Week 5 - Encryption

Sending VERIFIABLE secrets

ALICE needs to send a verifiable message to BOB but CAROL is trying to listen in.

Some definitions:

CLEARTEXT - (should be obvious)
CIPHER - The system of encryption
CIPHERTEXT - the (hopefully not-understandable) gibberish generated
KEY - the arbitrary DECODING or ENCODING "thing/data/password-ish thing" - sometimes not both.

Steganography

• Hiding the fact that the message/payload exists at all; e.g.

Examples:
- fake personal ad to say something else
- having a safe but hiding valuables in a shoebox
- weird bits in a jpg

Steganography is less preferred..

..when your attacker can potentially "see" everything.
EG, the internet, or even...

Some standard ideas

Security through obscurity* is generally a bad idea:

*The STRICT definition, meaning
"Relying on secrecy in implementation or design,
NOT in the key"

Security through obscurity

"Any person can invent a security system so clever that she or he can't think of how to break it."
Schneier's Law

(you can generalize this to a lot of things; e.g. Open Source, Auditing, etc)

Never roll your own

(Or better yet, do, and throw it out. You'll learn something)

Better

Quick note on "Security Through Obscurity"

Sometimes people use this as an equivalent to Steganography, though not quite.

I.E the great

"Should you change your SSH Port" Debate?"

What's the answer?

Against a determined attacker trying to get you personally? No point.

But, as the joke goes, it won't make you faster than the bear, but it will
make you faster than the other hunter.

It's MATH all the way down

One Way Strategies.

Really, it's KEY exchange that's a big deal

If you and your conspirator can "meet" - this makes things easy:

• Bookstore Strategy

or better yet

• One Time Pad

(Note that OAuth 2FA is *a lot* like this, but not identical. The overriding 2FA code is like the "book")

But, we are usually "strangers"

Enter PUBLIC KEY ENCRYPTION

So we use this for KEY encryption

The weird flipside of this:

SIGNATURES

IMPORTANT PRACTICAL PRINCPLES

RANDOMNESS

Pseudo-randomness is easy:
"Multiply big'ol numbers a bunch and chop off the beginning of them"

TRUE Randomness is surprisingly hard

RANDOMNESS

In a sense, you can't do it "inside" the computer.

Cloudflare

Backdoors

Yep, they're going to KEEP TRYING THIS MESS.

PRACTICAL MATTERS

DON'T ROLL YOUR OWN...better yet

PRACTICAL MATTERS

DEMAND only free and open source here, confirmed by e.g. NIST

Anything else is almost CERTAINLY compromised in real life.

PRACTICAL MATTERS

All software is imperfect and may have bugs;
..watch out as they may try to use this against you.

PRACTICAL MATTERS

Don't fall for the "Security through Obscurity" trap
(as in, actually reinforce, don't just hide)

PRACTICAL MATTERS

- OR for the "Security through Obscurity trap" trap
(additional hiding to reinforcement isn't bad, aka someone might seriously say, DONT PAINT THIS CAMO.)

Rubber Hose Decryption

Watch the endpoints, this is where the vulnerabilities are

Finally - encrypted AGAINST WHOM?

You'll have to do a fair bit of "game theoretical" thinking here,
when you're dealing with "black-box" encryption.
E.g. Whatsapp claims to be end-to-end encrypted?
I legit don't know.