From: anonymous@extropia.wimsey.com
Date: Thu, 5 May 94 19:22:43 PDT
To: cypherpunks@toad.com
Subject: No Subject
Message-ID: <199405060210.AA16657@xtropia>
MIME-Version: 1.0
Content-Type: text/plain


-----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-----