home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / sci / crypt / 6344 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  3.0 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!rutgers!network.ucsd.edu!qualcom.qualcomm.com!servo.qualcomm.com!karn
  2. From: karn@servo.qualcomm.com (Phil Karn)
  3. Newsgroups: sci.crypt
  4. Subject: Re: Ciphers
  5. Message-ID: <1993Jan4.110356.23995@qualcomm.com>
  6. Date: 4 Jan 93 11:03:56 GMT
  7. References: <R90TwB1w165w@west.darkside.com>
  8. Sender: news@qualcomm.com
  9. Organization: Qualcomm, Inc
  10. Lines: 46
  11. Nntp-Posting-Host: servo.qualcomm.com
  12.  
  13. In article <R90TwB1w165w@west.darkside.com> sspy@west.darkside.com (mshannon) writes:
  14. >Another question, gentlemen. Suppose someone, the feds or whoever, hace 
  15. >an encrypted disk that they want to crack, but they don't know what 
  16. >cipher was used. How can they find out. Are there programs that will 
  17. >analyze it and make this determination based on the way certain ciphers 
  18. >cipher?
  19.  
  20. In general, no. By itself, any good cipher produces ciphertext that is
  21. indistinguishable from purely random bits by anyone who doesn't know
  22. the key.  In practice, however, many encryption packages format their
  23. ciphertext output to make it easy for the intended recipient to
  24. recognize as a message encrypted with that particular package. This
  25. will tip off an eavesdropper that a particular system and possibly a
  26. particular set of keys are in use (implying the identities of the
  27. correspondents), even if he can't actually crack the contents.
  28.  
  29. For example, PGP puts out the "BEGIN PGP MESSAGE" banner, and it
  30. specifies the public key that was used to encrypt the message so the
  31. receiving program knows which of possibly several secret keys to use
  32. to decrypt it. Anyone with a reasonably complete public key collection
  33. can see who an intercepted message is addressed to, at least at the
  34. outermost level (it might contain several levels of encapsulated
  35. encryption, as in some of the anonymous remailer schemes).
  36.  
  37. Other encryption packages, such as Sun's 'des' command (and the one I
  38. wrote that's compatible with it) produce *no* identifying information
  39. in the ciphertext -- it looks like purely random bits. This has the
  40. advantage of denying an eavesdropper knowledge of the system you're
  41. using, but it has the disadvantage that the user must know, a priori,
  42. which algorithm and key to use to decrypt it. This is okay in a single
  43. key cryptosystem (you could consider the algorithm specifier to be
  44. part of the "key" that you exchange ahead of time) but it is not
  45. practical in a public key cryptosystem, which is supposed to let you
  46. send encrypted messages to someone without special prior arrangement.
  47.  
  48. On the other hand, it would not be hard to take that little bogus PGP
  49. ciphertext generator I posted the other week and go much farther with
  50. it. It could produce a properly formatted PGP message, with correct
  51. checksums, etc, that causes PGP on the receiving end to prompt for a
  52. totally random and fictictious key. To an eavesdropper, such messages
  53. would be indistinguishable from real PGP messages encrypted with
  54. unknown public keys. One could conceive of generating continuous
  55. streams of such traffic just to provide some haystacks in which to
  56. hide your needles.
  57.  
  58. Phil
  59.