Alice & Bob: Public key cryptography 101

Transcript

1. Alice & Bob CodeConnexx 8-9 november 2013, Maastricht Public key cryptography 101 1
2. An introduction 2
3. 3 Without this there would be no internet as we know today (really)
4. example “encryption” algorithms 4 http://www.flickr.com/photos/dpwk/1714014449/in/pool-1621478@N23/
5. ciphertext: 3, 15, 4, 5 “algorithm”: A = 1, B = 2, C = 3, ...., Z = 26 = C O D E 5
6. 6 ciphertext:          = W I N G D I N G S
7. “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
8. ➡ Key is too easy to guess. ➡ Key has to be send to Bob. ➡ Deterministic. ➡ Prone to frequency analysis. 8
9. ➡ ‘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
10. 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:
11. 11 Let’s analyze:
14. 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:
15. Determinism and the ability to apply frequency analysis are “bad things” 15
16. ➡ 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
17. Q: How does Alice send over the message + key securely to Bob? Everybody’s listening! 17
18. Another encryption system: Asymmetrical encryption or public key encryption. 18
19. public key - available for everybody. 19 KEYPAIR private key - For your eyes only!
20. It is NOT possible to decrypt the message with same key that is used to encrypt. 20
21. 21 Use public key to encrypt: private key to decrypt OR private key to encrypt: public key to decrypt.
22. 22 Encryption Signing
23. 23 Awesome! So why not using asymmetrical encryption for everything??
24. 24 It’s too slow!
25. 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
26. 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.
27. ➡ Alice generates a random string: ➡ “monkeypooh” ➡ Alice encrypts this string with Bobs PUBLIC key => “sdfafkjasdgaag” 27
28. 28 “sdfafkjasdgaag” ??? (slow) public key encryption
29. ➡ Bob received “sdfafkjasdgaag” ➡ Bob decrypts the message with his PRIVATE key => “monkeypooh” 29
30. 30 ??? (fast) symmetrical encryption using key “monkeypooh” 1001001010111 omglolbbq! haha hacker noobs!
31. 31 Hybrid Encryption
32. Hybrid ✓ quick ✓ not resource intensive ✓ useful for small and large messages ✓ safely exchange key data 32
33. 33 Signing
34. 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.
35. ➡ 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
36. 36 “i don’t like mondays” “43tt34tqegadsgadsgA”
37. ➡ 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
38. ➡ Can’t change message, because encrypted hash would not match. ➡ Can’t change hash, because only Bob’s private key can encrypt. 38
39. 39 Great,.. but not really convinced...
40. 40 How many of you are actually using this encryption and signing in practice??
41. 41 100%
44. ➡ 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
45. 45 How do we know that the site is actually run by the ones we think they are?
46. 46 PRIVATE COMMUNICATION ENDPOINT AUTHENTICATION
47. ➡ 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
48. ➡ (Root) Certificate Authorities ➡ They are automatically built into your browser / OS and you will automatically trust them. 48
49. 49 http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt 185
50. ➡ 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
51. 51 ➡ But, we can fix pretty much everything else!
52. 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
53. 53 ➡ Every time you commit something to version control / github, you sign it with your key! ➡ Download new software (yum, apt, packagist)
54. 54 lots of ppl with keys lots of implementations not many ppl with keys no implementations no implementations not many ppl with keys
55. 55 Here’s another problem: ➡ Everybody can create a key ➡ And everybody can pretend to be anyone else
56. 56 ➡ We use a system called: web-of-trust
58. ➡ How do we create the web-of-trust? 58
59. ➡ 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
60. 60 http://chemnitzer.linux-tage.de/2009/service/pgp_en.html
62. ➡ Add GPG/PGP extension to your email client (enigmail / gpgsuite etc). ➡ Create a keypair. ➡ Use! ➡ Worry about the web-of-trust later! 62
63. ➡ 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
64. http://farm1.static.flickr.com/73/163450213_18478d3aa6_d.jpg 64
65. 65 Find me on twitter: @jaytaph Find me for development and training: www.noxlogic.nl Find me on email: jthijssen@noxlogic.nl Find me for blogs: www.adayinthelifeof.nl http://joind.in/9608