Brad's point about writing encryption software for Windows, as you often write email to people who use Windows, so you know your email is safe on *both* ends, has merit, and if Windows was at all secure I'd agree, but... Another point about this type of zero-UI encryption is that you don't actually know if your email will be secure, or just sent in clear (if you have a flag to tell, it isn't zero-UI).
A better idea is to minimise the UI, not bring it to zero. This has the disadvantage of making encrypted email less used, thus making encrypted traffic more of a target, but false security is worse than no security. I am writing m-o-o-t, which runs on a bootable CD and doesn't use Windows (OpenBSD based, same CD runs on PC's and Macs). You can only email another m-o-o-t user, though m-o-o-t does more than email. The email package is part of the system, and it doesn't allow even the stupidest or most intelligent user on either end to do anything insecure, within reason. It is transparent to the user except when needed, eg writing to a new correspondent (verify public keys) storing files (level of protection) or setting up (there are some things a new user must know). m-o-o-t will use something similar to Pete's message-keys-stored-on-a-server suggestion (actually DH keyparts), with the addition that the keyparts are signed. The 175-bit public signing key is included with every message, no long PGP strings, and I'm trying to convert the key to ascii art to make it more easily recognisable. Two shared keys are automatically and transparently set up for later communications, and the address book is updated. The shared keys are updated with each message. On a side note, there is no choice of cypher or protocol. The multiple cyphers and protocols used by PGP and GPG are the main cause of this thread! If encryption software writers can't decide which cypher to use they shouldn't be writing encryption software. As m-o-o-t is mainly designed for GAK resistance, all persistant keys (except some locally-used SFS keys) are used only for signatures. The use of persistant keys for encryption in both PGP and GPG make them unsuitable for GAK resistance, and if you haven't got GAK yet, you might get it someday, making all your present traffic insecure. -- Peter Fairbrother Pete Chown wrote: > John Gilmore wrote: > >> Brad Templeton has been kicking around some ideas on how to make zero-UI >> encryption work (with some small UI available for us experts who care more >> about our privacy than the average joe). >> >> http://www.templetons.com/brad/crypt.html >> > That's an interesting article. I wrote Whisper (http://234.cx/whisper.php) as > a different way of making crypto more usable. The idea is that you simply > agree a pass phrase with the correspondent beforehand. You then encrypt your > message with a small and hopefully bullet-proof program. It isn't innovative > cryptographically, and that is the point -- hopefully it is simple enough that > anyone with basic computer literacy can make it work. > > Of course the effect of Whisper is different to the zero-UI encryption. > Whisper provides you with good security (subject to weak pass phrases and > bugs), but you must agree a pass phrase beforehand. Zero-UI encryption is > more vulnerable to active attacks on the network, but works with much less > effort. > > One enhancement to the zero-UI model that I think might be worthwhile is > automated key exchange ahead of the first message. So when Alice asks to > email Bob, her computer first sends a message asking for Bob's key. When the > reply is received, Alice's original message is taken out of the queue, > encrypted and sent. This way the first message doesn't go across the network > in the clear. > > If we don't want to add another round-trip time, we could make keys available > from a key server. This would have the disadvantage that attackers could > compromise the key server and replace the keys with false ones. However, this > would be detected almost straight away if they could not modify communications > going directly between Alice and Bob -- Bob would receive a message that he > couldn't decrypt. Normally surveillance operations have to be kept secret so > this kind of attack would be impractical. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]