«Applied cryptanalysis everything else» by Vladimir Garbuz

Applied Cryptanalysis:Everything else

Vladimir Garbuz

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)

Block ciphers

Modes of operation: ECB•Electronic CodeBook, the naive approach

Block ciphersModes of operation: CBC

•Cipher block chaining, a more clever approach

Block ciphers

Modes of operation: CBC•Bit flipping•Padding oracle attack• E.g. POODLE on SSLv3•And TLS 1.0-1.2 implementations

Block ciphers

Modes of operation: CBC – Padding Oraclehttp://sampleapp/home?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6

Block ciphers

Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=0000000000000000F851D6CC68FC9537

Response: 500 - Internal Server Error

Block ciphers

Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=0000000000000001F851D6CC68FC9537

Response: 500 - Internal Server Error

Block ciphers

Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=000000000000003CF851D6CC68FC9537

Response: 500 - Internal Server Error

X ⊕ 3C = 01X = 01 ⊕ 3CX = 3D3D 0F = ‘2’!⊕

3D Y = 02⊕Y = 3D 02⊕Y = 3F

Block ciphers

Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=000000000000003FF851D6CC68FC9537

Response: 500 - Internal Server Error

Block ciphers

Modes of operation: CBC – Padding OracleRequest: http://sampleapp/home?UID=000000000000243FF851D6CC68FC9537

Response: 500 - Internal Server Error

Block ciphers

Modes of operation: CTR

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

Hash

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

Cryptographic hash

Main problems they address

1. Password storage2. Key derivation3. Ensuring data integrity

1. Message authentication codes (MAC)2. Doing it right - HMAC

4. Proof of work

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?...

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!

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

Cryptographic hash

Ensuring data integrityMessage 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!

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

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)

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!

Cryptographic hash

Ensuring data integrityThe right way: HMAC

Introduced in 1996 Thus, widely available So effective, even broken functionsproduce secure tags with it! (e.g. MD5)

Still, not a reason to ever use MD5or any other broken hash function!

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

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!”

Cryptographic hash

MD5What’s similar for these 3 images?..

Their MD5 hash!And a freely available tool HashClash was used!

Cryptographic hash

MD5 Chosen prefix collisions

Authenticated encryption

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!

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

“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!

CRYPTOMANTo the rescue!

Public-key cryptography

A famous example is RSA

Digital signature

A simplified signing scheme via RSA

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-keyto encrypt the key?.. Perfect forward secrecy!

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

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 higher10. For password storage, use a key derivation function with a

long, random salt!

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!!!

goo.gl/tuKku7

Questions and Discussion