After reading all these messages a bit too fast, it seems to be that we
can add to Thor's analysis
Moving the fast-not-super-strong PRNG to ChaCha8 is clearly a step
forward from what we have now. (really this is his conclusion)
It remains for Someone to do more formal work (perhaps in
On Apr 25, 2014, at 10:09 PM, Thor Lancelot Simon t...@panix.com wrote:
On Fri, Apr 25, 2014 at 08:58:54PM +, paul_kon...@dell.com wrote:
But what X are we talking about? Security analysis does not come from
generalities, it comes from the point by point analysis of specific
On Apr 24, 2014, at 10:09 PM, Thor Lancelot Simon t...@panix.com wrote:
On Thu, Apr 24, 2014 at 07:23:41PM +, paul_kon...@dell.com wrote:
I do disagree. The reason is that I see no requirements that make it
possible to decide whether the weak generator is useful.
Here are some cases
On Fri, Apr 25, 2014 at 01:53:13PM +, paul_kon...@dell.com wrote:
Yes, the discussion is about an RNG that is weaker than the existing
strong RNG. How much weaker is not clear.
There's not a single answer, because the CTR_DRBG is designed to resist
attacks that really don't seem relevant
On Apr 25, 2014, at 4:31 PM, Thor Lancelot Simon t...@panix.com wrote:
On Fri, Apr 25, 2014 at 01:53:13PM +, paul_kon...@dell.com wrote:
Yes, the discussion is about an RNG that is weaker than the existing
strong RNG. How much weaker is not clear.
There's not a single answer,
On Fri, Apr 25, 2014 at 08:58:54PM +, paul_kon...@dell.com wrote:
But what X are we talking about? Security analysis does not come from
generalities, it comes from the point by point analysis of specific
questions. You correctly point out that some attacks may not be
relevant. Which
paul_kon...@dell.com wrote:
No. There is a strong RNG, based on the NIST SP800-90 CTR_DRBG with
AES128 as the block transform.
There is also a fast RNG, based on RC4.
We are discussing the replacement of the fast RNG.
Ok. But if that’s a non-strong RNG, why are we discussing
On Apr 24, 2014, at 12:40 PM, Mindaugas Rasiukevicius rm...@netbsd.org wrote:
paul_kon...@dell.com wrote:
No. There is a strong RNG, based on the NIST SP800-90 CTR_DRBG with
AES128 as the block transform.
There is also a fast RNG, based on RC4.
We are discussing the replacement of the
paul_kon...@dell.com wrote:
There are cases when both security and performance matters. Consider
TCP ISN generation or UDP port number generation (i.e. randomisation).
There are known security issues if these numbers can be predicted, but
at the same time, high performance penalty is
On Apr 24, 2014, at 3:03 PM, Mindaugas Rasiukevicius rm...@netbsd.org wrote:
paul_kon...@dell.com wrote:
...
Knowing that there are “security issues” with UDP port number generation
may mean that a PRNG is inadequate. Deciding what sort of generator IS
adequate, though, means starting with
On Thu, Apr 24, 2014 at 07:23:41PM +, paul_kon...@dell.com wrote:
I do disagree. The reason is that I see no requirements that make it
possible to decide whether the weak generator is useful.
Here are some cases where the fast CPRNG is used:
1) Generation of ip_id values
On Tue, Apr 22, 2014 at 11:59:38PM -0400, Thor Lancelot Simon wrote:
I believe ChaCha8 is suitable for our purpose: we were previously considering
ciphers with, at most, 128-bit security, and even 6-round ChaCha has 139-bit
strength against the best currently known attack (at present, there is
Thor Lancelot Simon t...@panix.com wrote:
RESULTS
kernelcpb (32 bit)4GB (1 way) 16GB (4 ways) Scaling Factor
----- - --
arc4-mtx 35 42.58 398.83 0.106
arc4-nomtx24
Manuel Bouyer bou...@antioche.eu.org wrote:
On Wed, Apr 23, 2014 at 09:16:33AM -0400, Thor Lancelot Simon wrote:
[...]
Do we still have a compile-time way to check if the kernel (or port) is
uniprocessor only? If so we should probably #ifdef away the percpu
calls in such kernels, which
On Apr 22, 2014, at 11:59 PM, Thor Lancelot Simon t...@panix.com wrote:
...
RESULTS
kernelcpb (32 bit)4GB (1 way) 16GB (4 ways) Scaling
Factor
----- -
--
arc4-mtx 35
On Wed, Apr 23, 2014 at 09:16:33AM -0400, Thor Lancelot Simon wrote:
On Wed, Apr 23, 2014 at 10:57:59AM +0200, Joerg Sonnenberger wrote:
On Tue, Apr 22, 2014 at 11:59:38PM -0400, Thor Lancelot Simon wrote:
I believe ChaCha8 is suitable for our purpose: we were previously
considering
On Wed, Apr 23, 2014 at 03:30:09PM +0200, Manuel Bouyer wrote:
On Wed, Apr 23, 2014 at 09:16:33AM -0400, Thor Lancelot Simon wrote:
[...]
Do we still have a compile-time way to check if the kernel (or port) is
uniprocessor only? If so we should probably #ifdef away the percpu calls
in
On Wed, Apr 23, 2014 at 02:21:31PM +, paul_kon...@dell.com wrote:
I?ve been watching this long stream of messages flying by, and I?m a bit
concerned about the approach.
As I understand it, there is a strong RNG, based on RC4 (?ARC4?) in the
kernel today.
No. There is a strong RNG,
Date: Sun, 20 Apr 2014 03:18:03 -0400
From: Thor Lancelot Simon t...@panix.com
The following tests were run:
1) Cycles-per-byte, 32 bit request: at initial keying of
the generator and each automatic rekeying.
2)
On 20 Apr, 2014, at 00:18 , Thor Lancelot Simon t...@panix.com wrote:
Personally, I'd go with the HC128 variant without the ugly inlining. We
restrict bytes-on-key to 512MB -- the best current attack on HC128 requires
2^65 bytes to distinguish its keystream, so I think it's a reasonable
I have done some benchmarks of various cprng_fast implementations:
arc4-mtxThe libkern implementation from
netbsd-current, which uses a spin mutex to
serialize access to a single, shared arc4
21 matches
Mail list logo
