[Cryptech Tech] Avalanche noise test boards

[Bernd Paysan]

Am Dienstag, 19. August 2014, 12:40:31 schrieb Peter Gutmann:
> Randy Bush <randy at psg.com> writes:
> >all unix systems have a nice box into which to put the clueless complaints
> 
> They won't go to /dev/null, they'll get written up in blog posts by self-
> appointed experts who'll tell the world that your product shouldn't be used.
> Here's one example:
> 
> http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-> based-crypto-freebsd-developers-say/
> 
> You've got perfectly good CPU-based good crypto assist sitting there ignored
> because of pointless paranoia.

They aren't ignored, it's just they are fed through Yarrow instead of directly 
passed to the reader of /dev/random. Complaining about that is entirely stupid 
- the entropy doesn't go away if you feed it through yet another conditioner.  
The possible malicous backdoor goes away that way (just like encrypting with 
two different methods makes it impossible to decrypt the message if only one 
of them is weak).

> (Note that I don't know how to fix this issue because you're damned if you
> do and damned if you don't, just pointing out that there is an issue that
> may need to be addressed at some point).

If our product is good, the NSA will for sure spread as much FUD as they can 
to limit adaption rate ;-).

I have two reasons why I want the raw entropy without preconditioning:

1. I want to use that to debug and evaluate the noise source.  This includes 
modi to gain more information than usually is taken when used as random source 
(e.g. fast regular sampling for the ROSCs, to evaluate the actual jitter, or 
sampling of the complete counter of the avalanche diode noise to obtain the 
actual amplified signal plot)

2. I might not actually trust the conditioner or expander, and replace them 
with my own ones - and while I personally quite likely will have *my* trusted 
conditioner&expander in the project, other people won't (we can't put in 
everything, especially in of-the-shelf parts, there will be limits).  They 
should have the same possibilities, by taking the entropy out and using 
external stuff.  Especially the expander is good to have externally, because 
some algorithms simply need a lot of random numbers, and therefore should 
expand with a high-speed interface to the memory.

While we are aiming at complete transparency and auditability, intel made the 
mistake to hide their implementation (AFAIK it's ROSC-based, and works pretty 
well across processes; just like my ROSC design is made to be robust across 
different FPGAs).  The problem, especially with expanders, is that you can 
make them in a way that is harmful, which is from the outside 
indistinguishable from good expanders.  E.g. take an AES expander: You can 
either use a constant secret, and feed in the entropy as starting point, and 
use AES in counter mode.  Anybody who knows the secret can then predict more 
randomness from the first one.  If you feed in the entropy as key, and use an 
ever-incrementing nonce as input for counter mode, you are fine - an attacker 
can't guess unless there is a related plaintext attack in AES of which we 
don't know yet.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20140819/f56cfece/attachment.sig>