2. Block ciphers
Intro
•Operate on blocks of equal, identical size
•Have different and clever modes of operation
• Some of them can simulate a Stream cipher
•Has to have it’s input length divisible by block size
• To achieve that, padding is used (e.g. PKCS7)
7. Block ciphers
Modes of operation: CBC – Padding Oracle
Request: http://sampleapp/home?UID=0000000000000000F851D6CC68FC9537
Response: 500 - Internal Server Error
8. Block ciphers
Modes of operation: CBC – Padding Oracle
Request: http://sampleapp/home?UID=0000000000000001F851D6CC68FC9537
Response: 500 - Internal Server Error
9. Block ciphers
Modes of operation: CBC – Padding Oracle
Request: http://sampleapp/home?UID=000000000000003CF851D6CC68FC9537
Response: 500 - Internal Server Error
X ⊕ 3C = 01
X = 01 ⊕ 3C
X = 3D
3D ⊕ 0F = ‘2’!
3D ⊕ Y = 02
Y = 3D ⊕ 02
Y = 3F
10. Block ciphers
Modes of operation: CBC – Padding Oracle
Request: http://sampleapp/home?UID=000000000000003FF851D6CC68FC9537
Response: 500 - Internal Server Error
11. Block ciphers
Modes of operation: CBC – Padding Oracle
Request: http://sampleapp/home?UID=000000000000243FF851D6CC68FC9537
Response: 500 - Internal Server Error
13. Block ciphers
Modes of operation: CTR
•Very parallelizable and simple
•Still has many vulnerabilities…
• Bit flipping works great
• Counter must count
• And nonces should NEVER be reused
15. Cryptographic hash
Basically a one way function
With a finite number of possible digests
And infinite possible inputs collision possibility
Cryptographic hashes have stronger properties,
specifically it must be hard to:
Modify a message without changing its hash
Avalanche effect is our friend
Generate a message that has a given hash
Which makes it a one-way function
Find two different messages with the same hash
Which provides collision resistance
16. Cryptographic hash
Main problems they address
1. Password storage
2. Key derivation
3. Ensuring data integrity
1. Message authentication codes (MAC)
2. Doing it right - HMAC
4. Proof of work
17. Cryptographic hash
Password storage
Never store passwords for verification in the clear
Use salts with hashes to fight rainbow tables
Don’t reuse it with different passwords
Don’t make it too short
Get it with CSPRNG
Never use clear hash functions to hash passwords
Wat?!
Yep! Go for a key derivation function!
Wat?...
18. Cryptographic hash
Key derivation functions
Designed to be slooow, hard to parallelize
And are used in password hashes storage
Also used to increase entropy of an encryption key
Entropy of stuff you can type on a keyboard isn’t great
Examples:
PBKDF2 from RSA – better than nothing
bcrypt – pretty good, widely available
scrypt – best! Not yet as available, but if it is – use it!
19. Cryptographic hash
Ensuring data integrity
Usual workflow:
Hash data to get it’s hash, send hash with data
Receiver gets the data, computes its hash and
compares it with the hash transmitted
E.g. you can see them next to sourcecode downloads…
This catches transmission errors but doesn’t work
against an attacker modifying the message
20. Cryptographic hash
Ensuring data integrity
Message Authentication Codes
MAC is a hash tag computed as F(message, key)
And the key MUST be unpredictable and NOT short
Function F() could be any, e.g.:
1. F(message, key) = key + message (the naive approach)
2. F(message, key) = message + key (just a little better)
3. F(message, key) = key + message + key (still bad)
4. F(message, key) = weird pseudo-random transforms,
…
But the right way is HMAC, always HMAC!
21. Cryptographic hash
Breaking “key + message” MAC:
Length extension attack
What’s vulnerable?
Hash functions with Merkle–Damgård construction, e.g.
MD4, MD5, RIPEMD-160, WHIRLPOOL, SHA-0, SHA-1
and even SHA-2
Doesn’t work on other constructions - SHA-3,
poly1305,...
In this construction, the resulting hash is the internal
state of the function at the end of computation
Which can (and will ) be used as the starting state of
the hash function
22. Cryptographic hash
Breaking “key + message MAC”:
Length extension attack
Hash of k+m is actually a hash of k+m+p, where p is
some necessary, but easily predictable, padding
To illustrate this:
H0(k) = Hk - here, H0 is the initial state of hash function
Hk(m) = Hkm - Hk is its state after processing k
Hkm (p) = Hkmp
Hkmp = H(k+m+p)
23. Cryptographic hash
Breaking “key + message MAC”:
Length extension attack
Since p is predictable and end state Hkmp is known
We chose any arbitrary m´
Set the hash function’s initial state to Hkmp
And make it process the bytes of message m´
Hkmp(m´) = Hkmpm´
Curiously, this is EXACTLY what happens when you
hash m+p+m´ under a known key!
Now, our hash is forged but will check out as valid!
24. Cryptographic hash
Ensuring data integrity
The right way: HMAC
Introduced in 1996
Thus, widely available
So effective, even broken functions
produce secure tags with it! (e.g. MD5)
Still, not a reason to ever use MD5
or any other broken hash function!
25. Cryptographic hash
Proof of work
The basic idea – something must be hard to compute but
easy to check if the computation is right
Make the client find a string whose hash matches a mask
E.g. whose SHA-1 starts with the phrase “JEEZUZ” in ASCII
Get the text, compute it’s SHA-1 and check if it matches
Although, choose the mask randomly for each client
If it’s not enough, throttle the connection down by larger mask
Very useful to deter DoS or password bruteforce
By the way, that’s what Bitcoin is based on
26. Cryptographic hash
Vulnerable, but still used, hash functions
MD4
MD5 – yes, fully broken since 2007, stop using it!
SHA-1
“Oh please, we’ve used MD5 forever and it’s been
ok!”
30. Authenticated encryption
Approaches to Authenticated Encryption
Encrypt-and-MAC (E&M): A MAC is produced based on the
plaintext, and the plaintext is encrypted without the MAC.
MAC-then-Encrypt (MtE): A MAC is produced based on the
plaintext, then the plaintext and MAC are together
encrypted to produce a ciphertext based on both.
Encrypt-then-MAC (EtM): The plaintext is first encrypted,
then a MAC is produced based on the resulting ciphertext.
One should NEVER start decrypting if the MAC isn’t right!
31. Authenticated encryption
AE with Associated Data – AEAD
Basically means that some data is sent in cleartext but the
MAC authenticates it as well (e.g. packet routing info)
NEVER use un-authenticated encryption!
E.g. TLS 1.3 removes support for non-AEAD cipher modes!
NEVER implement encryption (cryptography) yourself!
Go google how to use AE in your framework
Example AEAD modes are GCM, EAX, CWC
32. “That’s all cool stuff, but how do we securely exchange
encryption keys over an insecure Internet connection with
people we’ve never met in person?...”
Public-key cryptography!
CRYPTOMAN
To the rescue!
35. Key exchange
Abstract Diffie-Hellman key exchange
Acronyms – DHE, ECDHE
Basic principle: paints
Paints are easy to mix
But difficult to separate
Vulnerable to MITM!
“Common paint” must be signed
Then why not just use public-key
to encrypt the key?..
Perfect forward secrecy!
36. Perfect forward secrecy
Even if private keys are stolen, the actual encryption
keys can not be uncovered
When Diffie-Hellman is properly configured, e.g IPSec,
SSH, TLS, STARTTLS, OpenSSL support it
37. Best Practices
1. NEVER invent your own crypto – it’s way too easy to screw
up!
2. NEVER implement existing cryptographic algorithms
yourself!
3. NEVER use export (EXP) crypto!
4. NEVER use broken cryptographic functions/primitives!
5. NEVER use passphrases as encryption keys! Go for key
derivation functions!
6. NEVER use unauthenticated encryption!
7. Use cryptographically strong PRNGs!
8. For symmetric encryption, use at least AES-128 or higher
9. For cryptographic hashing, use at least SHA-256 or higher
10. For password storage, use a key derivation function with a
long, random salt!
38. Best Practices
•Do TLS the right way!
•Yay or nay?
• ECDHE-RSA-AES256-GCM-SHA256
• Yay!
• ECDHE-RSA-RC4-SHA
• Nay!
• EXP-RC4-MD5
• Nay nay nay!!!
