[Cryptography] where shall we put the random-seed?

Phillip Hallam-Baker phill at hallambaker.com
Tue Jan 3 01:15:55 EST 2017


On Mon, Jan 2, 2017 at 6:09 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Mon, Jan 02, 2017 at 08:21:16PM +0000, Jason Cooper wrote:
> > Well, I disagree.  I'd prefer not to give up just because the rest of it
> > is crappy.  It may not always be that way.  We should fix what we have
> > the power to fix as soon as we can.  Especially with the long deployment
> > cycles of embedded systems.
>
> It's not a matter of giving up; I'm just questioning your assumption
> that there won't be regular clean shutdowns.  If the embedded device
> is getting regular security updates, it will very likely be doing
> clean shutdowns every month or so.  And if it's not getting regular
> security updates, you might as well give the Russian hackers free rein
> over the US Power Grid....  (Oh wait, they've already hacked computers
> on the US Power Grid.  Maybe fixing the gaping wide security holes
> should be higher priority, you think?)
>

​I don't see an issue.

First, mark a random source as having been used before you use the data out
of it.

Second, always put the source through a digest function and mix in a
guaranteed monotonically increasing value, e.g. current time.

At a practical level, SHA-2-512 (seed + counter + datetime) is pretty
robust because what matters is not how much ergodicity ​is in the pool, it
is how much unguessability is there.

Repeating use of a seed value kills unguessabilty but if the seed was
unguessable, different calls to the digest function need only have their
input vary by one bit to preserve unguessability.


There is often a tension between using formal methods and robustness. What
you can prove to be secure and what is robustly secure in use are often
very different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170103/8353297c/attachment.html>


More information about the cryptography mailing list