[Cryptography] The Crypto Pi

[Tom Mitchell]

>On Mon, Jan 26, 2015 at 10:59 AM, Ralf Senderek <crypto at senderek.ie> wrote:
>
>> On Mon, 26 Jan 2015 14:12:29 iang wrote:
>>>
>>>  On 25/01/2015 16:35 pm, Ralf Senderek wrote:
>>>
>>> >  When I read bytes from /dev/random with dd and immediately check this
>>> >  file again, n bits are missing as a result of the read operation.
 .....
>>
>>
>>  My advice:  applications should use /dev/urandom.


>I won't follow your advice, because for the Crypto Pi I want high-quality
>keys with a reliable amount of entropy in each of them, not only
>pseudo-random numbers
.....
>I agree that we're in implementation land already, and in the end we
>have to assess a working system and not a mathematical notion.

Since you are in implementation land code in a way that lets you
change the way "*random*" works with minimum impact on the rest
of the code base.  Good design here will let you apply tomorrows lessons
quickly.

The more I read about the BSD decisions on random the more I believe that
any
initial expectations may become fragile and need to be updated.

The two obvious /dev/random and /dev/urandom involve system
calls which invoke mutex locks all of which takes more time than
interacting with a well seeded user space PRNG.

Assuming flaws an important consideration for an attack is knowing
which flawed resource is involved.    In revision two consider multiple
user space PRNG(s) the selection of which is randomized and feed them
into a mixer using a random weight... 10% from PRNG(a), 60% from PRNG(b)
etc...

Any clever idea needs to be subjected to testing... again a design that
isolates these functions facilitates testing to avoid the obvious.  We
all know that double ROT13 is twice as good as single...

Now I am off to play with BSD on my PI







-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150127/6ea1293c/attachment.html>