home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / crypt / 4923 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.7 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!guvax.acc.georgetown.edu!denning
  2. From: denning@guvax.acc.georgetown.edu
  3. Newsgroups: sci.crypt
  4. Subject: Re: A Copper Balloon
  5. Message-ID: <1992Nov17.082637.1780@guvax.acc.georgetown.edu>
  6. Date: 17 Nov 92 08:26:37 -0500
  7. References: <1992Nov7.142220.1683@guvax.acc.georgetown.edu> <BxKLDM.Mss@sneaky.lonestar.org>
  8. Distribution: world
  9. Organization: Georgetown University
  10. Lines: 53
  11.  
  12. In article <BxKLDM.Mss@sneaky.lonestar.org>, gordon@sneaky.lonestar.org (Gordon Burditt) writes:
  13. >>1.  Caller activates call.  All 3 parties generate a random x and
  14. >>exchange their values y = a^x mod p for some a and p.  All 3 parties
  15. >>generate the key k in the style of DH but with 3 exponents instead
  16. >>of 2.
  17. > 
  18. > You're proposing enough telephone-company equipment to be involved in
  19. > EVERY telephone call in progress at once.  This is VERY expensive.  If 
  20.  
  21. I'm not so sure.  Switches are involved in every call right now.  
  22. Also, the majority of calls are unlikely to be encrypted and key 
  23. negotiation only takes  place at the beginning of a call.  But this
  24. is a good point.
  25.  
  26. > the caller has to indicate that the call is encrypted, then he's not 
  27. > going to do it. 
  28.  
  29. Wouldn't the calling device have to send a bit saying "I'm starting an
  30. encrypted call" so that the called device would know that it's 
  31. receiving an encrypted call anyway?    
  32.  
  33. > Also, this prohibits (or doesn't handle) bulk, non-interactive encryption,
  34. > where the encryption is done well before the transmission.  This sort
  35.  
  36. Yes, the technique seems to mainly applicable to real-time phone calls.
  37. I believe this is the area of greatest concern to LE.  
  38. > 
  39. > Would you care to suggest a cryptographic protocol for activating
  40. > the devices only if there is a VALID warrant?  Assume that the government
  41. > 
  42. Let's say that a warrant has been obtained.  Then the telco would set
  43. a flag in the switch, say, indicating that your communications stream
  44. was to be intercepted.  The software in the switch would use this to
  45. determine whether to send a copy of your stream to the government
  46. monitoring station.  A similar strategy could be used to activate the
  47. crypto device.
  48.  
  49. > It would also appear that the 3rd party devices could be used to perform
  50. > a traffic analysis of all encrypted traffic, possibly without a warrant.
  51. > 
  52. The switches can do this already.  Indeed, I would suppose they do 
  53. some traffic analysis anyway for the purpose of resource analysis and 
  54. capacity planning.
  55.  
  56. > This proposal STILL doesn't deal with the possibility of encrypted
  57. > "plaintext", the possibility that the sender doesn't USE the agreed-on
  58. > session key, but uses a different one, and that you have to decrypt
  59. > the transmission to catch someone doing this.
  60.  
  61. Yes, this is a problem.
  62.  
  63. Dorothy Denning
  64. denning@cs.georgetown.edu
  65.