[Cryptography] Techniques for malevolent crypto hardware

ianG iang at iang.org
Mon Sep 9 03:36:03 EDT 2013


On 9/09/13 06:42 AM, James A. Donald wrote:
> On 2013-09-09 11:15 AM, Perry E. Metzger wrote:
>> Lenstra, Heninger and others have both shown mass breaks of keys based
>> on random number generator flaws in the field. Random number
>> generators have been the source of a huge number of breaks over time.
>>
>> Perhaps you don't see the big worry, but real world experience says
>> it is something everyone else should worry about anyway.
>
> Real world experience is that there is nothing to worry about /if you do
> it right/.  And that it is frequently not done right.
>
> When you screw up AES or such, your test vectors fail, your unit test
> fails, so you fix it, whereas if you screw up entropy, everything
> appears to work fine.


Precisely.

> It is hard, perhaps impossible, to have test suite that makes sure that
> your entropy collection works.
>
> One can, however, have a test suite that ascertains that on any two runs
> of the program, most items collected for entropy are different except
> for those that are expected to be the same, and that on any run, any
> item collected for entropy does make a difference.
>
> Does your unit test check your entropy collection?


When I audited the process for root key ceremony for CAcert, I worried a 
fair bit about randomness.  I decided the entropy was untestable 
(therefore unauditable).

So I wrote a process such that several people would bring their own 
entropy source.  E.g., in the one event, 3 sources were used, by 
independent people on independent machines:

   * I used a sha-stream of laptop camera on dark paper [0]
   * Teus used sound card driver [1]
   * OpenSSL's RNG.

The logic was that as long as one person was honest and had a good 
source, and as long as our mixing was verifiable, the result would be good.

Then, I wrote a small C program to mix it [2];  as small as possible so 
a room full of techies could spend no more than 10 minutes checking it 
on the day [3].

The output of this was then fed into the OpenSSL script to do the root 
key.  (I'm interested if anyone can spot a flaw in this concept.)



iang



[0] This idea from Jon Callas from memory, the idea is that the lack of 
light and lack of discrimination between pixels drives the photocells 
into a quantam uncertainty state.
[1] John Denker's sound card driver.
[2] As an amusing sidenote, I accidentally used | to mix the bytes not 
^.  My eyeball tests passed at 2 sources but at 3 sources it was 
starting to look decidedly wonky.
[3] It was discussed on the group at this time, it was advised that the 
output of the mix should be sha'd, which I eventually agreed with, but I 
don't think I did in the event.


More information about the cryptography mailing list