applied cryptanalysis - everything else

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 ciphers

Modes 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


Block ciphers

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


X ⊕ 3C = 01

X = 01 ⊕ 3C

X = 3D

3D ⊕ 0F = ‘2’!

3D ⊕ Y = 02

Y = 3D ⊕ 02

Y = 3F

Block ciphers

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


Block ciphers

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


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

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 storage

2. Key derivation

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


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!

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


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


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


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!

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

MD5

What’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


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!


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

to 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

https://goo.gl/tuKku7

Questions and Discussion

applied cryptanalysis - everything else

Software