(Doesn't have quite the same ring to it as NaNoWriMo, but I've gotta work with what I have.) I've been meaning to brush up on crypto for a while, so to help with that I'm going to post the notes I write up while reading stuff. I'll try to make them vaguely followable but from day to day they'll jump around quite a bit depending on what I feel like reading about. Also I won't necessarily write up notes for stuff I already know pretty well, so some of the basics will go completely uncovered. Also also these will mostly be based on just reading a couple pieces about each topic, so it's likely there'll be quite the collection of fatal oversimplifications and straight-up errors.
At the end of every topic will be the list of questions it prompted, which is how I'll pick the next things to read about.
As a result, this is probably useless to everyone except for me, but if you happen to find it beneficial, cool.
TLS (Transport Layer Security) notes
Pages read:
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
Followup to Secure Sockets Layer (SSL). SSL is no longer used due to vulnerabilities to POODLE and attacks on RC4.
Allows private, authenticated, integrous communication.
-Privacy: Asymmetric (public-key) cryptography is used to establish a symmetric session key, which provides encryption and makes it apparent if the messages are being altered (they'll likely become gibberish). This encryption makes it so that anyone who sees the messages traveling over the wire can't see what they actually say.
-Authentication: Almost always, the server (the recipient of the initial connection request, not the initiator) uses an asymmetric certificate to demonstrate its identity. This allows the caller to trust that it is who it says it is. In certain cases the server will also require the client to demonstrate its identity in the same way.
-Integrity: Message authentication codes are used to make it clear when the message has changed in transit.
Some implementations of TLS provide forward secrecy, which means that even if the asymmetric keys used for the initial key exchange are exposed, any old communications are still secure. This requires that the combination of the asymmetric keys and the data that was sent over the network are not sufficient to determine the session key. If they're used to directly exchange a symmetric key, this doesn't work and old communications can be decrypted. If they're used to encrypt something like a Diffie-Hellman key exchange, and the key generated during that exchange is deleted when the session is over, then forward secrecy is maintained.
Over time, there have been a couple versions of TLS, 1.0, 1.1, 1.2, and 1.3 (which is still incomplete). These have fixed or improved aspects related to:
-Attacks on the CBC (cipher-block chaining) mode of symmetric encryption.
-Weaknesses in the MD5-SHA-1 hash function used in pseudorandom number generation.
-Added support for authenticated encryption like Galois/Counter Mode and CCM mode of AES.
What's (probably) changing in TLS 1.3?
-Certain weak elliptic curves are no longer supported.
-Certain weak hash functions (MD5 and SHA-224) are no longer supported.
-Adding support for HKDF.
-Adding support for PSK (pre-shared keys).
-Supporting faster handshakes (1 round-trip and moving towards 0 round-trip)
-Adding support for the ChaCha20 stream cipher with Poly1305 MAC
-Adding support for the Ed25519 and Ed448 digital signature algorithms.
-Adding support for the x25519 and x448 key exchange protocols.
What algorithms are supported in TLS1.3?
Initial key exchange:
-DHE-RSA
-ECDHE-RSA
-ECDHE-ECDSA
-and possibly others.
Notably, the three listed above all offer forward secrecy.
Cipher:
-AES GCM
-AES CCM
-Camellia GCM
-ARIA GCM
-ChaCha20-Poly1305
TLS1.2 has a handshake along the lines of the following:
Client: Yo server, I support (x,y,z) ciphers.
Server: Cool, let's use x. Here's my part of the key exchange
Client: Awesome, here's my part.
Server: Looks legit. Go on.
Client: (gets to start using the website)
TLS1.3 cuts down on round-trips by (basically) having the client guess what key the server will want to use:
Client: Yo server, I support (x,y,z) ciphers, and here's my part of the key exchange for x because x rocks.
Server: x is cool, so here's my part.
Client: Looks legit. (gets to start using the website)
I assume that if the server doesn't support x, it'll just fall back to the normal 2-round-trip process? Haven't read through the explicit TLS1.3 spec yet so I'm not positive.
TLS1.3 also allows 0-round-trip session reestablishment by having the client and/or server cache one of the keys from the last time they communicated.
In general, TLS1.3 straight-up bans a lot of dumb stuff that was recommended against but still allowed in certain situations by TLS1.2
Open questions from this:
??? What's POODLE?
??? What's RC4?
??? What does the PKI and CAs look like that support TLS?
??? What exactly is a message authentication code?
??? What's Galois/Counter Mode?
??? What's CCM?
??? How exactly does AES function?
??? What's HKDF?
??? What's TLS-PSK?
??? What's ChaCha20 and Poly1305?
??? What are Ed25519 and Ed448?
??? What are x25519 and x448?
??? What are DHE-RSA, ECDHE-RSA, and ECDHE-ECDSA?
??? What are Camellia and ARIA?
KRACK (Key Reinstallation AttaCKs) notes
Pages read:
At the start of a WPA2 session, the device and the router perform a key handshake. KRACK interferes with this handshake and performs a replay attack. One of the messages of the handshake causes the client to set the key and nonce (IV) used to the initial value for the session. By repeatedly sending this message, the 3rd in the 4-part handshake, the client can be made to send multiple messages encrypted using the same keystream (that is, the messages are encrypted by XORing them against the same stream of bytes) (because apparently WPA2 uses a stream cipher?). With this, a single known message will let you decrypt all other messages encrypted with the same key. This could be accomplished by finding a common header, or, if you can predict characteristics of the underlying data (for example, that it's likely ASCII text), this could be accomplished with a couple messages even without one being concretely known in advance.
If the TCP SYN packets are captured, the connection itself can be hijacked.
wpa_supplicant 2.4 and above (a wifi client commonly used on linux, and by extension, android) clears the negotiated key from memory after the first time it's told to install it, as apparently the spec for the protocol says that's something you can consider doing, and as a result the replay in the attack causes the installation of a key that's all 0s (or something like that). That makes it even easier to eavesdrop.
Doesn't leak the actual WPA2 password.
Open questions from this:
??? How does the TCP hijack work?
??? What exact stream generator is used in WPA2, and what does the full handshake (or handshakes?) look like.
??? WPA-TKIP? GCMP? AES-CCMP?
??? 4-way handshake? Fast BSS Transitional (FT) handshake?
