Search
Talks
Better Than ROT13
Edit
#encryption
#cryptography
#ruby
Summarized using AI

Better Than ROT13

Bradley Grzesiak • September 29, 2011 • New Orleans, Louisiana • Talk

In the talk titled "Better Than ROT13" presented by Bradley Grzesiak at RubyConf 2011, the complexities and history of cryptography are explored, emphasizing the importance of secure encryption practices in modern applications.

The main themes of the talk include:

  • Historical Context: Grzesiak begins by discussing early encryption methods, like the ROT13 and Caesar Cipher, noting their vulnerabilities to brute force attacks.

  • Types of Encryption: The speaker explains two main categories of encryption:

    • Symmetric Encryption: Involves using the same key for both encryption and decryption. Examples include DES, 3DES, and AES. Grzesiak highlights concepts such as confusion, diffusion, and various symmetric modes like ECB and CBC, outlining their risks and appropriate uses.
    • Asymmetric Encryption: Utilizes a pair of keys (public and private) for securing messages. RSA is pointed out as a prevalent asymmetric encryption method, with discussions on key generation and associated vulnerabilities such as timing attacks and quantum threats.

  • Hash Functions and Signing: Grzesiak touches on the significance of hashing for data integrity and secure password storage, advocating the use of bcrypt over MD5 and SHA due to its resilience against brute-force attacks. He describes how digital signatures work and the role of certificates in secure communications using cryptography.

  • Practical Implementations in Ruby: The speaker showcases how to leverage OpenSSL in Ruby to implement AES encryption securely, emphasizing the importance of using strong keys and avoiding well-known vulnerabilities in encryption modes.

  • Library Development and Security: Grzesiak introduces the idkfa gem, a library intended to securely store sensitive information in Ruby applications. However, he cautions that developers must have a deep understanding of cryptographic principles before attempting to implement their own solutions.

  • Conclusions on Encryption: The presentation concludes with the admonition that encryption is complex and fraught with potential pitfalls. Grzesiak encourages thorough study and understanding before venturing into cryptographic implementation, citing the extensive knowledge required and the potential for human error.

Overall, this talk serves as a foundational exploration of cryptography while warning against the common pitfalls in its implementation, especially for those using it in programming applications.

Better Than ROT13
Bradley Grzesiak • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 12, 2011
Announced: unknown

We use encryption every day, from SSL to SSH to passing notes to your crush during Social Studies class. But how does it actually work? I'll avoid most of the math but cover the concepts of both symmetric and asymmetric encryption, including hashing and signing. I'll also show how to use OpenSSL from inside ruby and show off the idkfa gem, a library to securely store sensitive information into your code repositories.

RubyConf 2011

