-----BEGIN PGP SIGNED MESSAGE----- Hello everyone! This is a preliminary document which I hope will stir discussion. I didn't write it in order to dictate rules to anyone, so please don't flame me. Hopefully the members of the list will supply lots of feedback! -Lady Ada - ---------------------------------------------------------- Introducting The Cypherpunk Standard For Encrypted Phones (CSEP) Purpose: Encryption software is a form of communication tool. Like other communication systems, it is useless without someone to talk to who shares the same protocol. It appears likely that various forms of encrypted phones will spring up in the near future, ranging from PC and SoundBlaster-based software to simple hardware phones. Now is the time for us to agree on protocols, so that all cypherpunk-built phones can talk to each other. Disclaimer: "But," you say, "Phil Z. is already working on VoicePGP. Why not wait until he releases it and let that be the standard?" Well, I'm not trying to undercut Phil, and I certainly hope that we will be incorporating his protocols into a future version. But I don't think we should let a single product drive all future design. Let's think about the future now. Isn't it better to hash out potential problems in a public forum? Basic Standard - -------------- - -- Diffie-Hellman for key exchange - -- Triple DES for data encryption - -- RSA for digital signatures/identity verification Rationale: Unlike encryption protocols designed for email, a phone system will need to exchange public keys bidirectonally at the beginning of every call, and the existance of an insecure two-directional link can be assumed. Diffie-Hellman is perfect for this application. The alternative, RSA, would require either generation of new keypairs at call time, which is very slow, or the long-term association of a keypair with a specific phone, which provides no benefit to the user and opens a possible path of attack (though not a major one) to eavesdroppers. Also, the patent on Diffie-Hellman expires in 1997, well before the 2000 expiration date of RSA. The information available to me appears to indicate that Triple DES is not significantly more vulnerable than IDEA or other popular algorithms, and it has the advantage of not being patented. I would like to see this standard keep possible future commercialization in mind. I suggest that the TDES implementation should use three different independent keys. IDEA might be offered as an option for those who prefer it. Compression - ----------- It's probably wise to standardize on a particular compression scheme. I have no opinions on this subject and welcome input. The most important feature is speed, not efficiency of compression. Other Features Required for Secure Phones - ----------------------------------------- Each phone shall have a button (hard or soft) which can be pressed by the caller at any time. Pressing it will cause a new TDES key to be generated and exchanged. [Should it generate a new n and g for D-H, or just create a new x and demand a new Y?] Paranoid users can press this button every few seconds if they wish. (In my humble opinion, even a single-DES phone is quite secure if it has this feature.) Other possible options - ---------------------- In some cases it may be desirable to confirm that the call recipient is really the person you wish to speak to. This could be implemented by allowing the phone to store RSA private keys (one for each user) and public keys (to test for other users). These signature keys should be independent of the encryption keys. The phone would require the user to enter a code [of what length?] which would act like the passphrase of PGP, preventing anyone from impersonating another user even if the would-be impersonator had access to the victim's key and phone. Control Codes - ------------- A number of control codes are needed for commands passing between the two phones. Not only the definitions of the codes but the values must be agreed upon by all users. Each of these will be associated with a defined packet that contains the appropriate data. GENNEWKEY [send x, request Y] DATA [send actual packet of data, request ACK] DATAACK [acknowledge data packet with checksum] - -------------------------------------------------------- OK, I admit it, this is pretty minimal, but hey, it's a beginning. Please send comments to the list. Phil Z, if you're out there reading this, I'd particularly like your input. -Lady Ada -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLclivqXNQdJx1hMZAQGq2wP/fcq5gp8unZhy/cog3jpdI8wA3hJORzME ul4qdnu5dOP7ON3LmlsWPeymUlagI1oUtJOUxb5LQ9lAlQMWv7u3TJDj3tqftcu3 il8fVmdIxrf8FYDbhs5GppCcfsMaz2/ervsw9cICspFPQJOKTOWzzTMuUYyoqcYa hWH/OJhMmPw= =coxy -----END PGP SIGNATURE-----