On Apr 25, 2014, at 10:09 PM, Thor Lancelot Simon 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
>> questions. You
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 an
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. Whi
On Apr 25, 2014, at 4:31 PM, Thor Lancelot Simon 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, because the
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 releva
On Apr 24, 2014, at 10:09 PM, Thor Lancelot Simon 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 where
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 Apr 24, 2014, at 3:03 PM, Mindaugas Rasiukevicius wrote:
> 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 a more definite description
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 undesirable in th
On Apr 24, 2014, at 12:40 PM, Mindaugas Rasiukevicius wrote:
> 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.
>>
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 secur
On Apr 23, 2014, at 7:56 PM, Thor Lancelot Simon wrote:
> 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, base
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
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
>
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
> > > consider
On Apr 22, 2014, at 11:59 PM, Thor Lancelot Simon wrote:
> ...
> RESULTS
>
> kernelcpb (32 bit)4GB (1 way) 16GB (4 ways) Scaling
> Factor
> ----- -
> --
> arc4-mtx 35 42.58
On Wed, Apr 23, 2014 at 02:34:33PM +0100, Mindaugas Rasiukevicius wrote:
> Thor Lancelot Simon wrote:
> > On Wed, Apr 23, 2014 at 01:16:42PM +0100, Mindaugas Rasiukevicius wrote:
> > >
> > > You mentioned that 4GB of data are generated by requesting 256 bytes.
> > > It would be more interesting t
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 such kernels, which are probably fo
Thor Lancelot Simon wrote:
> On Wed, Apr 23, 2014 at 01:16:42PM +0100, Mindaugas Rasiukevicius wrote:
> >
> > You mentioned that 4GB of data are generated by requesting 256 bytes.
> > It would be more interesting to see the throughput of 4 byte requests
> > i.e. how many cprng_fast32() calls per
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 are probably for slower hardware anyway.
AFAIK
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
> > ciphers with, at most, 128-bit security, and even 6-round ChaCha has
On Wed, Apr 23, 2014 at 01:16:42PM +0100, Mindaugas Rasiukevicius wrote:
>
> You mentioned that 4GB of data are generated by requesting 256 bytes.
> It would be more interesting to see the throughput of 4 byte requests
> i.e. how many cprng_fast32() calls per second can we do?
That is how the num
Thor Lancelot Simon wrote:
>RESULTS
>
> kernelcpb (32 bit)4GB (1 way) 16GB (4 ways) Scaling Factor
> ----- - --
> arc4-mtx 35 42.58 398.83 0.106
> arc4-nomtx24
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 i
Date: Sun, 20 Apr 2014 03:18:03 -0400
From: Thor Lancelot Simon
The following tests were run:
1) Cycles-per-byte, 32 bit request: at initial keying of
the generator and each automatic rekeying.
2) Generate 4GB of data
On Sun, Apr 20, 2014 at 03:18:03AM -0400, Thor Lancelot Simon wrote:
> I have done some benchmarks of various cprng_fast implementations:
>
> arc4-mtxThe libkern implementation from
> netbsd-current, which uses a spin mutex to
>
On 20 Apr, 2014, at 00:18 , Thor Lancelot Simon 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 choice
> at this
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
28 matches
Mail list logo
