<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 4:41 PM, Perry E. Metzger <span dir="ltr"><<a href="mailto:perry@piermont.com" target="_blank">perry@piermont.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, 5 Sep 2013 15:58:04 -0400 "Perry E. Metzger"<br>
<<a href="mailto:perry@piermont.com">perry@piermont.com</a>> wrote:<br>
> I would like to open the floor to *informed speculation* about<br>
> BULLRUN.<br>
<br>
</div>Here are a few guesses from me:<br>
<br>
1) I would not be surprised if it turned out that some people working<br>
for some vendors have made code and hardware changes at the NSA's<br>
behest without the knowledge of their managers or their firm. If I<br>
were running such a program, paying off a couple of key people here<br>
and there would seem only rational, doubly so if the disclosure of<br>
their involvement could be made into a crime by giving them a<br>
clearance or some such.<br></blockquote><div><br></div><div>Or they contacted the NSA alumni working in the industry.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2) I would not be surprised if some of the slow speed at which<br>
improved/fixed hashes, algorithms, protocols, etc. have been adopted<br>
might be because of pressure or people who had been paid off.<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At the very least, anyone whining at a standards meeting from now on<br>
that they don't want to implement a security fix because "it isn't<br>
important to the user experience" or adds minuscule delays to an<br>
initial connection or whatever should be viewed with enormous<br>
suspicion. Whether I am correct or not, such behavior clearly serves<br>
the interest of those who would do bad things.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>* The bizare complexity of IPSEC.</div><div><br></div><div>* Allowing deployment of DNSSEC to be blocked in 2002 by blocking a technical change that made it possible to deploy in .com. </div><div> <br>
</div><div>* Proposals to deploy security policy information (always send me data encrypted) have been consistently filibustered by people making nonsensical objections.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

3) I would not be surprised if random number generator problems in a<br>
variety of equipment and software were not a very obvious target,<br>
whether those problems were intentionally added or not.<br></blockquote><div><br></div><div>Agreed, the PRNG is the easiest thing to futz with. </div><div><br></div><div>It would not surprise me if we discovered kleptography at work as well.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) Choices not to use things like Diffie-Hellman in TLS connections<br>
on the basis that it damages user experience and the like should be<br>
viewed with enormous suspicion.<br>
<br>
5) Choices not to make add-ons available in things like chat clients<br>
or mail programs that could be used for cryptography should be viewed<br>
with suspicion.</blockquote><div><br></div><div>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. </div></div><div>
<br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>