home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / a_m / hakd011.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  4.1 KB  |  95 lines
  1.  
  2.  
  3.  
  4.             hh               AAAA       kk    kk          /       dd
  5.             hh              AA  AA      kk    kk         /        dd
  6.             hh              AA  AA      kk   kk         /         dd
  7.             hh             AA    AA     kk   kk        /          dd
  8.             hhhhhhhhhh     AAAAAAAA     kkk kk        /  ddddddddddd
  9.             hh      hh    AA      AA    kk kk        /   dd       dd
  10.             hh      hh    AA      AA    kk   kk     /    dd       dd
  11.             hh      hh   AA        AA   kk     kk  /     ddddddddddd
  12.                h0'z      Anarky/ASCII   komputerz           drugz
  13.  
  14.  
  15.                                  
  16.                                   phile #11
  17.                           
  18.                          `How to beat klipper chips'
  19.  
  20.  
  21. 5-4-94
  22. 2:20 pm
  23.  
  24.  
  25. @FROM   :smb@research.att.com
  26. @SUBJECT:Matt Blaze's Clipper attack -- details
  27. Message-ID: <Cqs9y1.By9@ulysses.homer.att.com>
  28. Newsgroups: sci.crypt
  29. Organization: AT&T Bell Laboratories
  30.  
  31. I spoke with Matt Blaze; he gave me permission to post a summary of his
  32. attacks.  But the paper is not yet available for ftp.
  33.  
  34. Matt's work was done using a prototype Tessera card, with a SCSI-PCMCIA
  35. interface on a Sun 4.  That may (or may not) have implications for some
  36. of the performance numbers.
  37.  
  38. There are two classes of ways to foil key escrow.  The less interesting
  39. class of attacks are non-interoperable.  That is, two rogue
  40. implementations can talk security, but can't talk to a conforming key
  41. escrow device.  But there's another attack possible, wherein a rogue
  42. application talks to a conforming device, but without presenting a
  43. valid LEAF.
  44.  
  45. The LEAF contains a 32 bit unit id, an 80-bit session key encrypted
  46. with the per-device secret key, and a 16 bit checksum.  The whole thing
  47. is encrypted with the family key.  The checksum field is based on both
  48. the session key and the IV.  A receiving device will not decrypt unless
  49. it's handed a valid LEAF.  But it can only base its judgment on the
  50. checksum and on its external knowledge of the key and IV; the actual
  51. key in the LEAF is encrypted in a way that it cannot read.  LEAFs are
  52. sent out of band by the application; they're not concealed in the
  53. encrypted data stream.
  54.  
  55. Non-interopable applications work by generating a LEAF/IV pair and not
  56. transmitting it.  (Users cannot control the IV; the Tessera interface
  57. (and maybe the Capstone chip) generates it.)  The receiving end does
  58. the same thing.  You don't need an IV for ECB mode, so you have at
  59. least some access to Skipjack that way.  But that's too slow; at least
  60. in the configuration tested, it took ~50 ms to do an ECB encryption.
  61.  
  62. In CBC mode, if you have the wrong IV, the first block of plaintext
  63. will be garbled.  But the error recovery properties of CBC guarantee
  64. that all subsequent blocks will be decrypted correctly.  (Derivation is
  65. left as an exercise for the reader.)  The solution, then, is simple:
  66. just pad your messages with an 8-byte garbage header.
  67.  
  68. OFB and CFB modes can be implemented as well.  The obvious way is via
  69. ECB mode, but that's too slow.  It turns out that with a bit of work,
  70. you can use CBC mode as a primitive to build OFB and CFB.  I'll
  71. describe that if anyone's really interested.
  72.  
  73. The more interesting attack on key escrow is a rogue implementation
  74. that can interoperate with a conforming one.  The checksum is only 16
  75. bits; it's possible to brute-force it.  That is, generate random
  76. 128-bit strings, and see if your own Tessera card will accept it as a
  77. valid LEAF.  Again, recall that it knows only the unencrypted key and
  78. the IV.  On average, you'll find a hit in 2^15 tries; at 50 ms per try,
  79. that's 28 minutes.  You can speed this up by running in parallel with
  80. multiple Tessera cards.
  81.  
  82.   --Steve Bellovin
  83.                                          kawl:
  84.                                           da honky rink
  85.                                           [713]xxx-xxxx
  86. 2:42 pm                                   hAk/d world HQ
  87. EOF
  88.  
  89.                                         broughy to ya by:
  90.                                               omc
  91.  
  92.  
  93.  
  94.  
  95.