home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / sci / crypt / 4447 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.1 KB

  1. Path: sparky!uunet!think.com!rpi!zaphod.mps.ohio-state.edu!darwin.sura.net!guvax.acc.georgetown.edu!denning
  2. From: denning@guvax.acc.georgetown.edu
  3. Newsgroups: sci.crypt
  4. Subject: A Copper Balloon
  5. Message-ID: <1992Nov7.142220.1683@guvax.acc.georgetown.edu>
  6. Date: 7 Nov 92 14:22:20 -0500
  7. Distribution: world
  8. Organization: Georgetown University
  9. Lines: 59
  10.  
  11. I'd like to suggest another possibility, which for want of a
  12. better name I'll call the "copper balloon".  It's quite clear that key 
  13. registration goes over like a "lead balloon".  My question is: is this 
  14. any better?  worse?  I would also like to suggest that we keep this
  15. thread focused on this proposal and not on the merits/demerits of
  16. wiretapping in general.
  17.  
  18. The basic idea is very simple.  Use a 3-way Diffie-Hellman public-key
  19. exchange protocol to set up a session key for use with say DES 
  20. encryption.  The third party would be the service provider (actually
  21. equipment owned by the service provider), which would make the key
  22. available to law enforcement if a court order has been received and
  23. an intercept activated.   Here's a concrete scenario for telephone
  24. security devices:
  25.  
  26. 1.  Caller activates call.  All 3 parties generate a random x and
  27. exchange their values y = a^x mod p for some a and p.  All 3 parties
  28. generate the key k in the style of DH but with 3 exponents instead
  29. of 2.
  30.  
  31. 2.  If a tap has not been activated, the 3rd party would be a bit
  32. bucket.  The key would not be saved or distributed elsewhere.  Indeed 
  33. the third party might even play a slightly different game and issue
  34. a random y without even having generated an x.  
  35.  
  36. 3.  If a tap has been activated, the key would be delivered to the 
  37. government monitoring facilty along with the communications stream.
  38.  
  39. The idea for this came from several places.  First, encryption can 
  40. be used without the need for users or devices to have permanent
  41. secret keys.  For example, at least some telephone security devices 
  42. have no keys wired into them.  The session keys are negotiated at 
  43. the time of the call.  Diffie-Hellman does not require any concept
  44. of a permanent key.  Doug Jones posted a message earlier mentioning
  45. a scenario that would not use permanent keys.
  46.  
  47. Second, the trick is basically the same as used by Silvio Micali in
  48. fair cryptography, though he had 5 parties.
  49.  
  50. Third, someone (Carl Ellison?) suggested that it might be better to
  51. just record session keys rather than permanent keys.  Since the 
  52. session keys are what is ultimately needed, this sounds good to me.
  53.  
  54. Obviously this would not work with PGP or any form of RSA encryption
  55. which uses permanent keys.  So if such a strategy were used, it would
  56. constrain what protocols & methods could be used.
  57.  
  58. Like key registration, I expect it would be much harder to enforce on 
  59. computer nets that run software than telephone systems where you could 
  60. require that hardware products meet the basic requirements.
  61.  
  62. Assuming that the 3rd party devices were reliably constructed, this 
  63. would at least superficially provide more protection since no keys 
  64. would be kept unless a court order were issued.
  65.  
  66. OK, fire away.
  67.  
  68. Dorothy Denning
  69. denning@cs.georgetown.edu  
  70.