[146589] in cryptography@c2.net mail archive
Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Thu Sep 5 17:04:56 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130905164118.2967b7d7@jabberwock.cb.piermont.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>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2443404638612809110==
Content-Type: multipart/alternative; boundary=089e01177475c85d8904e5a92d0c
--089e01177475c85d8904e5a92d0c
Content-Type: text/plain; charset=ISO-8859-1
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/
--089e01177475c85d8904e5a92d0c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Sep 5, 2013 at 4:41 PM, Perry E. Metzger <span dir=3D"ltr">=
<<a href=3D"mailto:perry@piermont.com" target=3D"_blank">perry@piermont.=
com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, 5 Sep 2013 15:58:0=
4 -0400 "Perry E. Metzger"<br>
<<a href=3D"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 contact=
ed the NSA alumni working in the industry.</div><div><br></div><div>=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"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></blockquo=
te><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"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&#=
39;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></d=
iv><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 tec=
hnical change that made it possible to deploy in .com.=A0</div><div>=A0<br>
</div><div>* Proposals to deploy security policy information (always send m=
e data encrypted) have been consistently filibustered by people making nons=
ensical objections.</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"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><di=
v><br></div><div>Agreed, the PRNG is the easiest thing to futz with.=A0</di=
v><div><br></div><div>It would not surprise me if we discovered kleptograph=
y at work as well.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"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 disc=
ouraged all that was the decision to make end user certificates hard to obt=
ain (still no automatic spec) and expire after a year.=A0</div></div><div>
<br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallam=
baker.com/</a><br>
</div></div>
--089e01177475c85d8904e5a92d0c--
--===============2443404638612809110==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2443404638612809110==--
