home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / crypt / 5090 < prev    next >
Encoding:
Text File  |  1992-11-20  |  1.8 KB  |  49 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!aixproj!uri
  3. From: uri@watson.ibm.com (Uri Blumenthal)
  4. Subject: RSA FAQ & Differential Cryptanalysis
  5. Sender: news@watson.ibm.com (NNTP News Poster)
  6. Message-ID: <1992Nov20.195655.147884@watson.ibm.com>
  7. Date: Fri, 20 Nov 1992 19:56:55 GMT
  8. Reply-To: uri@watson.ibm.com
  9. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  10. References: <1992Nov20.175252.25182@decuac.dec.com>
  11. Nntp-Posting-Host: aixproj.watson.ibm.com
  12. Organization: Why do you care?
  13. Lines: 34
  14.  
  15. Hi folks,
  16.  
  17. In FAQ (Version 1.0 draft 1e), RSADSI talks
  18. about DES and diff. cryptanalysis (page 35).
  19.  
  20.     Specifically, they say: "........This attack
  21.     requires 2^47 chosen plaintexts, i.e. 
  22.     plaintexts chosen by the attacker.
  23.     Changing the key frequently is                       <----
  24.     not an adequate defense, because
  25.     the attack tests each possible key                     how
  26.     as soon as it is generated during the                  can
  27.     attack; therefore the expected time to               these
  28.     succeed is not affected by key changes (as         coexist
  29.     long as the chosen plaintexts are always encrypted   <----
  30.     under the current key).
  31.  
  32.  
  33. Now - it surely looks like manure to me. If I change the key,
  34. all you've done with your chosen plaintexts is supposed to go
  35. down the tube  and you have to start from the very beginning,
  36. or at least this was my understanding. Am I wrong on this?
  37.  
  38. How can it be possible, that the expected time to succeed is 
  39. not dependent on how often I change keys? Assume I have a 
  40. counter, which automatically demands a new key as soon
  41. as 2^20 bytes are encrypted with the current one. How
  42. can such a scheme be vulnerable to diff. cryptan?
  43.  
  44. -- 
  45. Regards,
  46. Uri.        uri@watson.ibm.com
  47. ------------
  48. <Disclaimer>
  49.