[Cryptography] Moving forward on improving HTTP's security

[Jerry Leichter]

On Nov 18, 2013, at 8:08 PM, Phillip Hallam-Baker wrote:
> 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....  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....
Testing software that relies even on non-cryptographic pseudo-randomness - e.g., Monte Carlo algorithms - is a challenge exactly because we *expect* repeated runs to get different seeds and thus produce different results.  A standard trick is for the test framework to print the random seed it's using.  (This is typically generated from the time of day in production and production test use; what's important is that it varies, not that it's unpredictable).

Should a test run produce unexpected results, there's an test framework provides and alternate way to run the software, feeding back in the seed printed in a failing run - which we can now reproduce exactly. 

                                                        -- Jerry