Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Alice & Bob: Public key cryptography 101

Joshua Thijssen
November 08, 2013

Alice & Bob: Public key cryptography 101

Joshua Thijssen

November 08, 2013


  1. ciphertext: 3, 15, 4, 5 “algorithm”: A = 1, B

    = 2, C = 3, ...., Z = 26 = C O D E 5
  2. “algorithm”: c = (m + k) mod 26 7 Message:

    C O D E Ciphertext (key=1): D P E F Ciphertext (key=2): E Q F G Ciphertext (key=-1): B M C D Ciphertext (key=0): C O D E Ciphertext (key=26): C O D E Ciphertext (key=52): C O D E http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Caesar3.svg
  3. ➡ Key is too easy to guess. ➡ Key has

    to be send to Bob. ➡ Deterministic. ➡ Prone to frequency analysis. 8
  4. ➡ ‘E’ is used 12.7% of the times in english

    texts. ➡ The ‘Z’ only 0.074%. ➡ ‘E’ is used 17.4% of the times in german texts, the ‘Q’ only 0.022% 9
  5. gl 7291 i owioa okddilnk ylgm hiu uflm mk cwgukl

    bs i dgegmiws okywm jkw i owgdf mvfs ngnl'm okddgm. mvfuf dfl cwkdcmes fuoicfn jwkd i dixgdyd-ufoywgms umkoainf mk mvf eku ilqfefu ylnfwqwkyln. mknis, umgee hilmfn bs mvf qkrfwldflm, mvfs uywrgrf iu ukengfwu kj jkwmylf. gj sky virf i cwkbefd, gj lk klf feuf oil vfec iln gj sky oil jgln mvfd., disbf sky oil vgwf, mvf i- mfid. 10 Intercepted message:
  6. 12

  7. 13

  8. In 1972 a crack commando unit was sent to prison

    by a military court for a crime they didn't commit. These men promptly escaped from a maximum-security stockade to the Los Angeles underground. Today, still wanted by the government, they survive as soldiers of fortune. If you have a problem, if no one else can help and if you can find them, maybe you can hire, The A- Team. 14 http://gutenberg.spiegel.de/buch/3664/4 Decrypted message:
  9. ➡ Previous examples were symmetrical encryptions. ➡ Same key is

    used for both encryption and decryption. ➡ Good symmetrical encryptions: AES, Blowfish, (3)DES. ➡ They are fast and secure. 16
  10. Q: How does Alice send over the message + key

    securely to Bob? Everybody’s listening! 17
  11. It is NOT possible to decrypt the message with same

    key that is used to encrypt. 20
  12. 21 Use public key to encrypt: private key to decrypt

    OR private key to encrypt: public key to decrypt.
  13. Symmetrical ✓ quick. ✓ not resource intensive. ✓ encryption only

    ✓ useful for small and large messages. ✗ need to send over the key to the other side. Asymmetrical ✓ no need to send over the (whole) key. ✓ can be used for encryption and signing. ✗ very resource intensive. ✗ only useful for small messages. 25
  14. 26 Q: How does Alice send over the message +

    key securely to Bob? Everybody’s listening! A: Use symmetrical encryption for the (large) message and encrypt the key used with an asymmetrical encryption method.
  15. ➡ Alice generates a random string: ➡ “monkeypooh” ➡ Alice

    encrypts this string with Bobs PUBLIC key => “sdfafkjasdgaag” 27
  16. Hybrid ✓ quick ✓ not resource intensive ✓ useful for

    small and large messages ✓ safely exchange key data 32
  17. 34 ➡ Maybe even more important than encryption? ➡ Signing

    is authenticating that a message is actually send by the sender and is not compromised in any way.
  18. ➡ Bob creates a message: “i don’t like mondays”. ➡

    Bob creates a md5() from this message: “b54c7cf4312cd6e2c37fd3f1ec681116” ➡ Bob encrypts this MD5 with his PRIVATE key => “43tt34tqegadsgadsgA” 35
  19. ➡ Alice decrypts the hash with Bob’s PUBLIC key: “b54c7cf4312cd6e2c37fd3f1ec681116”

    ➡ Alice creates a md5() from the message => “b54c7cf4312cd6e2c37fd3f1ec681116” ➡ Alice checks if both hashes match. 37
  20. ➡ Can’t change message, because encrypted hash would not match.

    ➡ Can’t change hash, because only Bob’s private key can encrypt. 38
  21. 42

  22. 43

  23. ➡ When we go to a HTTPS website, we are

    establishing a symmetrical encryption. ➡ We use asymmetrical encryption to exchange the (random) key used. ➡ The public key we need to use is found in the SSL-certificate. 44
  24. 45 How do we know that the site is actually

    run by the ones we think they are?
  25. ➡ It is signed (by somebody else) that states: this

    certificate / URL truly belongs to them. ➡ Signed by their PRIVATE key, so we can use their PUBLIC key to check the signature. 47
  26. ➡ (Root) Certificate Authorities ➡ They are automatically built into

    your browser / OS and you will automatically trust them. 48
  27. ➡ We are forced to trust companies that make a

    living on selling as many certificates as possible.. ➡ It’s a flawed system, but the best we have :( 50
  28. 52 ➡ Email: privately communicate between you and somebody else.

    ➡ Making sure your email isn’t tampered with and actually comes from you. ➡ Enigmail / gpgsuite ➡ Pretty easy to setup and use
  29. 53 ➡ Every time you commit something to version control

    / github, you sign it with your key! ➡ Download new software (yum, apt, packagist)
  30. 54 lots of ppl with keys lots of implementations not

    many ppl with keys no implementations no implementations not many ppl with keys
  31. 55 Here’s another problem: ➡ Everybody can create a key

    ➡ And everybody can pretend to be anyone else
  32. 57

  33. ➡ Every time you meet a person in real life.

    ➡ key signing parties on meetups, conferences, places where enough people come together. ➡ No need for a computer / laptop. Only your key (fingerprint) and something that identifies you being you (driving license, ID etc) 59
  34. 61

  35. ➡ Add GPG/PGP extension to your email client (enigmail /

    gpgsuite etc). ➡ Create a keypair. ➡ Use! ➡ Worry about the web-of-trust later! 62
  36. ➡ PKE enables us to (automatically) enrich your content with

    security and/or privacy. ➡ It’s still hard to implement, but it’s getting better and easier. ➡ (e-)mail was hard too! ➡ We *need* it. 63
  37. 65 Find me on twitter: @jaytaph Find me for development

    and training: www.noxlogic.nl Find me on email: [email protected] Find me for blogs: www.adayinthelifeof.nl http://joind.in/9608