pertaining to this thread, i must give you some background information first. reading over my initial email, i noticed that my insisting on x being a private and k a public key might cause confusion in the light of my previous email on how public key encryption and signing works. what we are doing here is kind of independent, although then again it isn't. here's the background: signing a message[1] can really only be done with public keys. recall that signing is about integrity and authenticity. if you use a conventional symmetric algorithm[2], you don't have any form of integrity verification, as it is generally easier to modify an encrypted email to decrypt to something different, than it is to actually decrypt the message (this is the birthday paradox). so with symmetric algorithms, the recipient cannot be sure that what he obtained by decrypting is what the sender fed to the encryption engine on his side. you *do* have a light form of authenticity, because when seanius and i share a symmetric key that we use to encrypt messages to each other, then only messages from sean will be decryptable with that key. but it's very possible that someone else obtained the key from sean. moreover, once a third party obtains a symmetric key, s/he can listen in and take influence on the communication between two encrypting parties. [ 1. which does not have to be an email. it could be something as granular as an IP packet (c.f. IPv6) 2. DSA, RSA, ElGamal are asymmetric algorithms as the key used to decrypt is different from the key used to encrypt. (3)DES, CAST, IDEA, Blowfish, AES, and Caesar are symmetric algorithms, as you use the same key to encrypt and decrypt. can you see disadvantages of that? ] finally, sean and i have a problem, because we have to meet at one point to agree on a passphrase to use for our encryption channel. once that's compromised, we have to meet again (or employ a secure channel == impossible). so why even bother with symmetric encryption? well, the answer is simple: it's between 1000 and 10000 times faster than asymmetric encryption. for emails, this doesn't really matter, the payload is so small and encrypting an email message is not a time critical action, so GPG may actually go ahead and encrypt with ElGamal as i've shown in my previous email. but when you think about virtual private networks - that's basically two firewalls encrypting all traffic between them, it becomes a very time-critical thing with a large payload. using an external parallelized VLSI chip for symmetric encrytion, the CHeck Point Firewall-1 (market leader) has an encryption throughput of 3.2 Gbit/s. this would reduce to between 3.2 Mbit/s and 320 Kbit/s were it to use asymmetric encryption; unacceptable. any real-time application uses symmetric encryption these days for precisely the speed advantage. the question is, how to attain integrity, authenticity, and privacy all at once, given the problems i introduced in the example of sean and i? and the first part of this answer is what this game is all about: how to agree on a symmetric encryption key without exchanging any information that should be kept private. not many have sent in their k, but whatever, the show must go on. you can always join later. what we're doing here is the 30 year old Diffie-Hellman key exchange algorithm. and public/private key pair has a mathematical relationship just like this one is k = g^x mod p. the important thing is simply that obtaining x from k (the discrete logarithm) is made so difficult that trying it is useless. let's see. go and ask some other participant (or multiple others) to establish a passphrase with you. then, on both sides you calculate: s = k^x mod p where x is *your* private key and k is *his/her* public key. the resulting s will be the same on both sides. to verify this, employ and algorithm that prevents both sides from cheating (this is simplified and not at all part of the diffie-hellman key exchange. but it's another cool and rather handy application of cryptography). - correspondent A does: `echo 34 | md5sum` he sends the result "fd1bc138d22d4f78150c6e808345c2cc" to the other side. - correspondent B sends his s to A - correspondent A sends his s to B - correspondent A compares his s with B's s. if they match, then noone cheated. - correspondent B compares the md5sum of A's s with the md5sum he received in the first step. if they match, noone cheated. - correspondent B compares his s with B's s both s are the same, and noone could cheat. note that cheating is defined as trying to obtain the other's s without disclosing his own or trying to cheat the other party into thinking that one has the s without really having it. obviously, cheating is not just randomly changing a number for the sake of breaking the protocol. anyway, now both have the same value without ever having exchanged any information that would allow a third party to obtain that value: x and y (the two private keys) never crossed the wire. i leave it to you to figure out why this works, it's really not hard. now paste this into your shell (this is a *very* simplistic symmetric encryption algorithm known as caesar encryption): (i wish i was eric and could do this in one line of perl. the following is pretty ghetto...) alphabet_lower=abcdefghijklmnopqrstuvwxyz alphabet_upper=`echo $alphabet_lower | tr "[a-z]" "[A-Z]"` function rotx() { local offset=`expr $1 % 26 + 1` test $offset -lt 1 && offset=`expr 26 + $offset` rot_lower1=`echo $alphabet_lower | cut -c$offset-26` rot_lower2=`echo $alphabet_lower | cut -c-\`expr $offset - 1\`` rot_upper1=`echo $alphabet_upper | cut -c$offset-26` rot_upper2=`echo $alphabet_upper | cut -c-\`expr $offset - 1\`` echo "${rot_lower1}${rot_lower2}${rot_upper1}${rot_upper2}" } function caesar() { local offset=$1; shift echo $* | tr ${alphabet_lower}${alphabet_upper} `rotx $offset` } and then finally encrypt a message to your encryption peer using the following syntax: caesar your message here ... caesar 35 only you can read this... xwuh hxd ljw anjm cqrb... if you receive an encrypted message, decrypt it with the -s: caesar -35 xwuh hxd ljw anjm cqrb... only you can read this... bingo. (yes, i know that others can actually brute force this rather easily. go ahead and implement Rijndall/AES-256 on the shell if you want good security ;^>) now implement something like the Oakley/ISAKMP protocol to coordinate frequent recreation of session keys and you get privacy. authenticity is established through a shared s provided that integrity is secured, and the latter you can easily do by attaching an md5sum of the original data to each encrypted message. finished. i think that diffie-hellman rocks. so please accept my apology for abusing this forum to share my enthusiasm with the world. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck micro$oft encrypts your windows nt password when stored on a windows ce device. but if you look carefully at their encryption algorithm, they simply xor the password with "susageP", Pegasus spelled backwards. Pegasus is the code name of windows ce. this is so pathetic it's staggering.