home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / sci / crypt / 6398 < prev    next >
Encoding:
Text File  |  1993-01-05  |  4.4 KB  |  90 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: Re: Another well-intentioned novice's question
  5. Sender: news@rchland.ibm.com
  6. Message-ID: <1993Jan05.160811.29681@rchland.ibm.com>
  7. Date: Tue, 05 Jan 1993 16:08:11 GMT
  8. Reply-To: lwloen@rchland.vnet.ibm.com
  9. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  10. References: <1993Jan04.051300.26089@rat.csc.calpoly.edu> <cfG9faf0Bwwb4F5T9z@transarc.com>
  11. Nntp-Posting-Host: wo0z.rchland.ibm.com
  12. Organization: IBM Rochester
  13. Lines: 75
  14.  
  15. In article <cfG9faf0Bwwb4F5T9z@transarc.com>, Lyle_Seaman@transarc.com writes:
  16. |> lwloen@rchland.vnet.ibm.com (Larry Loen) writes:
  17. |> > In the hypothetical example, compression moves the overall cost up
  18. |> > to 2 to the 60 from the original 2 to the 54.  That ain't chicken
  19. |> > feed, but it will probably not make a serious difference in overall
  20. |> > security, in the end.  If one can exhaustively break DES in a day,
  21. |> > having to wait 64 days will defeat some opponents, but others will be
  22. |> > just as happy on the 64th day as the first. 
  23. |> > 
  24. |> > Note, however, that the key technology remains breaking the basic DES.  Once
  25. |> > one can spring for a cost on the order of 2 to the 54th, it does not seem
  26. |> > like the typical opponent will run out of money at 2 to the 60th or that they
  27. |> > will not simply wait the extra time if they do.
  28. |> 
  29. |> Does it change the analysis if I substitute "month" for "day" above?
  30. |> "If one can exhaustively break DES in a month, having to wait a little
  31. |> over 5 years will defeat some opponents..."
  32. |>
  33.  
  34. Only at the margins.  You are correct, of course, that most DES opponents
  35. will fail in the example you cite.  There will be some cases, however, where
  36. waiting 5 years is still very worthwhile.
  37.  
  38. Also, if one substitutes "decade" for "day" above, then compression wasn't
  39. necessary at all, because it is rare data that needs to be secret for a decade
  40. and the fact that compression moves it up to 640 years is kind of ho-hum.
  41. Maybe the historians will lose out, but that's about it.  Besides, if computation
  42. continues to improve exponentially, it won't be 640 years, which means even
  43. the historians will eventually get a shot at it.
  44.  
  45. An increase in the work function is always a good thing; but compared to the base
  46. work factor of 2 to the 54, moving to 2 to the 60th isn't more than a marginal 
  47. improvement.  I'd rather go to multiple encryption and multiply by more like
  48. 2 to the 54th.
  49.  
  50. |> I have to imagine that it would defeat nearly all the opponents, since
  51. |> most of the data will be well-nigh worthless after 5 years.  Along the
  52. |> same lines, even governments can't necessarily spend 64X to complete
  53. |> a job which would otherwise require an expenditure of X.
  54. |>
  55.  
  56. Agreed.  But, that's the point.  Compared to the base cost of 2 to the 54,
  57. an added 64-fold increase may run the opponent out of budget.  But, if one is
  58. worried, why not add larger factors?  There is a lot of uncertainty surrounding
  59. work functions of attackers, after all.  One can never be sure that the cost
  60. to an opponent is entirely linear.  What if the cost is N log(N) and the
  61. compression only adds to the "log(N)" part?
  62.  
  63. |> In short, linear increases in complexity with sufficiently large
  64. |> constant factors may provide a better security enhancement than do
  65. |> exponential increases with small constant factors.
  66. |>
  67.  
  68. It depends on the cases, but you can certainly construct examples where this
  69. is true.  Question is:  Does it apply to the successful opponent, whose 
  70. technique you aren't sure of?  I'd rather go for exponential stuff, because
  71. it has higher odds of actually adding to the work.
  72.  
  73. |> Not a flame, just a nit.
  74. |>
  75.  
  76. But, an illuminating one, I think.  I claim, still, that compression should
  77. be done as an economy-of-transmission move and not a security move, per se.  If
  78. one fears that 2 to the 54th (or, whatever one presumes the work factor to be),
  79. isn't enough, one should enhance the _encryption_ by a large factor (>= 2 to 
  80. the 32 or so) and take any added security from compression (which isn't always 
  81. available anyway) as a bonus that one does not count on _as a matter of design_.
  82.  
  83. |> Lyle        Transarc        707 Grant Street
  84. |> 412 338 4474    The Gulf Tower        Pittsburgh 15219
  85. |> "I don't believe it!  I believe it, though..."     - kazar
  86.  
  87. -- 
  88.    Larry W. Loen        |  My Opinions are decidedly my own, so please
  89.                         |  do not attribute them to my employer
  90.