[Cryptography] Moving forward on improving HTTP's security

Phillip Hallam-Baker hallam at gmail.com
Mon Nov 18 20:08:05 EST 2013


On Mon, Nov 18, 2013 at 6:02 PM, John Kelsey <crypto.jmk at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131118/b0394dbe/attachment.html>


More information about the cryptography mailing list