🚀 go-pugleaf

Death rays from Mars made shaun@octel.com (Attack of the Dayglo Howler Monkeys)
    write:
 
>Is there some way the public-key idea can be extended to handle a centralized
>distribution point?  That is, A sends a message to a redistribution point R,
>which forwards the message on to B, C, and D.  A performs encryption, and B,
>C, and D all decrypt the message and get authentication that it was from A as
>well.  R does nothing but redistribute, and contains no keys or encryption
>software.
 
Sure, it's not hard.  This feature is a standard part of PEM (which isn't
available yet, though), will be in the next version of PGP, and is already in
HPACK (a secure archiver I released recently).  The scheme they use is
generally identical, and works as follows:
 
  Normally, a public-key encrypted file/message/whatever actually consists
  of a PKC-encrypted key for a conventional cipher (called a DEK), which is
  then used to encrypt the actual message.
 
Lets say you have a PKC 'P', a conventional cipher 'E'.  Then the normal
PKC-encrypted message would be:
 
    P     ( DEK ) + E   ( message )
     userA           DEK
 
ie the DEK encrypted with the key of userA, followed by the message itself
encrypted with the DEK.
 
Extending this to allow multiple recipients is quite simple.  Just use:
 
    P     ( DEK ) + P     ( DEK ) + ... + P      ( DEK ) + E   ( message )
     userA           userB                 user n           DEK
 
When someone wants to decrypt this message, they look for the public-key
encrypted DEK packet which corresponds to their secret key, use the secret key
to decrypt the DEK, and then use the DEK to decrypt the message itself.
 
The advantages are obvious - it's great for doing things like secure mailing
lists, or anything which has to go to multiple recipients.
 
The disadvantages are that it's only as strong as the weakest link - if just
one of the secret keys are compromised then the DEK is revealed and anyone can
read the encrypted data - you have to make sure you trust everyone being sent
the data.
 
Peter.
--
 pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz
peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz
               (In order of preference - one of 'ems bound to work)