new crypto stuff for faster + smaller messages

On prompting from various people (hez, thecrypto, nop, and my conscience),
 here's a new way to handle encryption for messages.  
Brief summary:

<jrand0m> basically, payloads either start with the ElG encryption of
the session key, 
          or they start with a 32byte session tag (where session tags
are never reused).  
          messages with a known unused tag are decrypted with AES (with
some verificatino 
          stuff), or if they don't match an unknown tag, they're decrypted
with ElG+AES as 
          before.  all messages can contain a set of 32byte tags for
future use too.  

<jrand0m> in the first message sent to a destination from a destination,
 the ElG includes the 
          session key.  within the payload of that message is a set of
0-256 session tags, 
          where each tag can be used on subsequent messages. 

<jrand0m> within the payload of tagged messages (messages starting with
a tag, not with an 
          ElG of the session key), there can be new tags as well 

Here's the specifics I'm adding to the spec:

*******************
Payload:
 The first 8 bytes make up an Integer specifying the number of 
 bytes in the Payload data structure (including these first 8 bytes).
 
 After that, one of two scenarios can occur.

 If the next 32 bytes are not equal to a known and unused session tag,
 
 as defined by a previous message, the first scenario takes place.  
 Otherwise, the second takes place.

 Scenario 1: unknown session tag, or incorrect hash of session key
  The first 512 bytes after the 8 byte payload structure size is decrypted

  with ElGamal (containing 256 unencrypted bytes).  The first 32 bytes

  unencrypted make up the SessionKey.  The rest of the cleartext is random

  data.  Following that is the rest of the payload decrypted with the
AES 
  SessionKey:
   The content starts with a 2 byte Integer specifying the number of
   session tags that follow.  After that comes that many 32 byte random

   Integers that act as session tags.  After that comes an 8 byte 
   Integer specifying the real size of the body of the payload to follow.
 
   Then comes the Hash of the the unencrypted body, for verification.
 The 
   remainder is the actual body of the message, padded with random bytes
to 
   match the size specified in the first 8 bytes.

 Scenario 2: known session key, known unused session tag
  The remainder of the payload is considered to be encrypted with the

  SessionKey from the message in which the session tag was specified.
  The remainder is decrypted with that key and it contains:
   The decrypted body starts with a Hash of the 
   SessionKey in use.  If this doesn't match the one in use, then 
   scenario 2 is aborted and the message is treated according to scenario
1.  
   If it does match, then the processing continues, where the rest of
the 
   decrypted body is the same as defined in scenario 1.

Session tags recieved should be kept for 1 hour after being recieved,
 or until they 
are used (whichever comes first).  Once a session tag is used or the
time has passed, 
it should be discarded and further messages should not be checked for
that tag.  The 
client APIs implementing the session tagging and verification may keep
a list of tags that
have been used with a particular session ID and make sure the other party
doesn't try to 
reuse a session tag.  Note: for extremely slow transports, extremely
paranoid people (using 
many tunnel hops), or any other scenario where a message may take more
than an hour to be 
recieved, the client APIs should use scenario 1 exclusively.

*******************

Important:
To the observer, there should be no way to tell whether the message begins
with a session tag or an 
ElG cypher.  If this isn't the case, an observer can tell that some destination
somewhere is 
recieving follow-on traffic.  Since session tags change constantly, there
is no way for an observer
to know what session a tagged message belongs so (even *if* they were
able to detect a tagged vs
ElG'ed message)

I'm adding this to the spec now.  Speak now or hold your piece until
you want to speak later.
Also, I'm adding the SignaturePublicKey and SignaturePrivateKey structures
(which are the keys used
for DSA signatures), and placing them on appropriate structures.

-jrandom



Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427