On Fri, Jan 8, 2021 at 4:41 PM Eric Dumazet wrote:
>
> On Fri, Jan 8, 2021 at 2:51 PM Sedat Dilek wrote:
> >
> > On Fri, Jan 8, 2021 at 2:08 PM Sedat Dilek wrote:
> > >
> > > On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
> > >
> > > > > Also, I tried the diff for tcp_conn_request...
> > >
On Fri, Jan 8, 2021 at 2:08 PM Sedat Dilek wrote:
>
> On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
>
> > > Also, I tried the diff for tcp_conn_request...
> > > With removing the call to prandom_u32() not useful for
> > > prandom_u32/tracing via perf.
> >
> > I am planning to send the TCP p
On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
> > Also, I tried the diff for tcp_conn_request...
> > With removing the call to prandom_u32() not useful for
> > prandom_u32/tracing via perf.
>
> I am planning to send the TCP patch once net-next is open. (probably next
> week)
Ping.
What i
On Wed, Aug 12, 2020 at 6:38 PM Sedat Dilek wrote:
>
> On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
> >
> > On Wed, Aug 12, 2020 at 9:20 AM Sedat Dilek wrote:
> > >
> > > On Wed, Aug 12, 2020 at 5:16 PM Eric Dumazet
> > > wrote:
> > > >
> > > >
> > > >
> > > > On 8/11/20 11:03 PM, Sedat
On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet wrote:
>
> On Wed, Aug 12, 2020 at 9:20 AM Sedat Dilek wrote:
> >
> > On Wed, Aug 12, 2020 at 5:16 PM Eric Dumazet wrote:
> > >
> > >
> > >
> > > On 8/11/20 11:03 PM, Sedat Dilek wrote:
> > > > [ CC netdev ]
> > > > [ Please CC me I am not subscribed
On Wed, Aug 12, 2020 at 5:16 PM Eric Dumazet wrote:
>
>
>
> On 8/11/20 11:03 PM, Sedat Dilek wrote:
> > [ CC netdev ]
> > [ Please CC me I am not subscribed to this mailing-list ]
> >
> > Hi Eric,
> >
> > I have added your diffs from [0] and have some troubles to display the
> > prandom_32 trace-e
On 8/11/20 11:03 PM, Sedat Dilek wrote:
> [ CC netdev ]
> [ Please CC me I am not subscribed to this mailing-list ]
>
> Hi Eric,
>
> I have added your diffs from [0] and have some troubles to display the
> prandom_32 trace-events (I mostly followed [1]):
>
> I did:
>
> echo prandom_u32 >> /s
On Wed, Aug 12, 2020 at 8:35 AM Sedat Dilek wrote:
>
> [ INSTRUCTIONS ]
>
> echo 1 > /proc/sys/kernel/sched_schedstats
> echo prandom_u32 >> /sys/kernel/debug/tracing/set_event
> echo traceon > /sys/kernel/debug/tracing/events/random/prandom_u32/trigger
> echo 1 > /sys/kernel/debug/tracing/events/
[ INSTRUCTIONS ]
echo 1 > /proc/sys/kernel/sched_schedstats
echo prandom_u32 >> /sys/kernel/debug/tracing/set_event
echo traceon > /sys/kernel/debug/tracing/events/random/prandom_u32/trigger
echo 1 > /sys/kernel/debug/tracing/events/enable
/home/dileks/bin/perf record -e random:prandom_u32 -a -g
On Sat, Aug 08, 2020 at 01:52:37PM -0700, Linus Torvalds wrote:
> On Sat, Aug 8, 2020 at 1:47 PM George Spelvin wrote:
>> I *just* finished explaining, using dribs and drabs of entropy allows an
>> *information theoretical attack* which *no* crypto can prevent.
>
> The key word here being "theore
On Sat, Aug 8, 2020 at 3:28 PM George Spelvin wrote:
>
> It's not a theoretical hole, it's a very real one. Other than the cycles
> to do the brute-force part, it's not even all that complicated. The
> theory part is that it's impossible to patch.
We'll just disagree.
I'm really fed up with se
On Sat, Aug 08, 2020 at 12:49:30PM -0700, Andy Lutomirski wrote:
> I don't care about throwing this stuff away. My plan (not quite
> implemented yet) is to have a percpu RNG stream and to never to anything
> resembling mixing anything in. The stream is periodically discarded and
> reinitialized
On Sat, Aug 08, 2020 at 09:18:27PM +0200, Florian Westphal wrote:
> Can't we keep prandom_u32 as-is...? Most of the usage, esp. in the
> packet schedulers, is fine.
>
> I'd much rather have a prandom_u32_hashed() or whatever for
> those cases where some bits might leak to the outside and then con
On Sat, Aug 08, 2020 at 11:19:01AM -0700, Linus Torvalds wrote:
> If siphash is a good enough hash to make the pseudo-random state hard
> to guess, then it's also a good enough hash to hide the small part of
> the fast-pool we mix in.
No!
No, no, a thousand times no.
I *just* finished explaining
On Sat, Aug 08, 2020 at 07:44:51PM +0200, Willy Tarreau wrote:
> On Sat, Aug 08, 2020 at 03:26:28PM +, George Spelvin wrote:
>> So any discussion of reseeding begins by *assuming* an attacker has
>> captured the PRNG state. If we weren't worried about this possibility,
>> we wouldn't need to r
On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>>- Cryptographically strong ChaCha, batched
>>- Cryptographically strong ChaCha, with anti-backtracking.
>
> I think we should just anti-backtrack everything. With the "fast key
> erasure" construction, already implemented
Hi Florian,
On Sat, Aug 08, 2020 at 09:18:27PM +0200, Florian Westphal wrote:
> > struct rnd_state {
> > - __u32 s1, s2, s3, s4;
> > + siphash_key_t key;
> > + uint64_t counter;
> > };
>
> Does the siphash_key really need to be percpu?
I don't think so, I was really exploring a quick and
On Sat, Aug 8, 2020 at 1:47 PM George Spelvin wrote:
>
> I *just* finished explaining, using dribs and drabs of entropy allows an
> *information theoretical attack* which *no* crypto can prevent.
The key word here being "theoretical".
The other key word is "reality".
We will have to agree to di
On Sat, Aug 8, 2020 at 1:08 PM George Spelvin wrote:
>
> So assuming that once per interrupt equals "often" is completely false.
That's not what people are assuming.
They are assuming it's "unpredictable".
Guys, look up the real and true meaning of "random" some day.
Guess what? It at no point
> On Aug 8, 2020, at 12:03 PM, George Spelvin wrote:
>
> On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>>> - Cryptographically strong ChaCha, batched
>>> - Cryptographically strong ChaCha, with anti-backtracking.
>>
>> I think we should just anti-backtrack everything.
I'm quite annoyed at the way that this discussion has drifted away from
the main problem, which is that f227e3ec3b5c is broken and needs reverted.
The original bug report is accurate, and it's a critical issue.
My proposed fix is described (patch imminent) below.
THE PROBLEM:
The reseeding desi
Willy Tarreau wrote:
> diff --git a/include/linux/random.h b/include/linux/random.h
> index 9ab7443bd91b..9e22973b207c 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -117,7 +118,
On Sat, Aug 08, 2020 at 11:19:01AM -0700, Linus Torvalds wrote:
> On Sat, Aug 8, 2020 at 10:45 AM Willy Tarreau wrote:
> >
> >
> > WIP: random32: use siphash with a counter for prandom_u32
>
> siphash is good.
>
> But no:
>
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> >
On Sat, Aug 8, 2020 at 10:45 AM Willy Tarreau wrote:
>
>
> WIP: random32: use siphash with a counter for prandom_u32
siphash is good.
But no:
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1277,7 +1277,6 @@ void add_interrupt_randomness(int irq, int irq_flags)
>
>
On Sat, Aug 8, 2020 at 10:07 AM Andy Lutomirski wrote:
>
>
> > On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
> >
>
> > And apparently switching to the fastest secure PRNG currently
> > in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> > would cause too much performance penalty
On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>
> > On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
> >
>
> > And apparently switching to the fastest secure PRNG currently
> > in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> > would cause too much performan
On Sat, Aug 08, 2020 at 03:26:28PM +, George Spelvin wrote:
> So any discussion of reseeding begins by *assuming* an attacker has
> captured the PRNG state. If we weren't worried about this possibility,
> we wouldn't need to reseed in the first place!
Sure, but what matters is the time it tak
> On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
>
> And apparently switching to the fastest secure PRNG currently
> in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> would cause too much performance penalty.
Can someone explain *why* the slow path latency is particularly r
On Fri, Aug 07, 2020 at 03:45:48PM -0700, Marc Plumb wrote:
> Willy,
>
>
> On 2020-08-07 3:19 p.m., Willy Tarreau wrote:
> > On Fri, Aug 07, 2020 at 12:59:48PM -0700, Marc Plumb wrote:
> > >
> > > If I can figure the state out once,
> > Yes but how do you take that as granted ? This state doesn'
Willy,
On 2020-08-07 3:19 p.m., Willy Tarreau wrote:
On Fri, Aug 07, 2020 at 12:59:48PM -0700, Marc Plumb wrote:
If I can figure the state out once,
Yes but how do you take that as granted ? This state doesn't appear
without its noise counterpart,
Amit has shown attacks that can deduce the
On Fri, Aug 07, 2020 at 12:59:48PM -0700, Marc Plumb wrote:
>
> On 2020-08-07 10:43 a.m., Willy Tarreau wrote:
> >
> > > Which means that it's 2^32 effort to brute force this (which Amit called
> > > "no
> > > biggie for modern machines"). If the noise is the raw sample data with
> > > only
> >
On Fri, Aug 7, 2020 at 1:16 PM Andy Lutomirski wrote:
>
> I think this will come down to actual measurements :).
Numbers talk, bullshit walks.
But:
> If the cost of one block of cache-cold ChaCha20 is 100 cycles of actual
> computation and 200 cycles of various cache misses, then let’s do more
> On Aug 7, 2020, at 12:57 PM, Linus Torvalds
> wrote:
>
> On Fri, Aug 7, 2020 at 12:33 PM Andy Lutomirski wrote:
>>
>> No one said we have to do only one ChaCha20 block per slow path hit.
>
> Sure, doing more might be better for amortizing the cost.
>
> But you have to be very careful a
On 2020-08-07 10:43 a.m., Willy Tarreau wrote:
Which means that it's 2^32 effort to brute force this (which Amit called "no
biggie for modern machines"). If the noise is the raw sample data with only
a few bits of entropy, then it's even easier to brute force.
Don't you forget to multiply by
On Fri, Aug 7, 2020 at 12:33 PM Andy Lutomirski wrote:
>
> No one said we have to do only one ChaCha20 block per slow path hit.
Sure, doing more might be better for amortizing the cost.
But you have to be very careful about latency spikes. I would be
*really* nervous about doing a whole page at
> On Aug 7, 2020, at 12:21 PM, Linus Torvalds
> wrote:
>
> On Fri, Aug 7, 2020 at 12:08 PM Andy Lutomirski wrote:
>> 4 cycles per byte on Core 2
>
> I took the reference C implementation as-is, and just compiled it with
> O2, so my numbers may not be what some heavily optimized case does.
On Fri, Aug 7, 2020 at 12:08 PM Andy Lutomirski wrote:
>
> > On Aug 7, 2020, at 11:10 AM, Linus Torvalds
> > wrote:
> >
> >
> > I tried something very much like that in user space to just see how
> > many cycles it ended up being.
> >
> > I made a "just raw ChaCha20", and it was already much too
> On Aug 7, 2020, at 11:10 AM, Linus Torvalds
> wrote:
>
> On Fri, Aug 7, 2020 at 10:55 AM Andy Lutomirski wrote:
>>
>> I think the real random.c can run plenty fast. It’s ChaCha20 plus ludicrous
>> overhead right now.
>
> I doubt it.
>
> I tried something very much like that in user sp
On Fri, Aug 7, 2020 at 10:55 AM Andy Lutomirski wrote:
>
> I think the real random.c can run plenty fast. It’s ChaCha20 plus ludicrous
> overhead right now.
I doubt it.
I tried something very much like that in user space to just see how
many cycles it ended up being.
I made a "just raw ChaCha2
Hi Andy,
On Fri, Aug 07, 2020 at 10:55:11AM -0700, Andy Lutomirski wrote:
> >> This is still another non-cryptographic PRNG.
> >
> > Absolutely. During some discussions regarding the possibility of using
> > CSPRNGs, orders around hundreds of CPU cycles were mentioned for them,
> > which can defi
On Fri, Aug 07, 2020 at 09:52:14AM -0700, Marc Plumb wrote:
> On 2020-08-07 12:03 a.m., Willy Tarreau wrote:
>
> > Just to give a heads up on this, here's what I'm having pending regarding
> > MSWS:
> >
> >struct rnd_state {
> > uint64_t x, w;
> > uint64_t seed;
> >
On 2020-08-07 12:03 a.m., Willy Tarreau wrote:
Just to give a heads up on this, here's what I'm having pending regarding
MSWS:
struct rnd_state {
uint64_t x, w;
uint64_t seed;
uint64_t noise;
};
uint32_t msws32(struct rnd_state *state)
{
uint64_t
On Thu, Aug 06, 2020 at 10:18:55AM -0700, Marc Plumb wrote:
> Willy,
>
>
> On 2020-08-05 11:30 p.m., Willy Tarreau wrote:
> > On Wed, Aug 05, 2020 at 03:21:11PM -0700, Marc Plumb wrote:
> > > There is nothing wrong with perturbing net_rand_state, the sin is doing it
> > > with the raw entropy tha
Willy,
On 2020-08-05 11:30 p.m., Willy Tarreau wrote:
On Wed, Aug 05, 2020 at 03:21:11PM -0700, Marc Plumb wrote:
There is nothing wrong with perturbing net_rand_state, the sin is doing it
with the raw entropy that is also the seed for your CPRNG. Use the output of
a CPRNG to perturb the pool
On 2020-08-05 3:05 p.m., ty...@mit.edu wrote:
Well, technically it's not supposed to be a secure cryptographic
primitive. net_rand_state is used in the call prandom_u32(), so the
only supposed guarantee is PSEUDO random.
That being said, a quick "get grep prandom_u32" shows that there are a
On Wed, Aug 05, 2020 at 03:21:11PM -0700, Marc Plumb wrote:
> There is nothing wrong with perturbing net_rand_state, the sin is doing it
> with the raw entropy that is also the seed for your CPRNG. Use the output of
> a CPRNG to perturb the pool all you want, but don't do things that bit by
> bit r
On Wed, 5 Aug 2020 09:39:17 -0700
Linus Torvalds wrote:
> On Wed, Aug 5, 2020 at 8:44 AM Marc Plumb wrote:
> >
> > I thought net_rand_state was assumed to be insecure and that anyone
> > could determine the internal state. Isn't this Working as Designed?
>
> I was working as designed - becaus
>> On Aug 5, 2020, at 3:06 PM, ty...@mit.edu wrote:
>>
>> On Wed, Aug 05, 2020 at 09:06:40AM -0700, Marc Plumb wrote:
>> Isn't get_random_u32 the function you wrote to do that? If this needs to be
>> cryptographically secure, that's an existing option that's safe.
>> The fundamental question is
Willy,
On 2020-08-05 12:38 p.m., Willy Tarreau wrote:
It's not *that* major an issue (in my personal opinion) but the current
net_rand_state is easy enough to guess so that an observer may reduce
the difficulty to build certain attacks (using known source ports for
example). The goal of this ch
On Wed, Aug 05, 2020 at 09:06:40AM -0700, Marc Plumb wrote:
> Isn't get_random_u32 the function you wrote to do that? If this needs to be
> cryptographically secure, that's an existing option that's safe.
>
> The fundamental question is: Why is this attack on net_rand_state problem?
> It's Working
Hi Willy,
On 2020-08-04 7:49 p.m., Willy Tarreau wrote:
Hi Marc,
On Tue, Aug 04, 2020 at 05:52:36PM -0700, Marc Plumb wrote:
Seeding two PRNGs with the same entropy causes two problems. The minor one
is that you're double counting entropy. The major one is that anyone who can
determine the sta
Hi Ted,
On 2020-08-05 8:34 a.m., ty...@mit.edu wrote:
On Wed, Aug 05, 2020 at 04:49:41AM +0200, Willy Tarreau wrote:
Not only was this obviously not the goal, but I'd be particularly
interested in seeing this reality demonstrated, considering that
the whole 128 bits of fast_pool together count
On Wed, Aug 5, 2020 at 8:44 AM Marc Plumb wrote:
>
> I thought net_rand_state was assumed to be insecure and that anyone
> could determine the internal state. Isn't this Working as Designed?
I was working as designed - because it wasn't really designed to be
"real crypto" - but sadly it's also th
Hi Mark,
On Wed, Aug 05, 2020 at 09:06:40AM -0700, Marc Plumb wrote:
> Just because you or I don't have a working exploit doesn't mean that someone
> else isn't more clever.
I agree on the principle, but it can be said from many things, including
our respective inability to factor large numbers f
Hi Ted,
On Wed, Aug 05, 2020 at 11:34:32AM -0400, ty...@mit.edu wrote:
> That being said, it certainly is a certificational / theoretical
> weakness, and if the bright boys and girls at Fort Meade did figure
> out a way to exploit this, they are very much unlikely to share it at
> an open Crypto c
On Wed, Aug 5, 2020 at 6:07 PM wrote:
> That being said, it certainly is a certificational / theoretical
> weakness
random.c is filled with super suspicious things that are probably only
correct by accident, or only correct in practice, but in theory it's
just such a mess. Stupid example if I'm r
On Wed, Aug 05, 2020 at 04:49:41AM +0200, Willy Tarreau wrote:
>
> Not only was this obviously not the goal, but I'd be particularly
> interested in seeing this reality demonstrated, considering that
> the whole 128 bits of fast_pool together count as a single bit of
> entropy, and that as such, e
Hi Marc,
On Tue, Aug 04, 2020 at 05:52:36PM -0700, Marc Plumb wrote:
> Seeding two PRNGs with the same entropy causes two problems. The minor one
> is that you're double counting entropy. The major one is that anyone who can
> determine the state of one PRNG can determine the state of the other.
>
On Tue, Aug 4, 2020 at 5:52 PM Marc Plumb wrote:
>
> TL;DR This change takes the seed data from get_random_bytes and broadcasts it
> to the network, thereby destroying the security of dev/random. This change
> needs to be reverted and redesigned.
This was discussed.,
It's theoretical, not prac
Willy and Ted,
This commit has serious security flaws
f227e3ec3b5cad859ad15666874405e8c1bbc1d4
TL;DR This change takes the seed data from get_random_bytes and
broadcasts it to the network, thereby destroying the security of
dev/random. This change needs to be reverted and redesigned.
It
60 matches
Mail list logo
