Practice Cryptography!
Even with all of the cryptologic and cryptographic technology that has existed in the world for the past 60 years, we still don't really know what encryption is good for or how to use it -- or, more importantly, why it's important. Maybe it's time for people and coders to actually start practicing how to use it, like any other skill.Tuesday, April 25, 2006
Xfire and the ideas it has...
An engineer at Xfire has had the idea of using GPG keys (aka OpenPGP keys) to provide a mechanism for authenticating the other end of a given traffic exchange. Absolutely lovely idea (and he's even familiar with Diffie-Hellmann key negotiation, which is another plus). However... I'm not quite sure he understands what a "hybrid" cryptosystem is.
As with anything cryptographic, it's not going to be easy to create a system that is resistant to all forms of attack. Nor is it going to be easy to do session key negotiation. See, GPG uses an asymmetric key to encrypt a symmetric key, which it uses to encrypt the message -- and which it then sends with the message. This means that the possibility exists, in the worst case, that every message will be encrypted with a different symmetric key. (How much work is involved in decrypting that key, and then decrypting the message? Enough that you'd notice, playing a first-person shooter.)
It would be better, in my opinion, to use fairly long-lived symmetric encryption keys. On the first connection from one system to another, do the key agreement (and thus identity verification). After that, use the agreed-upon key to do the bulk encryption, until it expires, and then go through the key-agreement again -- preferably within the current bulk encrypted channel.
As with anything cryptographic, it's not going to be easy to create a system that is resistant to all forms of attack. Nor is it going to be easy to do session key negotiation. See, GPG uses an asymmetric key to encrypt a symmetric key, which it uses to encrypt the message -- and which it then sends with the message. This means that the possibility exists, in the worst case, that every message will be encrypted with a different symmetric key. (How much work is involved in decrypting that key, and then decrypting the message? Enough that you'd notice, playing a first-person shooter.)
It would be better, in my opinion, to use fairly long-lived symmetric encryption keys. On the first connection from one system to another, do the key agreement (and thus identity verification). After that, use the agreed-upon key to do the bulk encryption, until it expires, and then go through the key-agreement again -- preferably within the current bulk encrypted channel.
Archives
2006-02-12 2006-02-19 2006-02-26 2006-03-05 2006-03-12 2006-03-19 2006-03-26 2006-04-02 2006-04-09 2006-04-16 2006-04-23 2006-07-23 2008-01-13 2008-01-20 2008-02-03 2008-02-17 2008-03-16 2008-04-06 2008-05-11
