Cryptography

For Non-Cryptographers

Pt.1

Patrick Favre-Bulle

About

 

Lead Dev,  Senacor 2019, Wien

Professional

    - NFC Payment App (EMVCo)

    - E2E encrypted Health Data Provider

Articles

            Security Best Practices, ...

Open Source

           bcrypt, armadillo, hkdf, id-mask, dice, ...

Patrick Favre-Bulle

Symmetric Encryption

From Block Cipher to Authenticated Encryption

Cryptoanalysis 

128 vs 256 bit security,  How Secure is AES?

1

2

Crypto APIs

The unfortunate Story

3

Table of
Contents

Symmetric
Encryption

 

Remember XOR?

  • Important Logical Operation in Cryptography¹¹¹
A B Out
0 0 0
0 1 1
1 0 1
1 1 0
0110 ^ 1100 = 1010
1010 ^ 1100 = 0110

Bits, Bytes and Numbers

  • 128 bit = 16 byte = 3.4x10^38
  • 256 bit = 32 byte = 1.15x10^77
  • 16 byte = UUID = IPv6 Address

Advanced Encryption Standard

  • AES (Advanced Encryption Standard) aka Rijndael
  • Winner AES Selection Process (2001)
  • Block Cipher with 128 bit Block Length
  • Key Sizes of 128, 192 und 256 bit

Block Cipher

Plain Text

0x41 0x20 0x53 0x65 0x63 0x72 0x65 0x74 0x20 0x4d 0x65 0x73 0x73 0x61 0x67 0x65

A Secret Message

Plain Text: Ascii

Key

16 random bytes
0x41 0x20 0x53 0x65
0x63 0x72 0x65 0x74
0x20 0x4d 0x65 0x73
0x73 0x61 0x67 0x65

Block Cipher

  • SubByte Step
  • ShiftRow Step
  • MixColumn Step
  • AddKey Step

9, 11 or 13 Rounds

AES Round

Encrypt More Than 1 Block?

Block cipher mode of operation!

Block cipher mode of operation:

Electronic Codebook (ECB)

Block Cipher

Encryption

Ciphertext 1
Plaintext 1
Key

Block 1

Block Cipher

Encryption

Ciphertext 2
Plaintext 2
Key

Block 2

...

Electronic Codebook (ECB)

Why is it bad?

What if Plaintext does not exactly fit a Block?

Padding!

  • PKCS#7

Practically no security implication in the choice of padding in AES*

 ... 6F 1A 02 __ __ __ __
         04 04 04 04
 ... 6F 1A 02 E5 __ __ __
            03 03 03

What else?

Cipher Block Chaining (CBC)

Block Cipher

Encryption

Ciphertext 1
Plaintext 1
Key

Block 1

Initialization Vector (IV)

Block Cipher

Encryption

Ciphertext 2
Plaintext 2
Key

Block 2

+

+

Initialization Vector?

  • Fancy for: "Random Data the size of a Block"
  • Like a Salt, it should be
    • random
    • can be public
    • should be used only once*

* This property is depending on the block mode a recommentation or integral for security

Cipher Block Chaining (CBC)

CBC: data looks random

What else?

Counter Mode (CTR)

Block Cipher

Encryption

Ciphertext 1
Nonce
Key

Block 1

Plaintext 1

+

Counter

0000

Block Cipher

Encryption

Ciphertext 2
Nonce
Key

Block 2

Plaintext 2

+

Counter

0001

Counter Mode (CTR)

  • Makes a Block Ciper a Stream Cipher (No padding required)
  • Performance: encryption & decryption in parallel as well as random read access
  • VERY IMPORTANT: IV/Nonce MUST NEVER be reused with same key

Just One Problem:

Did anybody modify my message?

Unfortunately: Encryption does not protect against modification!

                 Known Attacks

  • Padding oracle attack
  • BEAST attack
  • Lucky Thirteen attack

Solution

Message Authentication Code (MAC)

  • Symmetric version of digital signature
  • Most common HMAC (Hash-based Message Authentication Code)¹¹¹¹

But how?

  • Encrypt first, then mac? Mac first then encrypt??
  • Use the same key? Use a different one?
  • Slow: Needs 2 Passes

Authenticated

Encryption

  • Confidentiality
  • Integrity
  • Authenticity

Block Mode of Operation:
Galois/Counter Mode (GCM)

  • Similar to CTR + Authentication Tag
  • Like CTR: IV/Nonce MUST NEVER be reused with same key
  • Free to use and widely implemented and used
  • Can be used to authenticate additional data

Ciphertext

Auth Tag

Block Mode of Operation for
Full Disk Encryption

  • Simple bit switch must not change whole disk
  • Special Modes: e.g. Bitlocker or Mac FileVault uses XTS

Kind of a
Cryptoanalysis

128 vs 256 Bit Key

  • Switch of Gate = C×V2 = 10^-15 J
  • Energy world consumption: 567 EJ (2013)*
  • 1 World Computer, 10 Y = 2^122**

Brute Force 128 bit: "How many football fields does it take?"

