home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / crypt / 4978 < prev    next >
Encoding:
Text File  |  1992-11-18  |  4.2 KB  |  106 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!caen!malgudi.oar.net!chemabs!jac54
  3. From: jac54@cas.org ()
  4. Subject: Re: Attack Methods
  5. Message-ID: <1992Nov18.194435.18141@cas.org>
  6. Sender: usenet@cas.org
  7. Organization: Chemical Abstracts Service, Columbus, Ohio
  8. References: <1992Nov11.213535.17788@csc.ti.com> <1992Nov18.134243.24089@qiclab.scn.rain.com> <1992Nov18.190513.10997@cis.uab.edu>
  9. Date: Wed, 18 Nov 1992 19:44:35 GMT
  10. Lines: 94
  11.  
  12. In article <1992Nov18.190513.10997@cis.uab.edu> sloan@cis.uab.edu (Kenneth Sloan) writes:
  13. >In article <1992Nov18.134243.24089@qiclab.scn.rain.com> Leonard.Erickson@f51.n105.z1.fidonet.org writes:
  14. >>jdailey@dadd.ti.com (Jim Dailey) writes:
  15. >>
  16. >>>So what are some of the methods used to attack an encrypted text, when the
  17. >>>encryption method is unknown?
  18. >>
  19. >>First you run frequency tests. This will tell you *immediately*
  20. >>if a "reasonably sized" text was encrypted via *any* character
  21. >>transposition cipher.
  22. >
  23. >This thread is at about my speed - so I'll toss in a question.  I'm sure
  24. >that this is hopelessly naive - but I hope someone will tolerate the
  25. >question long enough to answer it.
  26. >
  27. >Suppose that I have a character transposition cipher.  Will the
  28. >following scheme make it appreciably stronger (or weaker?):
  29. >
  30. >To encrypt:
  31. >
  32. >    0) compose the message
  33. >    1) add (to both the front, and the back) additional characters,
  34. >       chosen to produce a flat histogram.  Pseudo-randomize, as needed.
  35. >       Perhaps also pad to a standard size block?
  36. >       Perhaps randomize the positioning of the message within the block?
  37. >       Perhaps break the original message into bite-sized pieces and
  38. >       include additional material between bites as well as at the
  39. >       beginning and end?
  40. >    2) apply the character transposition cipher.
  41.  
  42.     Read the article the"Two Soviet Spy Ciphers" by David Kahn in
  43.     "Kahn on Codes".  The system used by Hayhanen did several of
  44.     these things and, if I remember correctly, everything was
  45.     susbtituted first.  Another common ploy is to split the message
  46.     down the middle and put the last part first, thereby hiding
  47.     the standard beginnings and endings.  Despite all this, I think
  48.     the transposition would fall to multiple anagramming fairly
  49.     quickly.  Somebody very patiently explained to me that
  50.     transpositions are considered very weak these days.
  51.  
  52.     Incidentally, the Soviets seem to have put a lot of effort
  53.     into putting field-expedient ciphers together so that they
  54.     wouldn't forever be delivering one-time pads to their
  55.     people.
  56.  
  57. >to decrypt:
  58. >
  59. >    0) reverse the transposition
  60. >    1) rely on the reader (either human or otherwise) to recognize
  61. >       the start and end of the original message (or the multiple starts
  62. >       and ends of message bites).
  63. >
  64. >One weakness which springs to mind is that absolutely flattening the
  65. >character histogram may cause an unacceptable increase in the size of
  66. >the transmitted message.  Perhaps this is what was intended by the
  67. >qualification ``"reasonably sized"'' above?
  68. >
  69. >A (probably foolish) complication which springs to mind is to:
  70. >
  71. >    *restrict words in the message to a pre-defined lexicon
  72.  
  73.     I wouldn't do this, it weakens the transposition considerably.
  74.  
  75. >    *break up the original message on word boundaries
  76.  
  77.     See above, the Hayhanen system used letter counts rather than
  78.     word boundaries (safer).
  79.  
  80. >    *add "histogram-flattening" characters between words (instead of
  81. >     whitespace?)
  82.  
  83.     Lots of nulls in this one! (To quote the Queene's Decypherer).
  84.  
  85.  
  86. >    *ensure that no "allowed words" are generated accidently
  87. >    *have the decrypting process find the "allowed words" among
  88. >     the random garbage (after reversing the transposition)
  89. >
  90. >Assuming that the message has been appropriately un-transposed, it
  91. >should be simple enough for the intended receiver to find the allowed
  92. >words, and hence the original message.  The question is: does this give
  93. >the enemy too large a lever on cracking the transposition cipher?
  94. >
  95. >       Yes, see above.
  96. >
  97. >       Alec Chambers
  98. >
  99. >--
  100. >Kenneth Sloan                   Computer and Information Sciences
  101. >sloan@cis.uab.edu               University of Alabama at Birmingham
  102. >(205) 934-2213                  115A Campbell Hall, UAB Station
  103. >(205) 934-5473 FAX              Birmingham, AL 35294-1170
  104.  
  105.  
  106.