Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

«Applied cryptanalysis everything else» by Vladimir Garbuz

0xdec0de01

  • Sé el primero en comentar

  • Sé el primero en recomendar esto

«Applied cryptanalysis everything else» by Vladimir Garbuz

  1. 1. Applied Cryptanalysis: Everything else Vladimir Garbuz
  2. 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)
  3. 3. Block ciphers Modes of operation: ECB •Electronic CodeBook, the naive approach
  4. 4. Block ciphers Modes of operation: CBC •Cipher block chaining, a more clever approach
  5. 5. Block ciphers Modes of operation: CBC •Bit flipping •Padding oracle attack • E.g. POODLE on SSLv3 • And TLS 1.0-1.2 implementations
  6. 6. Block ciphers Modes of operation: CBC – Padding Oracle http://sampleapp/home?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
  7. 7. Block ciphers Modes of operation: CBC – Padding Oracle Request: http://sampleapp/home?UID=0000000000000000F851D6CC68FC9537 Response: 500 - Internal Server Error
  8. 8. Block ciphers Modes of operation: CBC – Padding Oracle Request: http://sampleapp/home?UID=0000000000000001F851D6CC68FC9537 Response: 500 - Internal Server Error
  9. 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. 10. Block ciphers Modes of operation: CBC – Padding Oracle Request: http://sampleapp/home?UID=000000000000003FF851D6CC68FC9537 Response: 500 - Internal Server Error
  11. 11. Block ciphers Modes of operation: CBC – Padding Oracle Request: http://sampleapp/home?UID=000000000000243FF851D6CC68FC9537 Response: 500 - Internal Server Error
  12. 12. Block ciphers Modes of operation: CTR
  13. 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
  14. 14. Hash
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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!”
  27. 27. Cryptographic hash MD5 What’s similar for these 3 images?.. Their MD5 hash! And a freely available tool HashClash was used!
  28. 28. Cryptographic hash MD5 Chosen prefix collisions
  29. 29. Authenticated encryption
  30. 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. 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. 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!
  33. 33. Public-key cryptography  A famous example is RSA
  34. 34. Digital signature  A simplified signing scheme via RSA
  35. 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. 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. 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. 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!!!
  39. 39. goo.gl/tuKku7
  40. 40. Questions and Discussion

    Sé el primero en comentar

    Inicia sesión para ver los comentarios

0xdec0de01

Vistas

Total de vistas

427

En Slideshare

0

De embebidos

0

Número de embebidos

4

Acciones

Descargas

16

Compartidos

0

Comentarios

0

Me gusta

0

×