News You Can Bruise for 2006 February 23 (entry 2)

(5) Thu Feb 23 2006 23:11: Today's cool things: Ruby encryption libraries! Crypt, which is pure Ruby, and EzCrypto, a wrapper around the user-unfriendly OpenSSL bindings. Dunno why I didn't think of an encryption recipe until so late in the project. Also, only today did I really put all the pieces together about how public-key encryption works. The only difference from single secret key encryption is that there are two ways of getting to the key. Is that right?

Update: I don't know anything.

Comments:

Posted by xtian at Fri Feb 24 2006 04:53

I think the basic bit is that they're asymmetric. You can encrypt with just the public key, but you need both keys to decrypt (because of the way the maths works - factorising and stuff).

Posted by Leonard at Fri Feb 24 2006 08:33

That could work too. The thing that confused me was that the crypto libraries had no support for different keys. It looked like you had to use the same key to encrypt and decrypt. But I guess you could arrange the keys such that one key could decrypt the output of another. The main thing I realized yesterday was that the encryption algorithms themselves have nothing to do with the keys.

Posted by Nathaniel at Fri Feb 24 2006 16:00

...looking at those libraries, perhaps the reason that they don't have support for different keys, is that they don't have support for any public key encryption algorithms?

Blowfish, GOST, IDEA, AES are all symmetric ciphers; for public key (asymmetric) stuff, you need completely different algorithms, like RSA or ElGamal.

I would actually be a little leery of putting crypto stuff into a cookbook, since there's this huge body of experience that says that basically no matter how careful you are, unless you're a serious crypto expert you're going to screw things up. (And if you're a serious crypto expert, you'll still screw things up half the time.) "Here's how to connect to a socket over SSL" would be cool, but anything where you start putting things together yourself is... very, very hard! For crypto to be worthwhile, you have to get _everything_ right, including finicky things like the algorithm you use to generate a key from a password, or what storage format you use for keys on disk, how you serialize the data you're going to encrypt, making sure that you use the actual ciphers in a secure way (most can be accidentally be used insecurely), making sure you have good randomness, making sure your keys don't get swapped out to disk and left there...

Plus probably a bunch more things, I don't really trust myself to write such code either :-).

Posted by Leonard at Fri Feb 24 2006 16:03

Well, hell. I was right about public-key encryption the first time.

Posted by Zack at Fri Feb 24 2006 18:31

Nobody in this thread seems to have described asymmetric key crypto the way I understand it to work... In asymmetric crypto, you have a pair of keys, P and Q. What you encrypt with P you can decrypt with Q, and vice versa. In typical use, you pick one of them to publish, keeping the other secret; hence people talk about the public key and the private key. But there's no functional difference between them.

It's really important that you can encrypt with either, because that's how digital signatures work: you take a secure hash of the document, and encrypt the hash with your private key. Anyone who has a copy of your public key can decrypt the hash and compare it to the hash they compute.

The other important thing to know about asymmetric crypto is that it's much too slow to use for more than a few hundred bits, so people tend to use it exclusively to encrypt random, single-use "session keys" for a faster symmetric cipher. This is why, for instance, SSH cipher modes mention both a symmetric and an asymmetric algorithm (AES/DSA, e.g.).