128 Bit Keys probably not broken through brute force anytime soon!

128 vs 256 Bit Key

Reasons for 256 bit

  • Marketing
  • Compliance
  • Quantum Computer Protection*

Reasons for 128 bit

  • Faster
  • Resistant to 256 bit key related key attacks

Why then 128 bit, 192 bit and 256 bit Key Option?

Why AES and not

[insert fancy new cipher]

  • In Cryptography old is good (introduced 2001)
  • Under lot of scrutiny (used in e.g. TLS, WPA, OpenVPN, ...)
  • Highly stanzdardized (NIST)
  • Implementation available in practically every language
  • Very Fast (in Hardware) > GB/s
  • Hardware Implementations widely available (e.g.  x86 AES-NI,  ARM cryptographic extensions)

Why not AES?

  • Specific Use Cases may make other algorithms more feasible

    e.g. Bernstein's ChaCha20 is popular with Google because it is faster on non-hardware accelerated clients (like TLS in browser on some mobile devices)
     
  • DES Legacy

    e.g. 3DES still used in NFC Payment (EMVCo)

Is AES Secure?

AES is Broken!

In Cryptography broken does not necessarily means insecure.

Attacks have been published that are computationally faster than a full brute-force attack, though none as of 2013 are computationally feasible. For AES-128, the key can be recovered with a computational complexity of 2^126.1 using the biclique attack. (...) Related-key attacks can break (...) AES-256 with complexities 2^176 in both time and data, respectively.

An unfortunate Story
Crypto APIs

Levels Crypto Code

Primitives

Protocol Developer

Opinionated Protocol User

e.g. Implementation of Block Cipher

e.g. Secure Channel implementation

e.g. changing TLS Certificate

most Crypto APIs

Higher Level

Lets implement AES Encryption in Java!

  • Java Cryptography Architecture (JCA) & Java Cryptography Extension (JCE)
  • Implementation of Primitives JDK dependant (or Android)

Step 1: Create Key

SecureRandom secureRandom = new SecureRandom();
byte[] key = new byte[16];
secureRandom.nextBytes(key);

SecretKey secretKey = new SecretKeySpec(key, "AES");

Step 2: Initialise Cipher

byte[] iv = new byte[12]; //NEVER REUSE THIS IV WITH SAME KEY
secureRandom.nextBytes(iv);

final Cipher cipher = 
	Cipher.getInstance("AES/GCM/NoPadding");
GCMParameterSpec parameterSpec = 
	new GCMParameterSpec(128, iv); //128 bit auth tag length
    
cipher.init(Cipher.ENCRYPT_MODE, secretKey, parameterSpec);

if (associatedData != null) {
    cipher.updateAAD(associatedData);
}

Step 3: Encrypt & Package

byte[] cipherText = cipher.doFinal(plainText);

ByteBuffer byteBuffer = 
	ByteBuffer.allocate(iv.length + cipherText.length);
byteBuffer.put(iv);
byteBuffer.put(cipherText);
byte[] cipherMessage = byteBuffer.array();

//overwrite the content of key with zeros
Arrays.fill(key, (byte) 0); 

Step 4: Decrypt

final Cipher cipher = 
	Cipher.getInstance("AES/GCM/NoPadding");
    
//use first 12 bytes for iv
AlgorithmParameterSpec gcmIv = new GCMParameterSpec(128, cipherMessage, 0, 12);
cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmIv);

if (associatedData != null) {
    cipher.updateAAD(associatedData);
}

//use everything from 12 bytes on as ciphertext
byte[] plainText 
	= cipher.doFinal(cipherMessage, 12, cipherMessage.length - 12);

There is a lot to get wrong!

  • way too low level
  • unintuitive APIs







     

There is a lot to get wrong!

  • easy to get wrong
//THIS EXAMPLE IS UNSECURE - DO NOT USE

byte[] iv = new byte[12]; 
secureRandom.nextBytes(iv);

final Cipher cipher = 
	Cipher.getInstance("AES/GCM/NoPadding");
GCMParameterSpec parameterSpec = 
	new GCMParameterSpec(16, iv); //16 byte auth tag length
    
cipher.init(Cipher.ENCRYPT_MODE, secretKey, parameterSpec);

There is a lot to get wrong!

  • Cryptography requires different style of coding
byte[] calculatedMac = ... 
byte[] providedMac = ...

for(int i=0; i < calculatedMac.length; i++) {
    if(calculatedMac[i] != providedMac[i]) {
        return false;
    }
}

return true;
MessageDigest.isEqual(calculatedMac, providedMac); //JDK 6u10

Hello Side Channel Attack!

There are better options

  • Just do not implement crypto code!
  • Use higher level crypto frameworks like libsodium or Google Tink
  • Have a dedicated crypto engineer
  • Have formal audits or reviews

Summary

  • writing secure crypto code is hard, so avoid if possible
  • if that's not an option use high level frameworks
  • always strive for authenticated encryption (AES/GCM is a good choice)
  • 128 bit security is good enough for most use cases

Symmetric Encryption

Thanks!

Post your Qs in Slack