home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / sci / crypt / 2797 < prev    next >
Encoding:
Internet Message Format  |  1992-07-31  |  1.8 KB
  1. Path: sparky!uunet!stanford.edu!rutgers!psuvax1!fortran.cs.psu.edu!so
  2. From: so@fortran.cs.psu.edu (Nicol C. So)
  3. Newsgroups: sci.crypt
  4. Subject: Re: Padded Data
  5. Keywords: pascal crypt
  6. Message-ID: <Bs9J8t.EtI@cs.psu.edu>
  7. Date: 31 Jul 92 17:00:29 GMT
  8. References: <1992Jul31.135011.14195@dcs.glasgow.ac.uk> <1992Jul31.153719.28374@ncsu.edu>
  9. Sender: news@cs.psu.edu (Usenet)
  10. Organization: Penn State Computer Science
  11. Lines: 31
  12. Nntp-Posting-Host: fortran.cs.psu.edu
  13.  
  14. In article <1992Jul31.153719.28374@ncsu.edu> Webbge@che17.ncsu.EDU (Greg Earl Webb) writes:
  15. >
  16. >I've seen some interesting posts here recently, but I have yet to
  17. >see the topic of padding data with garbage.  It seems to me that
  18. >if you had an algorithm that would not only encrypt the data, but would
  19. >also insert random data into the original data (without following
  20. >a regular pattern) that it would be almost impossible for someone
  21. >to tell what was real information and what was just junk.  Although
  22. >the size of the document would increase, the difficulty in decrypting
  23. >the message would also increase considerably.
  24. >
  25. >The only problem I can see with this method is how do you insert data
  26. >in a non-regular pattern and still have the ability to remove it later.
  27. >Please comment on this type of procedure.  I'm sure people have thought
  28. >on these lines before and would be interested in seeing what they have
  29. >to say......
  30. >
  31. >            Greg Webb
  32. >
  33.  
  34. I have thought about this scheme at one point in time.  It is not
  35. difficult to implement but it is not superior to random padding.
  36. Actually it is less efficient.  One way to realize the scheme is to
  37. have a pseudorandom binary string which is derived from the encryption
  38. key, say:
  39.  
  40.     100111010100101010001110101010001...
  41.  
  42. If the i-th bit of this string is 1, the i-th symbol in the ciphertext
  43. is taken from the plaintext.  Otherwise, the i-th symbol is randomly
  44. chosen.
  45.