00:00:17.920 whoa that's loud hello my name is Bradley grec uh
00:00:24.920 you can find me on the internets as listy and pretty much everywhere uh um I
00:00:30.039 started a company with Steve Anderson over there called bendy Works a few years back and uh I run a infrequently
00:00:36.559 updated blog called naming things is hard.com um so the talk of my title is
00:00:41.840 better than rot 3 but it really should be called um don't try this at home uh
00:00:47.920 so a brief overview of what I'm going to talk about is a historical perspective of
00:00:53.079 cryptography symmetric encryption modes of symmetric encryption hashing asymmetric encryption
00:01:00.160 signing and then uh implications on how that affects Ruby uh so we all know about R 13 uh
00:01:08.840 it's actually a one instance of a a bunch of a class of algorithms called rat n and it's actually H it actually
00:01:16.320 has the official title of the Caesar Cipher apparently Julius Caesar used this all the time to talk to his generals out in the field uh and the
00:01:23.640 Caesar Cipher uh you encrypt by modular addition you decrypt by modular subtraction and the key this the thing
00:01:31.079 you want to keep secret is just n um so I'm GNA have a bunch of diagrams throughout this presentation I'm using a
00:01:38.200 couple of um uh features to help keep things straight first thing is anything
00:01:44.079 in uppercase is going to be public knowledge um something that you can let out into the world and not worry about
00:01:50.600 it I made it caps because it would be loud uh secret knowledge is going to be
00:01:55.840 all in lower lower case um something that's in a box is an algorithm and something in a circle is data um don't
00:02:02.320 mind the fact that that's not a circle uh so r n you take your secret plane
00:02:07.600 text the thing you don't want anyone else to see except the intended recipient uh you run it through the algorithm r n which is public you keep
00:02:15.120 the the key n secret and then you come up with a Cypher text that you send on its way and
00:02:22.000 to decrypt uh you use the inverse of r n which is modular subtraction uh again
00:02:27.519 you apply the secret n and you get back the sub the plane text not too difficult
00:02:32.959 U the reason we like to make fun of rot 13 is because rot 13 is equivalent to inverse of rot 13 so hence the joke
00:02:39.879 about double rot 13 uh obviously there are some serious vulnerabilities with this scheme uh
00:02:46.120 Brute Force attack you know you have 25 combinations to try uh rot zero isn't
00:02:51.159 very effective so you have 25 others to try um it only encrypts alphabetic stuff
00:02:56.959 which is usually a problem um so you can move on to something more advanced like the substitution Cipher you may have
00:03:02.640 seen these in the Sunday uh uh newspaper so basically you take an alphabet and a
00:03:08.560 scramble alphabet and make a map between the two uh you can extend that further and uh instead of just doing Al the
00:03:14.920 alphabet you can use uh numbers symbols what have you um so this also has some
00:03:20.879 vulnerabilities uh you have you can use letter frequency analysis because e is
00:03:25.920 the most uh frequent letter used in the English language it might be a different letter in different languages but in
00:03:31.200 English it's e um you have word frequency analysis so e and t are pretty
00:03:37.040 common and if you see a word um that's encrypted that starts with a T has a blank has an e you can assume with high
00:03:44.239 probability that the middle letter is H might be o but it's probably H and there's also temporal analysis so if you
00:03:51.239 keep sending more or less the same message over and over uh let's say at 8 a.m. you're you're reporting that the
00:03:56.599 weather is fine or cloudy or whatever something I'll use little later as well you can start using uh the the time that
00:04:03.360 the message is sent uh to help you in decrypting so moving from a monograph
00:04:09.680 where you have one letter to another letter you can start using something called a diagraph Cipher so uh
00:04:17.280 wheatstone invented this uh a cipher um it's not called the wheatstone cipher
00:04:22.520 it's called the Playfair cipher wheatstone you may have uh remembered his name from electrical engineering
00:04:27.840 classes if you took any created something called the wheatstone bridge kind of cool uh he also invented a cipher but Lord Playfair really liked it
00:04:34.639 and told everyone about it so it's named the Playfair cipher so you use a a pass phrase uh as
00:04:42.000 the key so let's take correct horse battery staple and if you read XKCD you
00:04:47.800 will recognize this from um this particular comic um if you don't read
00:04:54.000 XKCD start doing so immediately go through all over 900 of the comics so far uh it's well worth your time um but
00:05:02.759 going back to the P phrase what you do is you you take the P phrase and anytime a letter is repeated you delete the the
00:05:10.320 non first uh character so for example we're going to remove the second R in correct uh the O and horse because the O
00:05:17.120 is incorrect um Etc and you come up with corth
00:05:22.960 VAP um and so you arrange those into a 5x5 grid so you can see Co ET and it
00:05:29.120 keeps going um and then you get to the Middle where you run out uh and you just pad the rest
00:05:35.000 of the the 5x5 square with the remaining letters of the alphabet in order um and
00:05:40.280 because it's 5 by5 you had 25 there's 26 letters actually use I and J as the same or you can omit Q or whatever you want
00:05:47.160 to do but this is the general way it was used um so let's say we want to encrypt NP so we take R square we find n and p
00:05:55.000 kind of in the middle there and then that forms a rectangle and so we take take that rectangle and find the other
00:06:01.560 two corners of the rectangle and that's your encrypted pair so here we would output if there are rules on what
00:06:08.360 happens if they're in the same Row the same column or two in a row I won't go into those obviously this also has some
00:06:15.080 some vulnerabilities but it is better than substitution cypr uh it's susceptible to Brute Force there are 600
00:06:22.000 diagraph combinations which is just 26 * 25 um it has a poor padding scheme
00:06:28.919 because in that by 5 Square the last the bottom right is almost always Z unless Z
00:06:34.639 appears in your passphrase it's not very good for security it's alphabetical only again um
00:06:41.599 so this is a problem that the Germans faced actually in World War II with their Enigma machine the Enigma machine
00:06:47.319 only encrypted letters and so there was a common report that would be sent with
00:06:53.560 um a number from 1 to 12 that starts off the message they couldn't encrypt
00:06:58.879 numbers so they spelled it out and the the spelled out words for
00:07:05.560 the numbers 1- 12 used almost all the letters in the English and and German language so uh if you assume that this
00:07:14.199 message starts with a number that's spelled out uh you have 12 possibilities and you can you can go from there
00:07:22.039 um also uh It suffers from diagraph uh frequency analysis so the letters de and
00:07:27.720 Ed appear frequently r e e r also appear frequently and so you can do the same
00:07:33.560 thing with you uh that you do with substitution ciphering with the letter e and t and so on uh you can also use an
00:07:39.560 exor stream go a little further so I want to encrypt the the letters NP I
00:07:44.599 convert that to asky a bunch of bits um I'm going to come up with a random key called just P star and if I exort all
00:07:52.240 those bits together I get greater than z um I chose uh values that resulted in
00:07:58.039 asky characters but they don't have to they can certainly be non-printing characters um this also has some
00:08:03.440 vulnerabilities first and foremost if you know two of the things you can always get the third so let's say you uh
00:08:10.800 have a cipher text and you have the plain text if you exor those together you get the key and if the the person
00:08:18.120 you're attacking uses that key over and over again then you can use that key and
00:08:23.520 their Cipher text to always uh decrypt their their Cipher text um there's also
00:08:28.560 no diffusion this is topic I'm going to get into a little uh later but the idea of diffusion is uh or at least the
00:08:34.760 absence of diffusion in exor is that a bit in position a in the plain text only
00:08:40.200 affects this the bit in position a in the cipher text it doesn't affect other
00:08:45.399 uh bits in the uh in the result but exor can be used very uh
00:08:51.519 effectively in the idea of a onetime pad so onetime pad is where you have a key
00:08:58.040 that is as long as the message Mage that you're sending and it is never repeated mathematically this is unbreakable but
00:09:05.399 it's never used because if you're encrypting a one megabyte file you have to have a key that's one megabyte long
00:09:10.680 and you can never reuse it and somehow you have to get that key to the next person so um not exactly used very
00:09:17.560 frequently uh so let's talk about real symmetric cryptography um so the first
00:09:23.839 concept is confusion this is the the substitution of bits uh like the substitution Cipher um
00:09:30.040 one bite corresponds to another bite you have diffusion where if you change one B
00:09:36.360 one bit in the plane text it affects many many many bits in the cipher text
00:09:43.560 so the ideal situation is that if you change one bit in the plain text uh
00:09:49.160 every bit in the cipher text has a 50% probability of changing um the another important idea
00:09:55.880 is that uh you have a public algorithm and a secret key so if you have a gun pointed to your head and the person says
00:10:01.560 uh how did you encrypt this if it's some proprietary thing that once you tell someone how it works uh they'll be able
00:10:07.959 to decipher it that's bad because then they can coer you to say that if instead you can say I use this algorithm read
00:10:14.160 about it done Wikipedia I don't know what the key is though uh then you're well hopefully they don't blow blow your
00:10:19.399 brains out uh and the other thing about real
00:10:25.040 real symmetric cryptography is that it tends to operate on a single block side size so you can only encrypt uh 64 bits
00:10:32.640 into another 64 bits or 128 bits into another 128 bits there are things you can do to make that apply to an
00:10:38.920 arbitrary size message so this is the algorithm you get plain text you put it through an a
00:10:44.160 symmetric algorithm with a key and you get cyppher text the inverse is pretty
00:10:49.519 basic as well flip the arrows use the inverse of the symmetric Al algorithm and this looks awfully
00:10:55.839 familiar the only difference is that rot n is very simple and your typical
00:11:01.839 symmetric algorithm is not so uh a couple of examples of real
00:11:07.440 symmetric encryption are D's 3DS AES also known as rindal that is how you
00:11:12.760 pronounce that word uh D was published in 1977 uh and it was standardized in
00:11:20.959 1979 uh it uses a 56-bit key a 64-bit block size and uh triple d's was introduced
00:11:28.680 after that was determined that it wasn't enough so that was published in 1998 think about that that was 13 years ago
00:11:35.920 that we stopped kind of using a 56-bit key for pretty much anything uh it uses uh generally it uses
00:11:43.800 168 bit key uh which is actually just three 56 bit Keys next to each other um
00:11:49.920 it also uses 64bit block size and the encryption algorithm is really simple use these just three times encrypt the
00:11:57.200 plane text with the the first third of the the the key then decrypt with a second third and then encrypt again with
00:12:02.480 a third third simple as that um moving on to AES um before I actually get into
00:12:08.760 that um I want you to mentally sign this agreement I blank promise that once I
00:12:14.440 see how simple AES really is I will not implement it in production code even though it would be really fun this
00:12:19.760 agreement shall be in in effect until the undersign creates a meaningful interpretive dance that compares and
00:12:24.920 contrasts cache based timing and other side Channel attacks and their counter measures imple implementing this stuff
00:12:32.760 securely is incredibly difficult and is the topic of a lot of debate at all the The Gray beard cryptographic
00:12:39.839 conferences so don't implement this anyway I I have a QR code at the
00:12:46.440 end of the presentation that has all my references that image was taken from a great stick figure uh comic not written
00:12:53.800 by Randall Monroe but Jeff Moser um that explains AES quite thoroughly uh so ad
00:13:00.519 it was written by Vincent Ryman and Yan Dam and they combined their last names into ryall it was published in 98 uh at
00:13:08.600 the behest of uh the nist National Institute of Standards and something
00:13:14.279 technology maybe um and it was anointed as the winner of the AES uh encryption
00:13:19.920 scheme in 2001 used 128 bit lock which is basically a 4x4 Matrix of 8bit
00:13:27.560 characters and it uses a 128 192 or a 256bit key so
00:13:34.440 it has a few vulnerabilities they're not very big and they generally refer to retrieving the key so that means you uh
00:13:42.480 you're trying to get the key out given that you already know both the cipher text and the plain text so you're kind
00:13:48.399 of broken already um but it's it's even though you have the cipher text and the plain text it's really hard to get the
00:13:54.600 key back and there are a couple of vulnerabilities the first is extended sparse linear
00:14:00.120 linearization exsl attack it's it has a very high work Factor so that um even
00:14:06.120 though you can reduce the number of um attacks that you do the the amount of
00:14:12.519 work done per attack just gets so big that it's not really feasible anyway uh
00:14:17.639 there's related key attacks on 256 bit AES so you can uh you can kind of crack
00:14:23.399 AES 256 bit uh through 9 10 or 11 rounds but the standard says 14 rounds so you
00:14:29.800 can't really uh do that use that you have kind of a three round safety margin
00:14:35.120 on that um there's by click analysis uh which reduces the effectiveness of the
00:14:40.839 as by a factor of four I have no idea what by clicks are um but the idea that you you're reducing the uh effort by a
00:14:49.000 factor four makes no difference whatsoever because the most effective
00:14:54.240 attack on a Brute Force attack on cryptography has ever has been by
00:14:59.399 distributed. net and it was a 64-bit key that was broken and so when you're talking about 128 bits every bit you add
00:15:07.079 doubles the amount of effort so to get from 64 to 128 isn't a doubling of effort it's 2 to the
00:15:14.279 64 um times the effort um and then there's also side Channel
00:15:21.240 attacks if someone manages to get a computer running onto on your machine first of all you're kind of already
00:15:26.519 screwed um but some people have some very smart people have uh written
00:15:31.959 software that lets them determine what your key is in as little as 800 operations or under 100
00:15:38.759 milliseconds um so make sure that your servers are secure um so the general
00:15:45.040 operation is that you take a key and um it's also a round key so in the first round you basically take the key and you
00:15:52.079 exort it with your message that 4x4 Matrix of characters that that applies
00:15:58.199 confusion then you uh shift the rows of this Matrix that applies diffusion you mix The Columns more diffusion um and
00:16:05.480 then you do that 10 or 10 12 or 14 times depending on the length of your key this is all you need to
00:16:12.120 know so memorize that and you should be good but remember don't implement it
00:16:17.959 ever um so moving on to symmetric modes of encryption um say you want to encrypt
00:16:24.240 more than uh 16 bytes of information um
00:16:29.399 this is how uh you use modes of encryption to do that so if you were to open Terminal and type open SSL space
00:16:35.399 and then tab twice you'll get that which is a lot of stuff it's all inter
00:16:40.440 intermingled as well there's symmetric asymmetric all kinds of stuff in there if you pick one of those let's say
00:16:47.399 D- ed3 because that sounds familiar from earlier in the talk and a-h then you get
00:16:53.199 all this stuff um so these are all symmetric uh ciphers with a bunch of on
00:16:59.240 them if we pick one at random and pick ECB whatever um if you've done that you just failed um open cell doesn't tell
00:17:07.600 you that this is a tremendously insecure way of encrypting things it just says here try it um this is how ECB Works uh
00:17:15.799 looks pretty straightforward right you take your first uh plain text block of 128 bits encrypt it into cyppher text
00:17:22.240 second 128 bits encrypted into Cypher text um but it has a lot of vulnerabilities you have information Le
00:17:29.160 and pattern analysis so uh information leakage again if you're sending messages
00:17:35.039 that say the weather is sunny the weather is rainy um you end up and and
00:17:40.799 you use some magic key that results in the output being 1 through eight 1 through eight one through 8 um the
00:17:47.160 messages look very much the same all the way up to that sunny or rainy you're by
00:17:52.720 doing that you're leaking information there's also pattern analysis uh problems this is this image
00:18:00.120 of tux is encrypted with ECB um if you're really trying to hide
00:18:05.200 something this doesn't look very hidden so don't use
00:18:10.440 ECB uh the solution would be to use something like chain block Cipher um so
00:18:15.760 basically the idea is that every block depends on the previous block and the first block depends on an initialization
00:18:21.799 Vector which you can uh make public that's why it's in caps so this is the the idea behind it you take your first
00:18:28.000 plain text block xor it with your initialization Vector run it through the algorithm you get Cypher text one and you use Cypher text
00:18:34.880 one xor that with plain text to and keep going and keep going so that's how uh
00:18:40.159 chain block suering works this is kind of an overview there are many other ways that mix up the lines quite a bit more
00:18:46.720 but um this works so it has a few vulnerabilities that are all related to you
00:18:54.679 sucking so um if you use the same initialization vector you've just used
00:19:00.280 ECB except you're you're calling it CBC um once again we see that the output
00:19:06.240 at the beginning is 1 through eight 1 through eight 1 through eight and at the bottom it's 1 through eight 1 through eight and then gibberish because it
00:19:11.280 actually changed at that point um so the solution is use you should never use the same initialization Vector uh for the
00:19:18.320 same key um and it's pretty much immune to pattern analysis that's a pretty well
00:19:24.799 hidden tux um so the moral is don't actually Dr down to this level but if you have to
00:19:30.919 use AES 128 192 256 whatever um and use
00:19:36.159 CBC mode uh the next topic is hashing yeah
00:19:41.320 uh what would you recommend use if you have to write something thats to
00:19:47.919 be CC the middle everything after the
00:19:53.039 question was what do you do about um tolerance to corruption in the middle of the the cipher there are other ofb uh uh
00:20:01.440 I can't remember the rest of them but there are a number that are that are more tolerant to that um they kind of
00:20:07.039 reset themselves every few blocks um check out Wikipedia it it's got a lot of
00:20:13.640 information actually on Wikipedia um so hashes uh We've we've heard about these
00:20:19.760 md5 sha um decrypt if you're if you're hashing passwords please use bcrypt um
00:20:26.720 there's also hmac which you use sha or md5 with hmac and I'll go through each
00:20:32.360 one of those traditional hashes md5 sha one are designed to be fast they're designed to take a large amount of
00:20:38.720 information and crush it down into a small string that you can compare um to
00:20:43.799 to detect if uh like one bit has changed in the in the giant amount of information but that in effect provides
00:20:50.919 very little security if any against Brute Force computers are getting fast enough that you can just Brute Force
00:20:56.880 everything um and salt doesn't doesn't help um if you don't solve things yes You're vulnerable to rainbow tables but
00:21:03.320 rainbow tables isn't Brute Force um you can just use the salt um and then Brute
00:21:09.200 Force against the salt and and all your guesses for the the password and um yeah
00:21:15.120 if you're using a fast algorithm like md5 or sha you're helping out the attackers uh so this is how a
00:21:21.039 traditional hash works you you throw some plain text into an algorithm and instead of outputting the result of the
00:21:27.000 algorithm you just feed that into the next block and keep going until you get the final value and you output the hash
00:21:32.640 so basically symmetric encryption but you don't output anything except for the very last thing uh bcrypt is similar it uses it
00:21:42.159 uses an initialization Vector that's why if you ever use bcrypt and you encrypt the same thing twice it will actually be
00:21:48.720 something different because it's using an initialization Vector so you can't actually compare the output of decrypt
00:21:55.200 um to see if the encrypted uh contents are the same so use an an initialization
00:22:01.000 vector and then it uses this public value called n which is basically a work factor that says um if I am using 10 as
00:22:08.880 my n right now if I bump that to 11 then the algorithm will take twice as
00:22:15.120 long and so this is very resistant to computers getting faster over time and so over time you can just say well
00:22:21.200 computers got faster after 18 months let's bump up n um and so it's pretty effective for that kind of thing n IV
00:22:28.279 and the hash are all public information um and you can go one step further and have authentication code
00:22:35.200 that are usually tied to a hash and uh it's basically the same thing um but you pass in a secret key um
00:22:43.320 and this is more uh used in in things like asymmetric signing which I'm about to get into so asymmetric encryption has
00:22:51.720 uh two things and you know RSA DSA usually just use RSA that's good enough
00:22:57.640 um it's it's it tends to be actually better than DSA um for some reasons uh
00:23:02.799 due to key length um and so there are two goals for asymmetric encryption um you want to encrypt uh a message so that
00:23:09.880 only one person can read it and you also want to verify your authorship of something so it encrypts uh basically
00:23:17.600 this way so instead of using the same key um in the forward and the inverse you use a public uh key to encrypt and a
00:23:25.760 private key to decrypt and how it really encrypts is crazy
00:23:31.640 up math so what you do is you you determine
00:23:39.000 p and Q these need to be prime numbers multiply them together to get n n is
00:23:44.600 called the modulus uh taking an uh just pick an encryption um exponent uh have
00:23:52.679 it fairly small and have it have a low Hamming distance uh one1 in he is often
00:23:59.159 chosen also three is chosen uh sometimes uh the decryption exponent is that e
00:24:06.679 inverse modded with uh the oiler totient uh of
00:24:12.760 n um and to encrypt something you take your message M you raise it to the
00:24:17.880 exponent of the encryption exponent and mod it with your n and then you get C
00:24:24.240 and to decrypt to get the message back you take the uh Cipher text raise it to the decryption exponent mod it with n
00:24:31.480 and you get n back um I kind of stayed away from the capital letter lowercase thing um on the slide because this is
00:24:38.360 kind of what the industry uses um but in general n is public e is public D is
00:24:44.080 very private uh C is your your public text that you send out to the world and
00:24:49.320 N is uh private uh the problem is this only works for special values um so some of
00:24:56.960 the requirements are m to the power of E needs to be greater than n because if you start at that equation M the e n if
00:25:04.679 M the E is less than n the right hand side doesn't really do anything um it doesn't apply the mod uh
00:25:12.320 the modulus once so if you send out C if m to the E is too small an attacker can
00:25:18.520 just take C take the E root of it and they get the message back um so you solve that with padding now you have a
00:25:25.279 padding problem uh you can't just throw r ROM gibberish at the end of your message to make it bigger that's not
00:25:31.279 secure enough so you need to use something like the optimal asymmetric encryption padding scheme
00:25:37.919 OA um now that we've established that the message can't be too small it also
00:25:43.240 can't be too big uh there's also the coppersmith attack which basically says
00:25:49.000 if you send the same message to multiple recipients using the same encryption exponent uh an attacker would be able to
00:25:57.120 combine those linearly and figure out the message really quite simply um so
00:26:03.399 there's other crazy stuff too you can't have p and Q your initial prime numbers to be too close to each other otherwise
00:26:08.960 they're easily factorable um P minus one and Q minus one shouldn't have very only small prime factors uh Wiener's attack
00:26:17.240 uh happens when you have a small D that's my favorite line in the presentation there are timing attacks so
00:26:23.320 when you're doing all this modular arithmetic um if an attacker has a a
00:26:28.480 program running on the machine they can detect well it took a really short amount of time to do this operation so we can kind of figure like this happened
00:26:35.600 or it took long to do that um so it must be that um there's also just a whole
00:26:40.960 range of these things called um Cipher text and plain text attacks so you can have a chosen Cipher text attack an
00:26:47.880 Adaptive chosen Cipher text attack plain text attack it just goes on and on and on um you need to know what these things
00:26:54.039 are if you're going to implement RSA um going on Branch prediction analysis um if you uh see that the cach is
00:27:03.039 getting mixed uh missed or you assume that an if statement will evaluate to
00:27:08.440 true or false then you can start uh learning things about what the actual algorithm is doing um there's Quantum
00:27:15.679 prime factorization it's been proven that once we have quantum computers that are that are powerful enough that we can
00:27:21.840 solve the prime factorization problem in polinomial time this is huge no one's actually done it yet because it's really
00:27:27.640 hard to you know make the cubits work together um so it's not a problem yet but once we have computers that do that
00:27:34.440 anyone with enough money to buy one can just crack RSA um you shouldn't use a small n um
00:27:40.440 that would be bad so choose at least 2048 I would say just use
00:27:45.840 4096 so the moral of the story is don't implement this yourself there are so many ways to attack this that you are
00:27:52.159 going to fall into a pitfall so the second topic uh for asymmetric encryption is verifying your
00:27:58.640 authorship so let's say uh Alice and Bob have the public keys of each other because they've exchanged previously um
00:28:05.600 Alice wants to encrypt a message to send to Bob so she encrypts M with his public key she hashes the result of that and
00:28:13.919 encrypts that resulting hash with her private key then she sends both the the encrypted message and the the hash off
00:28:20.960 to Bob Bob decrypts this hash with Alice's public key and verifies that the hashes match and then Bob can enry the
00:28:28.440 message with his private key um there are vulnerabilities behind this as well most of them are the same as what I
00:28:35.399 explained earlier with asymmetric encryption um also you shouldn't be using the same public private key pair
00:28:40.840 for encryption as well as signing
00:28:49.360 yes yes
00:28:54.600 yes uh it's it's really a oneway function so so um if you take um a chunk
00:29:02.000 of text and then you run it through the algorithm with one exponent the only way
00:29:07.440 to get it back is with the other exponent so uh in the traditional scheme you would use the public key first and
00:29:14.360 it can only be decrypted with the the private key but you can instead encrypt something with the private key and it can only be decrypted with the public
00:29:23.360 key uh you have to pad the hash um same as before um in case m is too small um
00:29:31.240 moving on another place where you see signing is in certificates um and when
00:29:36.519 you like to talk about how https is working you usually say oh we're using SSL it's not actually SSL typically um
00:29:43.039 since 1999 you've probably been using TLS transport their security um and the
00:29:48.279 whole process behind that is enough for an entire talk so I won't get into it into it but the traditional way of uh of
00:29:55.039 SSL certificates and TLS certificates go is that the there's this standard called x509 and it's very hierarchical so you
00:30:02.960 have these root certificate authorities and they authorize you know children uh
00:30:08.559 certificate authorities and then it's all in a tree and so there's this chain of trust if you're given a certificate
00:30:14.919 um from eBay let's say you don't necessarily trust eBay so you look at the certificate and say oh it's been signed by veras sign I trust ver sign so
00:30:22.519 I must trust eBay um if you have lion there are about 175
00:30:28.519 certificate authorities already installed for you do you know those people there's one from the Hong Kong
00:30:34.519 post office did you know that you implicitly trust them I'm not saying that you shouldn't but I don't
00:30:41.080 know maybe look into it there's also poor revocation policies
00:30:47.159 you are capable of revoking a certificate let's say your private key got out um you are capable of sending
00:30:53.600 out a message across the internet basically to these repositories of certific get replication lists but the
00:30:59.279 browsers typically don't Implement them very well because that would make the experience of browsing too slow um and
00:31:06.399 also certificates in the SSL scheme are commercially exploited they have expiration dates on them and the reason
00:31:12.159 that they have expiration dates on them is twofold one because computers get fast so you want them to expire before
00:31:18.200 computers can hack them and two in case it gets out um in case your private key gets out you want it to eventually
00:31:24.720 expire so you don't have to keep telling people no don't trust that one no don't trust that one one and so once the expiration date goes past you don't have
00:31:30.880 to tell them that anymore commercial vendors however have decided that this is a great way to get money out of you
00:31:37.320 so uh the alternative is a web of trust model which is used by open pgp so a web of trust uh model uses a
00:31:45.720 directed graph which means that Alice can trust Bob this is no different than
00:31:51.720 x509 yet it it's also cyclic so Alice can trust Bob and Bob can trust Alice
00:31:58.519 and it's weighted so Alice can kind of trust Bob she knows Bob's you know an
00:32:04.679 okay computer user but she knows she he's not the the greatest um but Bob might think very highly of Alice and so
00:32:12.120 Bob places more trust into Alice so that Bob will implicitly trust anyone that Ellis trusts but Ellis would not trust
00:32:19.360 anyone that Bob trusts so that's kind of a cool feature um you don't need Casa in
00:32:24.399 this uh uh particular instance certificate authorities it's just kind of a web um the way you get this started
00:32:30.519 is with key signing parties where people get together say oh hi I'm Brad here's my public key will you sign it please um
00:32:38.480 kind of awkward but would you like to see my ID which is a problem for me because I lost it on the way here um and
00:32:46.159 there's also this High barrier to entry say you want to start doing this great you don't trust anyone yet so you can't
00:32:51.559 actually send any messages and nobody trusts you so this this is kind of a problem so you just kind of have to say
00:32:57.440 I'm going to do this I'm going to go do a bunch of uh key signing parties which by the way don't really exist um and
00:33:03.639 you're you're just kind of stuck without actually doing any of this so how am I doing on time am I like way past
00:33:10.279 already um no I think I'm good so Ruby implications um open SSL is built into
00:33:16.720 Ruby awesome uh so you can just do require op SSL I included open SSL
00:33:22.279 Cipher module here just for brevity um so let's say I want to use AES 256 with
00:33:28.240 a chain block Cipher um just create a new object I tell it okay I want you to to do encryption um generate and store a
00:33:36.760 random initialization Vector generate and uh and store a random key I want to
00:33:43.120 encrypt the W the the characters fub bang okay and then call final to to
00:33:49.440 apply the the padding and now you have a bunch of bits that um are usually not
00:33:55.279 printable so you usually want a base 64 and code those um and then decryption is
00:34:00.440 very similar uh you create an object you tell it okay you're going to do decryption you tell it what the
00:34:05.639 initialization Vector is the key and then you um update it with the crazy
00:34:11.040 weird string that is generally not printable and call that final and uh you get F bang
00:34:20.520 back and what about RSA um again pretty simple uh you just
00:34:25.839 call RSA new 49 wait a few seconds because it takes a while um and then let's say uh Bob gives
00:34:34.119 or Alice gives Bob her public key uh then on Bob's side he calls rs.
00:34:41.639 new with Alice's public key generates this public key object and then publicly encrypts Fu and generates some encrypted
00:34:48.879 blob and then he can send that off to Alice and then Alice can uh decrypt it
00:34:54.800 by using her private key to create an RSA object and then and doing a private decrypt on
00:35:00.119 it and all this padding stuff is automatically taken care of for
00:35:06.119 you open pgp um this is a problem in
00:35:11.760 Ruby Uh Kevin gesi gave a talk um a year and a half ago I think at Windy City rails possibly about how if you're going
00:35:19.839 to write a a library for Ruby or an open source uh tell people if you haven't finished it yet this is currently the
00:35:26.480 shipped version of open GP I'll give you a hint the decrypt method looks awfully
00:35:35.560 similar so this is a problem um so I'm I'm runting a gem
00:35:40.760 called ID KFA I haven't finished it yet um but it comes from the cheat code in Doom where it gives you all keys
00:35:47.720 firearms and ammunition I'm really concerned about the keys in this case so the purpose is to allow the encryption
00:35:55.240 encrypted embedding of sensitive information like pass passwords or API Keys into your code repository and it's
00:36:00.960 decryptable only by the authorized uh people or servers um so the anti- use case for ID
00:36:07.960 KFA is okay your app con uh connects to a database big surprise okay so that
00:36:13.680 means you got to keep the database. yo file out of the codeit story right um so
00:36:18.920 you have to send out updates uh to that file via SCP or sneaker net and then
00:36:24.920 boom your deploy fails because you forgot to update the server how many times is that has that happened to anyone before
00:36:32.240 yeah I'm just going to assume that none none of you other people actually write rails
00:36:38.160 apps so the use case for idkfa is that you're you check in
00:36:43.560 database. into your um into your uh your
00:36:48.839 code repository and it just has some Erb and this ID KFA method reads a file
00:36:55.880 that's also checked into your uh code repository and decrypts it assuming that you have the appropriate uh private key
00:37:03.720 in your home directory so you can grant access to other people to let them uh modify that
00:37:10.720 file um by using something like idkfa import and then take in their public key um you can update a server by saying ID
00:37:17.680 Cafe Heroku setup or ID Cafe UI setup um and its status is it has a really nice
00:37:24.280 read me it has some cues and some specs and and some code but not a whole lot um
00:37:31.680 I I wrote the I'm doing readme driven devel development on this and I started
00:37:37.079 I I've basically finished the readme and then in research doing research for this talk I realized that it's not quite
00:37:42.800 sufficient to be uh uh because it's actually susceptible to Cooper Smith's
00:37:48.280 or copper Smith's attack so um I need to modify that a little bit um So currently
00:37:54.880 it's unusable and um actually it set it has a very large image at the top of the read me that says stop don't use me so
00:38:02.800 um actually take heed when you see that so you've learned all about
00:38:08.720 encryption where do you start okay um my unofficial requirements
00:38:14.040 for um you're doing this these are just suggestions I'm not going to like bring
00:38:19.240 down the hammer on you if you don't do these um if you want to hack on idkfa that is the the cryptography part you're
00:38:25.160 working on the CLI stuff I'm sure all of you are capable but if you're going to actually touch the cryptography part um
00:38:31.280 you need to study for about 10 hours on on just cryptography in general um if you want to start your own gem that does
00:38:37.160 cryptography do 30 hours of study if you want to implement the mode
00:38:43.040 like CBC but different somehow um spend four years analyzing this stuff go to
00:38:49.160 all the cryptographic con uh conferences you need to learn a lot because what you
00:38:54.800 do is probably not going to work the first time um if you want to implement an algorithm another four years if you
00:39:01.240 want to design an algorithm it's going to take 10 years of study do to do that come up with it and once you come up
00:39:07.280 with that you can't use it for two years because you need you need to have other people hammering on it you need to put
00:39:13.119 on a paper you need to have people at a conference say this is a this is a great idea or this is a terrible idea this
00:39:19.440 these are the holes um so just assume that if you if you feel like designing the next AES it's going to be 12 years
00:39:26.359 before you're done also while you're doing that probably a good idea to get a
00:39:31.400 PhD um and again all these uh durations are revocable you know some of the
00:39:36.680 greatest cryptographers out there who have been doing it for 30 40 50 years still make mistakes so that just because
00:39:42.720 you've spent all that time studying doesn't mean that you're you're capable of producing this bulletproof
00:39:49.640 Cipher um also you should uh start listening to security now it's on the twit network um these are some of the
00:39:55.960 relevant episodes uh here are more of them total running time for all of those
00:40:01.359 episodes is 17 hours and 23 minutes some of it is uh like ads some of it is um uh
00:40:09.640 like uh like security roundups like Windows had another patch today um but
00:40:15.480 you should probably listen to all those before you start diving into some of this stuff um basically the idea I'm
00:40:21.800 trying to get across is that encryption is really hard um so if you want to start doing it start studying don't
00:40:28.000 necessarily start doing uh read rfc's uh read papers go to conferences
00:40:34.400 Etc um that's all I've got um you can get resources um credits all and
00:40:40.200 everything from there thank you any questions
Bradley Grzesiak
@bradg-vin
Explore all talks recorded at RubyConf 2011
+55