[148193] in cryptography@c2.net mail archive
Re: [Cryptography] Moving forward on improving HTTP's security
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Mon Nov 18 21:06:55 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <2FF17814-B3E8-47AC-A971-7F5AEECB0780@gmail.com>
Date: Mon, 18 Nov 2013 20:08:05 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: John Kelsey <crypto.jmk@gmail.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>,
Ben Laurie <ben@links.org>, "jamesd@echeque.com" <jamesd@echeque.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3859228913917199514==
Content-Type: multipart/alternative; boundary=001a11c37044017cbc04eb7d4c7a
--001a11c37044017cbc04eb7d4c7a
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Nov 18, 2013 at 6:02 PM, John Kelsey <crypto.jmk@gmail.com> wrote:
> It seems like the clever bit of CT is the insight that some actions, like
> a CA signing a cert, are intended to be public, and so should be forced
> (via clever crypto) to take place in public. This makes me wonder what
> other crypto actions should also take place in public, in a way that
> doesn't permit hiding them from the world.
+1
That is what I think the big idea in CT is, the principle of Transparency.
I am not that much into the details of the protocol itself, its the
transparency that maters.
I would like to see transparency in crypto hardware too. There was a side
meeting on this in Vancouver. But it is a very hard problem.
Yes we can take a Raspberry Pi and run Linux on it from a distribution with
a known fingerprint. But that still leaves us with a half million lines of
code to wade through.
While I was thinking about the problem it suddenly hit me that the NIST/NSA
backdoor DRNG might have been originally designed to meet this problem.
Let us imagine that the NSA wants to check to see if a piece of crypto
hardware has a backdoor inserted by Belgium. They take samples of the
device, they generate a bunch of random numbers, use their backdoor to pull
the seed out and at this point the device is completely deterministic. They
can audit it. If the device passes they throw the samples in the grinder
and approve the device for government use. Otherwise they give it a NIST
certification but mark it as 'unacceptable' in some registry kept in the
bowels of Fort Meade.
It makes perfect sense that the NSA would have such a program. But it only
really works for them well if they keep the fact that it exists secret.
Otherwise an attacker might play some game where they only defect sometimes
or for some particular domains.
Now imagine that we take the same idea, a DRNG with a backdoor and we use
it to create an auditable crypto module. We can run the device on the bench
with curves and points that we know aren't jiggered and see if it gives the
same output as our reference implementations.
Then for production use we use a set of curves, points, whatever we
generate in a controlled manner after the hardware was validated, on
machines that we physically destroy (belt sander plus thermite) afterward.
The backdoor is sealed shut.
Open source is a good foundation but it only enables open review and there
is going to be too much code to review fully for quite a while and it does
not extend to the machine code running on the hardware. There are many
points of vulnerability that are not covered. Being able to test the whole
crypto system is very useful.
--
Website: http://hallambaker.com/
--001a11c37044017cbc04eb7d4c7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Nov 18, 2013 at 6:02 PM, John Kelsey <span dir=3D"ltr"><<a href=3D"m=
ailto:crypto.jmk@gmail.com" target=3D"_blank">crypto.jmk@gmail.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">It seems like the clever bit of CT is the in=
sight that some actions, like a CA signing a cert, are intended to be publi=
c, and so should be forced (via clever crypto) to take place in public. =A0=
This makes me wonder what other crypto actions should also take place in pu=
blic, in a way that doesn't permit hiding them from the world.</blockqu=
ote>
<div><br></div><div>+1</div><div><br></div><div>That is what I think the bi=
g idea in CT is, the principle of Transparency. =A0I am not that much into =
the details of the protocol itself, its the transparency that maters.</div>
<div><br></div><div>I would like to see transparency in crypto hardware too=
. There was a side meeting on this in Vancouver. But it is a very hard prob=
lem.</div><div><br></div><div>Yes we can take a Raspberry Pi and run Linux =
on it from a distribution with a known fingerprint. But that still leaves u=
s with a half million lines of code to wade through.</div>
<div><br></div><div><br></div><div>While I was thinking about the problem i=
t suddenly hit me that the NIST/NSA backdoor DRNG might have been originall=
y designed to meet this problem.</div><div><br></div><div>Let us imagine th=
at the NSA wants to check to see if a piece of crypto hardware has a backdo=
or inserted by Belgium. They take samples of the device, they generate a bu=
nch of random numbers, use their backdoor to pull the seed out and at this =
point the device is completely deterministic. They can audit it. If the dev=
ice passes they throw the samples in the grinder and approve the device for=
government use. Otherwise they give it a NIST certification but mark it as=
'unacceptable' in some registry kept in the bowels of Fort Meade.<=
/div>
<div><br></div><div>It makes perfect sense that the NSA would have such a p=
rogram. But it only really works for them well if they keep the fact that i=
t exists secret. Otherwise an attacker might play some game where they only=
defect sometimes or for some particular domains.</div>
<div><br></div><div><br></div><div>Now imagine that we take the same idea, =
a DRNG with a backdoor and we use it to create an auditable crypto module. =
We can run the device on the bench with curves and points that we know aren=
't jiggered and see if it gives the same output as our reference implem=
entations.</div>
<div><br></div><div>Then for production use we use a set of curves, points,=
whatever we generate in a controlled manner after the hardware was validat=
ed, on machines that we physically destroy (belt sander plus thermite) afte=
rward. The backdoor is sealed shut.</div>
<div><br></div><div>Open source is a good foundation but it only enables op=
en review and there is going to be too much code to review fully for quite =
a while and it does not extend to the machine code running on the hardware.=
There are many points of vulnerability that are not covered. Being able to=
test the whole crypto system is very useful.</div>
</div><div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">ht=
tp://hallambaker.com/</a><br>
</div></div>
--001a11c37044017cbc04eb7d4c7a--
--===============3859228913917199514==
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
--===============3859228913917199514==--
