* Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function
@ 2016-12-15 21:16 Jason A. Donenfeld
0 siblings, 0 replies; 4+ messages in thread
From: Jason A. Donenfeld @ 2016-12-15 21:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: kernel-hardening, Hannes Frederic Sowa, David Laight, Netdev,
Jean-Philippe Aumasson, LKML, Linux Crypto Mailing List,
Daniel J . Bernstein, Eric Biggers
On Thu, Dec 15, 2016 at 10:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> I think you can/should just use the natural alignment for "u64".
>
> For architectures that need 8-byte alignment, u64 will already be
> properly aligned. For architectures (like x86-32) that only need
> 4-byte alignment, you get it.
I should have added mention of that with my previous email. For the
parameters that are always a multiple of u64 -- namely, the key -- I
now do that in v5 of the patchset. So this is already done.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function
2016-12-15 21:11 ` [kernel-hardening] " Jason A. Donenfeld
@ 2016-12-15 21:14 ` Linus Torvalds
0 siblings, 0 replies; 4+ messages in thread
From: Linus Torvalds @ 2016-12-15 21:14 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kernel-hardening, Hannes Frederic Sowa, David Laight, Netdev,
Jean-Philippe Aumasson, LKML, Linux Crypto Mailing List,
Daniel J . Bernstein, Eric Biggers
On Thu, Dec 15, 2016 at 1:11 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Indeed, I stand corrected. But in any case, the use of __aligned(8) in
> the patchset ensures that things are fixed and that we don't have this
> issue.
I think you can/should just use the natural alignment for "u64".
For architectures that need 8-byte alignment, u64 will already be
properly aligned. For architectures (like x86-32) that only need
4-byte alignment, you get it.
Linus
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function
2016-12-15 21:09 ` Peter Zijlstra
@ 2016-12-15 21:11 ` Jason A. Donenfeld
2016-12-15 21:14 ` Linus Torvalds
0 siblings, 1 reply; 4+ messages in thread
From: Jason A. Donenfeld @ 2016-12-15 21:11 UTC (permalink / raw)
To: kernel-hardening
Cc: Hannes Frederic Sowa, David Laight, Netdev,
Jean-Philippe Aumasson, LKML, Linux Crypto Mailing List,
Daniel J . Bernstein, Linus Torvalds, Eric Biggers
On Thu, Dec 15, 2016 at 10:09 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, Dec 15, 2016 at 07:50:36PM +0100, Jason A. Donenfeld wrote:
>> There's no 32-bit platform
>> that will trap on a 64-bit unaligned access because there's no such
>> thing as a 64-bit access there. In short, we're fine.
>
> ARMv7 LPAE is a 32bit architecture that has 64bit load/stores IIRC.
>
> x86 has cmpxchg8b that can do 64bit things and very much wants the u64
> aligned.
>
> Also, IIRC we have a few platforms where u64 doesn't carry 8 byte
> alignment, m68k or something like that, but yes, you likely don't care.
Indeed, I stand corrected. But in any case, the use of __aligned(8) in
the patchset ensures that things are fixed and that we don't have this
issue.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function
2016-12-15 7:57 Herbert Xu
@ 2016-12-15 8:15 ` Daniel Micay
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Micay @ 2016-12-15 8:15 UTC (permalink / raw)
To: kernel-hardening, Jason A. Donenfeld
Cc: hannes, netdev, linux-kernel, linux-crypto,
jeanphilippe.aumasson, djb, torvalds, ebiggers3
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
On Thu, 2016-12-15 at 15:57 +0800, Herbert Xu wrote:
> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Siphash needs a random secret key, yes. The point is that the hash
> > function remains secure so long as the secret key is kept secret.
> > Other functions can't make the same guarantee, and so nervous
> > periodic
> > key rotation is necessary, but in most cases nothing is done, and so
> > things just leak over time.
>
> Actually those users that use rhashtable now have a much more
> sophisticated defence against these attacks, dyanmic rehashing
> when bucket length exceeds a preset limit.
>
> Cheers,
Key independent collisions won't be mitigated by picking a new secret.
A simple solution with clear security properties is ideal.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-12-15 21:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-15 21:16 [kernel-hardening] Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function Jason A. Donenfeld
-- strict thread matches above, loose matches on Subject: below --
2016-12-15 7:57 Herbert Xu
2016-12-15 8:15 ` [kernel-hardening] " Daniel Micay
2016-12-14 22:03 Hannes Frederic Sowa
2016-12-15 11:04 ` David Laight
2016-12-15 12:23 ` Hannes Frederic Sowa
2016-12-15 12:28 ` David Laight
2016-12-15 12:50 ` Hannes Frederic Sowa
2016-12-15 13:56 ` David Laight
2016-12-15 14:56 ` Hannes Frederic Sowa
2016-12-15 15:41 ` David Laight
2016-12-15 15:53 ` Hannes Frederic Sowa
2016-12-15 18:50 ` Jason A. Donenfeld
2016-12-15 21:09 ` Peter Zijlstra
2016-12-15 21:11 ` [kernel-hardening] " Jason A. Donenfeld
2016-12-15 21:14 ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).