home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / sci / crypt / 3678 < prev    next >
Encoding:
Text File  |  1992-10-08  |  3.4 KB  |  78 lines

  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!wupost!cs.utexas.edu!milano!cactus.org!ritter
  3. From: ritter@cactus.org (Terry Ritter)
  4. Subject: Re: PGP *2.0* available
  5. Message-ID: <1992Oct8.064316.17440@cactus.org>
  6. Organization: Capital Area Central Texas UNIX Society, Austin, Tx
  7. References: <1992Sep7.142336.5733@ghost.dsi.unimi.it> <1992Oct7.224601.8915@qualcomm.com>
  8. Date: Thu, 8 Oct 1992 06:43:16 GMT
  9. Lines: 67
  10.  
  11.  
  12.  In <1992Oct7.224601.8915@qualcomm.com> karn@qualcom.qualcomm.com
  13.  (Phil Karn) writes:
  14.  
  15. >In article <17939.Sep2300.39.3792@virtualnews.nyu.edu>, brnstnd@nyu.edu
  16. >(D. J. Bernstein) writes:
  17. >|> In article <1992Sep20.195136.8642@cactus.org> ritter@cactus.org
  18. >|>(Terry Ritter) writes:
  19. >|> >  As far as I can tell, the whole point of cryptography is to be
  20. >|> >  able to restrict information to only those who are intended to
  21. >|> >  have it.
  22. >|>
  23. >|> That description is far too broad. You cannot singlehandedly restrict
  24. >|> information to a chosen recipient, because he can in turn give the
  25. >|> information to someone else. You pose an impossible problem; is it a
  26. >|> surprise that there are no solutions?
  27.  
  28. >Indeed. I've been making this point regarding anti-piracy devices for
  29. >some time. Even if Videocipher, for example, had not been broken there
  30. >would have been no way to prevent someone from taping the output of a
  31. >legitimate decoder and selling it or giving it away. The same is
  32. >undoubtedly true for software packages, at least those running on
  33. >standard general purpose machines. If you can't trust the authorized
  34. >user, then all bets are off.
  35.  
  36.  The rest of my original comment was:
  37.  
  38.     "When a public key "appears," it may really be a key
  39.     which was generated inside a spoofing node.  When one responds
  40.     to that key, one's response may be deciphered in the spoofing
  41.     node, then re-enciphered to the ultimate recipient.
  42.  
  43.     "Note that the recipient does, in fact, get the message.  One
  44.     can communicate in cipher.  The problem is that the spoofing
  45.     node gets to read all the communications.  So unless we actually
  46.     *intended* that there be a spoofing node, and that they should
  47.     read our messages, I think the cryptography has failed."
  48.  
  49.  
  50.  The reality that someone privy to a secret can betray it is
  51.  something most of us learned the hard way, before third grade,
  52.  and may have re-learned many times since.  This is not news.
  53.  
  54.  What *is* news is the idea that anyone would equate betrayal at
  55.  the other end with the possibility that a spoofer could *also*
  56.  be reading the mail and distributing it.
  57.  
  58.  Expressed perhaps a bit more clearly:  The *whole point* of
  59.  cryptography is to deliver information, *unexposed*, to the far
  60.  end.  Then, if the secret *is* exposed, at least you know it was
  61.  them (or you).  The ability to identify and eliminate channels
  62.  of exposure is a major part of security.  (No previous part of
  63.  this thread has concerned the broadcast distribution of secure
  64.  information.)
  65.  
  66.  If a spoofer *is* reading the mail (something well within the
  67.  range of a cracker, but which could easily be prevented by the
  68.  user), the system is *not* pretty good cryptography, it is not
  69.  even good cryptography, it is just *failed* cryptography.  Instead
  70.  of a fancy two-key cipher with a strong one-key data engine, it
  71.  might as well have been a modest homophonic substitution, or a
  72.  stream cipher with a little 32-bit LCG or LFSR.  But this would
  73.  *not* be real cryptography, it would be *toy* cryptography.
  74.  
  75.  ---
  76.  Terry Ritter   ritter@cactus.org
  77.  
  78.