----- Forwarded message from Phillip Hallam-Baker <hallam@gmail.com> ----- Date: Thu, 5 Sep 2013 16:58:07 -0400 From: Phillip Hallam-Baker <hallam@gmail.com> To: "Perry E. Metzger" <perry@piermont.com> Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" On Thu, Sep 5, 2013 at 4:41 PM, Perry E. Metzger <perry@piermont.com> wrote:
On Thu, 5 Sep 2013 15:58:04 -0400 "Perry E. Metzger" <perry@piermont.com> wrote:
I would like to open the floor to *informed speculation* about BULLRUN.
Here are a few guesses from me:
1) I would not be surprised if it turned out that some people working for some vendors have made code and hardware changes at the NSA's behest without the knowledge of their managers or their firm. If I were running such a program, paying off a couple of key people here and there would seem only rational, doubly so if the disclosure of their involvement could be made into a crime by giving them a clearance or some such.
Or they contacted the NSA alumni working in the industry.
2) I would not be surprised if some of the slow speed at which improved/fixed hashes, algorithms, protocols, etc. have been adopted might be because of pressure or people who had been paid off.
At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because "it isn't important to the user experience" or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. Whether I am correct or not, such behavior clearly serves the interest of those who would do bad things.
I think it is subtler that that. Trying to block a strong cipher is too obvious. Much better to push for something that is overly complicated or too difficult for end users to make use of. * The bizare complexity of IPSEC. * Allowing deployment of DNSSEC to be blocked in 2002 by blocking a technical change that made it possible to deploy in .com. * Proposals to deploy security policy information (always send me data encrypted) have been consistently filibustered by people making nonsensical objections. 3) I would not be surprised if random number generator problems in a
variety of equipment and software were not a very obvious target, whether those problems were intentionally added or not.
Agreed, the PRNG is the easiest thing to futz with. It would not surprise me if we discovered kleptography at work as well.
4) Choices not to use things like Diffie-Hellman in TLS connections on the basis that it damages user experience and the like should be viewed with enormous suspicion.
5) Choices not to make add-ons available in things like chat clients or mail programs that could be used for cryptography should be viewed with suspicion.
I think the thing that discouraged all that was the decision to make end user certificates hard to obtain (still no automatic spec) and expire after a year. -- Website: http://hallambaker.com/ _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5