[liberationtech] [Cryptography] Opening Discussion: Speculation on "BULLRUN"

[Jonathan Wilkes]

Hi Eugen,
      When Bruce Schneier made the call for people to come forward
and describe being asked to degrade standards or build backdoors
I don't think this is what he meant.

Mr. Gilmore seems perfectly happy to give us enough details to
be able to find the identity of a "suspicious" Kernel dev, but he
refrains from identifying the NSA employees and their friends.

If he can write without reservation that he knows someone had
longstanding ties to the NSA, he obviously knows who this person
is.  Deanonymizing the person from the free software world while
granting anonymity to someone with ties to the NSA isn't fair, isn't
helpful, and most of all it isn't intellectually responsible.

I cannot fault people for failing to be perfect heroes, but I can fault
them when what may be reasonable fears result in writing that
speculates where we need it least and lacks evidence where we
need it most.

Best,
Jonathan


On 09/07/2013 04:34 AM, Eugen Leitl wrote:
> ----- Forwarded message from John Gilmore <gnu at toad.com> -----
>
> Date: Fri, 06 Sep 2013 17:22:26 -0700
> From: John Gilmore <gnu at toad.com>
> To: Cryptography <cryptography at metzdowd.com>, gnu at toad.com
> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
>
> Speaking as someone who followed the IPSEC IETF standards committee
> pretty closely, while leading a group that tried to implement it and
> make so usable that it would be used by default throughout the
> Internet, I noticed some things:
>
>    *  NSA employees participted throughout, and occupied leadership roles
>       in the committee and among the editors of the documents
>
>    *  Every once in a while, someone not an NSA employee, but who had
>       longstanding ties to NSA, would make a suggestion that reduced
>       privacy or security, but which seemed to make sense when viewed
>       by people who didn't know much about crypto.  For example,
>       using the same IV (initialization vector) throughout a session,
>       rather than making a new one for each packet.  Or, retaining a
>       way to for this encryption protocol to specify that no encryption
>       is to be applied.
>
>    *  The resulting standard was incredibly complicated -- so complex
>       that every real cryptographer who tried to analyze it threw up
>       their hands and said, "We can't even begin to evaluate its
>       security unless you simplify it radically".  See for example:
>
>          https://www.schneier.com/paper-ipsec.html
>
>       That simplification never happened.
>
>       The IPSEC standards also mandated support for the "null"
>       encryption option (plaintext hiding in supposedly-encrypted
>       packets), for 56-bit Single DES, and for the use of a 768-bit
>       Diffie-Hellman group, all of which are insecure and each of which
>       renders the protocol subject to downgrade attacks.
>
>    *  The protocol had major deployment problems, largely resulting from
>       changing the maximum segment size that could be passed through an
>       IPSEC tunnel between end-nodes that did not know anything about
>       IPSEC.  This made it unusable as a "drop-in" privacy improvement.
>
>    *  Our team (FreeS/WAN) built the Linux implementation of IPSEC, but
>       at least while I was involved in it, the packet processing code
>       never became a default part of the Linux kernel, because of
>       bullheadedness in the maintainer who managed that part of the
>       kernel.  Instead he built a half-baked implementation that never
>       worked.  I have no idea whether that bullheadedness was natural,
>       or was enhanced or inspired by NSA or its stooges.
>
> In other circumstances I also found situations where NSA employees
> explicitly lied to standards committees, such as that for cellphone
> encryption, telling them that if they merely debated an
> actually-secure protocol, they would be violating the export control
> laws unless they excluded all foreigners from the room (in an
> international standards committee!).  The resulting paralysis is how
> we ended up with encryption designed by a clueless Motorola employee
> -- and kept secret for years, again due to bad NSA export control
> advice, in order to hide its obvious flaws -- that basically XOR'd
> each voice packet with the same bit string!  Their "encryption"
> scheme for the control channel, CMEA, was almost as bad, being
> breakable with 2^24 effort and small numbers of ciphertexts:
>
>    https://www.schneier.com/cmea-press.html
>
> To this day, no mobile telephone standards committee has considered
> or adopted any end-to-end (phone-to-phone) privacy protocols.  This is
> because the big companies involved, huge telcos, are all in bed with
> NSA to make damn sure that working end-to-end encryption never becomes
> the default on mobile phones.
>
> 	John Gilmore
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
> ----- End forwarded message -----