home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2923 < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.4 KB  |  64 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!wo0z!lwloen
  3. From: lwloen@rchland.vnet.ibm.com (Larry Loen)
  4. Subject: Missing subject header
  5. Sender: news@rchland.ibm.com
  6. Message-ID: <1992Aug17.222410.10011@rchland.ibm.com>
  7. Date: Mon, 17 Aug 1992 22:24:10 GMT
  8. Reply-To: lwloen@vnet.ibm.com
  9. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  10. Nntp-Posting-Host: wo0z.rchland.ibm.com
  11. Organization: IBM Rochester
  12. Lines: 50
  13.  
  14. In article <1992Aug12.185029.13607@mintaka.lcs.mit.edu> Eric Knight writes:
  15.  
  16. >Yes, I was attempting to create an encryption that would become
  17. >I/O bound as the limit to its speed.  Most other systems become
  18. >CPU bound (DES, great example.)  I/O is significantly slower than
  19. >CPU and that causes problems repeatitively trying to guess it.
  20.  
  21. Well, we're all for a fast system. Speed is, unfortuately, one of the later design
  22. criteria.  The system has to take a LOT longer to solve than it does to encrypt. 
  23. If breaking it takes only 100,000 times as long to do as encrypting it, then it
  24. will be a failure in virtually any application I can imagine.  If it doesn't work,
  25. fast run time will not be impressive.
  26.  
  27. Cryptography has great appeal to any number of people.
  28. It looks so easy!  And, indeed.  Nothing is easier than proposing a new
  29. encryption algorithm.  Nothing is harder than figuring out whether it is any
  30. good.
  31.  
  32. I am hardly the top gun in the universe on this topic, but I have learned
  33. a considerable respect for the need to study it.  It is very highly probable
  34. that unless you get out and study a bit, you will produce a system that 
  35. runs fast, scrambles the data impressively to the eye, with cipher output 
  36. output passing all kinds of statistical tests for randomness, has a 500 gabillion
  37. bit keyspace, but can be solved by someone you've never heard of that knows what
  38. they are doing.  Oh, yes.  The system did stump me and all your friends, too.  Just
  39. didn't stump the guy you really needed to fool.  The history of cryptography
  40. simply abounds with examples of this.  Read "The Codebreakers" by David Kahn
  41. (in most libraries and quite good).
  42.  
  43. I also highly recommend that you acquire some experience in breaking cryptography
  44. systems.  There are no scientific proofs for what makes a system good.  Lots of
  45. mathematical things hold "in general", but fall apart because some niggling little
  46. special case comes up that an attacker can expect to exploit sooner or later,
  47. and that brings the whole edifice down.  There's even a semi-formal name for
  48. this.  It's called "entering" the cipher and once you have done so, a great 
  49. percentage of systems slowly but surely break as a whole.  Or, enough to
  50. steal the PIN on someone's ATM card or the like.  
  51.  
  52. Unless you have broken quite a few of the nontrivial, classical cryptography
  53. systems, your chances of developing something good are pretty small.  There's
  54. so many things you have to guard against.  And, only practical experience and
  55. lots of study will give you a clue as to what they are.  Do you know whether
  56. your system is vulnerable to various forms of advanced mathematics?  Do you
  57. know, given that a lot of data is boilerplate and may be correctly guessed,
  58. how many bits of data that have to be guessed to defeat you?  It's a long list,
  59. and I've only typed in a little bit of it. . .
  60.  
  61. -- 
  62.    Larry W. Loen        |  My Opinions are decidedly my own, so please
  63.                         |  do not attribute them to my employer
  64.