home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / sci / crypt / 5624 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  2.6 KB
  1. Path: sparky!uunet!wupost!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!pgut1
  2. Newsgroups: sci.crypt
  3. Subject: Re: Multi-way encryption/FAQ/archives?
  4. Message-ID: <1992Dec12.234910.7347@cs.aukuni.ac.nz>
  5. From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
  6. Date: Sat, 12 Dec 1992 23:49:10 GMT
  7. References: <1992Dec10.184723.6236@octel.com>
  8. Organization: Computer Science Dept. University of Auckland
  9. Lines: 51
  10.  
  11. Death rays from Mars made shaun@octel.com (Attack of the Dayglo Howler Monkeys)
  12.     write:
  13.  
  14. >Is there some way the public-key idea can be extended to handle a centralized
  15. >distribution point?  That is, A sends a message to a redistribution point R,
  16. >which forwards the message on to B, C, and D.  A performs encryption, and B,
  17. >C, and D all decrypt the message and get authentication that it was from A as
  18. >well.  R does nothing but redistribute, and contains no keys or encryption
  19. >software.
  20.  
  21. Sure, it's not hard.  This feature is a standard part of PEM (which isn't
  22. available yet, though), will be in the next version of PGP, and is already in
  23. HPACK (a secure archiver I released recently).  The scheme they use is
  24. generally identical, and works as follows:
  25.  
  26.   Normally, a public-key encrypted file/message/whatever actually consists
  27.   of a PKC-encrypted key for a conventional cipher (called a DEK), which is
  28.   then used to encrypt the actual message.
  29.  
  30. Lets say you have a PKC 'P', a conventional cipher 'E'.  Then the normal
  31. PKC-encrypted message would be:
  32.  
  33.     P     ( DEK ) + E   ( message )
  34.      userA           DEK
  35.  
  36. ie the DEK encrypted with the key of userA, followed by the message itself
  37. encrypted with the DEK.
  38.  
  39. Extending this to allow multiple recipients is quite simple.  Just use:
  40.  
  41.     P     ( DEK ) + P     ( DEK ) + ... + P      ( DEK ) + E   ( message )
  42.      userA           userB                 user n           DEK
  43.  
  44. When someone wants to decrypt this message, they look for the public-key
  45. encrypted DEK packet which corresponds to their secret key, use the secret key
  46. to decrypt the DEK, and then use the DEK to decrypt the message itself.
  47.  
  48. The advantages are obvious - it's great for doing things like secure mailing
  49. lists, or anything which has to go to multiple recipients.
  50.  
  51. The disadvantages are that it's only as strong as the weakest link - if just
  52. one of the secret keys are compromised then the DEK is revealed and anyone can
  53. read the encrypted data - you have to make sure you trust everyone being sent
  54. the data.
  55.  
  56. Peter.
  57. --
  58.  pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz
  59. peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz
  60.                (In order of preference - one of 'ems bound to work)
  61.  
  62.