From iang@iang.org Fri Jul 6 02:34:34 2018 From: ianG To: cypherpunks-legacy@lists.cpunks.org Subject: Re: [cryptography] ICIJ's project - comment on cryptography & tools Date: Fri, 06 Jul 2018 02:34:34 +0000 Message-ID: <172289284195.3881296.14475911039009378216.generated@mail.pglaf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0093954375964314228==" --===============0093954375964314228== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 9/04/13 03:43 AM, Jeffrey Goldberg wrote: > On Apr 8, 2013, at 7:38 AM, ianG wrote: > >> We all know stories. DES is now revealed as interfered with, yet for deca= des we told each other it was just parity bits. > > But it turned out that the interference was to make it *stronger* against a= ttacks, differential cryptanalysis, that only the NSA and IBM knew about at t= he time. That's what we all believed. From Wikipedia (I haven't checked the =20 primary references): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In contrast, a declassified NSA book on cryptologic history states: In 1973 NBS solicited private industry for a data encryption standard=20 (DES). The first offerings were disappointing, so NSA began working on its=20 own algorithm. Then Howard Rosenblum, deputy director for research and=20 engineering, discovered that Walter Tuchman of IBM was working on a=20 modification to Lucifer for general use. NSA gave Tuchman a clearance and=20 brought him in to work jointly with the Agency on his Lucifer=20 modification."[8] and NSA worked closely with IBM to strengthen the algorithm against all except=20 brute force attacks and to strengthen substitution tables, called S-boxes.=20 Conversely, NSA tried to convince IBM to reduce the length of the key from=20 64 to 48 bits. Ultimately they compromised on a 56-bit key.[9] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27s_involvement_in_= the_design Conclusion? We wuz tricked! In their own words, they managed the entire=20 process, and succeeded in convincing everyone that they did not. And they=20 made it weaker where they held the advantage: budget to crunch. Last two=20 sentences, above. > If history is a guide, weakness that TLAs insist on are transparent. They a= re about (effective) key size. Indeed. Notice the subtlety of their attack: it is brutally simple. We=20 others focus on elegance, and dismiss the simplistic. Cognitive dissonance? They focussed on mission, and used asymmetry of crunch strength. Recall =20 that, in the old days, no other country could muster the budget and =20 technology that they could. > We have no way to know whether this will continue to be the case, but I'd i= magine that the gap in knowledge between the NSA and the academic community d= iminishes over time; so that makes me think that they'd be even more reluctan= t to try to slip in a hidden weakness today than in 1975. Possibly. In terms of algorithms, I don't think there has been a case =20 where they've deliberately weakened the algorithm. OTOH, in terms of key=20 strength, they have been very very finessed. Remember Skipjack? The=20 comments at the time was that the key strength was beautifully aligned -=20 right at the edge. 80 bit keys where the open community had already=20 concluded 128 was the target. Which meant that if there was to be an=20 advantage, all that was left was: budget in crunching. iang _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- --=20 Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --===============0093954375964314228==--