[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8kYHNo6T9-C3E0vyu7Mz-xGRLzLOifLFYsBMkoK92qmiA@mail.gmail.com>
Date: Sat, 17 Dec 2016 11:14:47 -0500
From: Jeffrey Walton <noloader@...il.com>
To: "Theodore Ts'o" <tytso@....edu>, kernel-hardening@...ts.openwall.com,
"Jason A. Donenfeld" <Jason@...c4.com>, George Spelvin <linux@...encehorizons.net>, ak@...ux.intel.com,
davem@...emloft.net, David Laight <David.Laight@...lab.com>,
"D. J. Bernstein" <djb@...yp.to>, Eric Biggers <ebiggers3@...il.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>, linux-crypto@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, luto@...capital.net,
Netdev <netdev@...r.kernel.org>, Tom Herbert <tom@...bertland.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: Re: [PATCH v5 1/4] siphash: add
cryptographically secure PRF
> As far as half-siphash is concerned, it occurs to me that the main
> problem will be those users who need to guarantee that output can't be
> guessed over a long period of time. For example, if you have a
> long-running process, then the output needs to remain unguessable over
> potentially months or years, or else you might be weakening the ASLR
> protections. If on the other hand, the hash table or the process will
> be going away in a matter of seconds or minutes, the requirements with
> respect to cryptographic strength go down significantly.
Perhaps SipHash-4-8 should be used instead of SipHash-2-4. I believe
SipHash-4-8 is recommended for the security conscious who want to be
more conservative in their security estimates.
SipHash-4-8 does not add much more processing. If you are clocking
SipHash-2-4 at 2.0 or 2.5 cpb, then SipHash-4-8 will run at 3.0 to
4.0. Both are well below MD5 times. (At least with the data sets I've
tested).
> Now, maybe this doesn't matter that much if we can guarantee (or make
> assumptions) that the attacker doesn't have unlimited access the
> output stream of get_random_{long,int}(), or if it's being used in an
> anti-DOS use case where it ultimately only needs to be harder than
> alternate ways of attacking the system.
>
> Rekeying every five minutes doesn't necessarily help the with respect
> to ASLR, but it might reduce the amount of the output stream that
> would be available to the attacker in order to be able to attack the
> get_random_{long,int}() generator, and it also reduces the value of
> doing that attack to only compromising the ASLR for those processes
> started within that five minute window.
Forgive my ignorance... I did not find reading on using the primitive
in a PRNG. Does anyone know what Aumasson or Bernstein have to say?
Aumasson's site does not seem to discuss the use case:
https://www.google.com/search?q=siphash+rng+site%3A131002.net. (And
their paper only mentions random-number once in a different context).
Making the leap from internal hash tables and short-lived network
packets to the rng case may leave something to be desired, especially
if the bits get used in unanticipated ways, like creating long term
private keys.
Jeff
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
