Since padata has a maximum number of inflight jobs, currently 1000, it's
very useful to know how many jobs are currently queued up. This adds a
simple helper function to expose this information.
Signed-off-by: Jason A. Donenfeld
---
include/linux/padata.h | 2 ++
kernel/padata.c
Hi Steffen,
On Fri, Oct 7, 2016 at 5:15 AM, Steffen Klassert
wrote:
> Why you want to have this?
I'm working on some bufferbloat/queue code that could benefit from
knowing how many items are currently in flight. The goal is to always
keep padata busy, but never with more jobs than absolutely nec
On MIPS chips commonly found in inexpensive routers, this makes a big
difference in performance.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/crypto/poly1305_generic.c b/crypto
On Wed, Nov 2, 2016 at 9:09 PM, Herbert Xu wrote:
> Can you give some numbers please? What about other architectures
> that your patch impacts?
Per [1], the patch gives a 181% speed up on MIPS32r2.
[1] https://lists.zx2c4.com/pipermail/wireguard/2016-September/000398.html
--
To unsubscribe from
These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS:
s390 arm arm64 powerpc x86 x86_64
So, these will use the original old code.
The architectures that will thus use the new code are:
alpha arc avr32 blackfin c6x cris frv h7300 hexagon ia64 m32r m68k
metag microblaze mips mn10300 nios2 o
On Wed, Nov 2, 2016 at 10:26 PM, Herbert Xu wrote:
> What I'm interested in is whether the new code is sufficiently
> close in performance to the old code, particularonly on x86.
>
> I'd much rather only have a single set of code for all architectures.
> After all, this is meant to be a generic im
Hi Herbert,
On Thu, Nov 3, 2016 at 1:49 AM, Herbert Xu wrote:
> FWIW I'd rather live with a 6% slowdown than having two different
> code paths in the generic code. Anyone who cares about 6% would
> be much better off writing an assembly version of the code.
Please think twice before deciding th
Hi David,
On Thu, Nov 3, 2016 at 6:08 PM, David Miller wrote:
> In any event no piece of code should be doing 32-bit word reads from
> addresses like "x + 3" without, at a very minimum, going through the
> kernel unaligned access handlers.
Excellent point. In otherwords,
ctx->r[0] = (le32_t
Hi Eric,
On Fri, Nov 4, 2016 at 6:37 PM, Eric Biggers wrote:
> I agree, and the current code is wrong; but do note that this proposal is
> correct for poly1305_setrkey() but not for poly1305_setskey() and
> poly1305_blocks(). In the latter two cases, 4-byte alignment of the source
> buffer is *n
On Mon, Nov 7, 2016 at 7:08 PM, Jason A. Donenfeld wrote:
> Hmm... The general data flow that strikes me as most pertinent is
> something like:
>
> struct sk_buff *skb = get_it_from_somewhere();
> skb = skb_share_check(skb, GFP_ATOMIC);
> num_frags = skb_cow_data(skb, .
On Mon, Nov 7, 2016 at 7:26 PM, Eric Biggers wrote:
>
> I was not referring to any users in particular, only what users could do. As
> an
> example, if you did crypto_shash_update() with 32, 15, then 17 bytes, and the
> underlying algorithm is poly1305-generic, the last block would end up
> misa
By using the unaligned access helpers, we drastically improve
performance on small MIPS routers that have to go through the exception
fix-up handler for these unaligned accesses.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 12 ++--
1 file changed, 6 insertions
On Mon, Nov 7, 2016 at 8:25 PM, Eric Biggers wrote:
> No it does *not* buffer all incoming blocks, which is why the source pointer
> can
> fall out of alignment. Yes, I actually tested this. In fact this situation
> is
> even hit, in both possible places, in the self-tests.
Urgh! v3 coming ri
By using the unaligned access helpers, we drastically improve
performance on small MIPS routers that have to go through the exception
fix-up handler for these unaligned accesses.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 33 ++---
1 file
By using the unaligned access helpers, we drastically improve
performance on small MIPS routers that have to go through the exception
fix-up handler for these unaligned accesses.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 34 +++---
1 file
Hello friendly test robot,
On Sun, Nov 13, 2016 at 12:27 AM, kbuild test robot wrote:
> Hi Jason,
>
> [auto build test ERROR on cryptodev/master]
That error was fixed by v4 in this series. The version that should be
tested and ultimately applied is v4 and can be found here:
https://www.mail-arc
Hi Herbert,
The scatterwalk_map_and_copy function copies ordinary buffers to and
from scatterlists. These buffers can, of course, be on the stack, and
this remains the most popular use of this function -- getting info
between stack buffers and DMA regions. It's mostly used for adding or
checking M
Hah, looks like I missed [1] by a couple weeks. Looks like it's been
settled then.
Is this a stable@ candidate?
[1]
https://git.zx2c4.com/linux/commit/?id=c8467f7a3620698bf3c22f0e199b550fb611a8ae
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message
their kernels. SipHash is
a widely known high-speed solution to a widely known problem, and it's
time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
---
include/linux/siphash.h | 18 ++
lib/Makefile
Hi Herbert,
On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu wrote:
> As for AEAD we never had a sync interface to begin with and I
> don't think I'm going to add one.
That's too bad to hear. I hope you'll reconsider. Modern cryptographic
design is heading more and more in the direction of using AEAD
Hi Greg,
Thanks for the review. Responses to your suggestions are inline below:
On Sat, Dec 10, 2016 at 1:37 PM, Greg KH wrote:
> Please use u64 and u8 instead of the userspace uint64_t and uint8_t
> types for kernel code. Yes, the ship has probably sailed for trying to
> strictly enforce it, b
their kernels. SipHash is
a widely known high-speed solution to a widely known problem, and it's
time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
---
include/linux/siphash.h | 20 +
lib/Makefile
Hey Linus,
On Mon, Dec 12, 2016 at 5:01 AM, Linus Torvalds
wrote:
> The above is extremely inefficient. Considering that most kernel data
> would be expected to be smallish, that matters (ie the usual benchmark
> would not be about hashing megabytes of data, but instead millions of
> hashes of sm
Hey Eric,
Lots of good points; thanks for the review. Responses are inline below.
On Mon, Dec 12, 2016 at 6:42 AM, Eric Biggers wrote:
> Maybe add to the help text for CONFIG_TEST_HASH that it now tests siphash too?
Good call. Will do.
> This assumes the key and message buffers are aligned to
Hi Linus,
> I guess you could try to just remove the "if (left)" test entirely, if
> it is at least partly the mispredict. It should do the right thing
> even with a zero count, and it might schedule the code better. Code
> size _should_ be better with the byte mask model (which won't matter
> in
On Mon, Dec 12, 2016 at 10:44 PM, Jason A. Donenfeld wrote:
> #if defined(CONFIG_DCACHE_WORD_ACCESS) && BITS_PER_LONG == 64
>switch (left) {
>case 0: break;
>case 1: b |= data[0]; break;
>case 2: b |= get_unaligned_le16(data); br
their kernels. SipHash is
a widely known high-speed solution to a widely known problem, and it's
time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
---
Changes from v2->v3:
- The unaligned helpers are now used for rea
On Tue, Dec 13, 2016 at 12:01 AM, Andi Kleen wrote:
> It would be nice if the network code could be converted to use siphash
> for the secure sequence numbers. Right now it pulls in a lot of code
> for bigger secure hashes just for that, which is a problem for tiny
> kernels.
Indeed this would be
their kernels. SipHash is
a widely known high-speed solution to a widely known problem, and it's
time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
---
Changes from v3->v4:
- load_unaligned_zeropad is only called when left
Hi Eric,
On Tue, Dec 13, 2016 at 9:39 AM, Eric Biggers wrote:
> Hmm, I don't think you can really do load_unaligned_zeropad() without first
> checking for 'left != 0'. The fixup section for load_unaligned_zeropad()
> assumes that rounding the pointer down to a word boundary will produce an
> add
Hi Linus,
On Tue, Dec 13, 2016 at 8:25 PM, Linus Torvalds
wrote:
> Yeah,. the TCP sequence number md5_transform() cases are likely the
> best example of something where siphash might be good. That tends to
> be really just a couple words of data (the address and port info) plus
> the net_secret[]
the call chain does add a degree of natural entropy. So, in keeping with
this design, instead of the massive per-cpu 64-byte md5 state, there is
instead a per-cpu previously returned value for chaining.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
---
drivers/cha
their kernels. SipHash is
a widely known high-speed solution to a widely known problem, and it's
time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
Cc: Linus Torvalds
Cc: Eric Biggers
---
Changes from v1->v2:
- None in this patch, b
Many jhash users currently rely on the Nwords functions. In order to
make transitions to siphash fit something people already know about, we
provide analog functions here. This also winds up being nice for the
networking stack, where hashing 32-bit fields is common.
Signed-off-by: Jason A
the call chain does add a degree of natural entropy. So, in keeping with
this design, instead of the massive per-cpu 64-byte md5 state, there is
instead a per-cpu previously returned value for chaining.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Ted Tso
---
Changes from v1
ore/secure_seq.c b/net/core/secure_seq.c
index 88a8e429fc3e..abadc79cd5d3 100644
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -1,3 +1,5 @@
+/* Copyright (C) 2016 Jason A. Donenfeld . All Rights
Reserved. */
+
#include
#include
#include
@@ -8,14 +10,14 @@
#include
#incl
Hi David,
On Wed, Dec 14, 2016 at 10:56 AM, David Laight wrote:
> ...
>> +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN])
> ...
>> + u64 k0 = get_unaligned_le64(key);
>> + u64 k1 = get_unaligned_le64(key + sizeof(u64));
> ...
>> + m = get_unaligned_l
Hi David,
On Wed, Dec 14, 2016 at 10:51 AM, David Laight wrote:
> From: Jason A. Donenfeld
>> Sent: 14 December 2016 00:17
>> This gives a clear speed and security improvement. Rather than manually
>> filling MD5 buffers, we simply create a layout by a simple anonymous
>
Hi Hannes,
On Wed, Dec 14, 2016 at 12:21 PM, Hannes Frederic Sowa
wrote:
> Can you show or cite benchmarks in comparison with jhash? Last time I
> looked, especially for short inputs, siphash didn't beat jhash (also on
> all the 32 bit devices etc.).
I assume that jhash is likely faster than sip
Hi Hannes,
Thanks for the feedback.
> __packed not only removes all padding of the struct but also changes the
> alignment assumptions for the whole struct itself. The rule, the struct
> is aligned by its maximum alignment of a member is no longer true. That
> said, the code accessing this struct
On Wed, Dec 14, 2016 at 3:47 PM, David Laight wrote:
> Just remove the __packed and ensure that the structure is 'nice'.
> This includes ensuring there is no 'tail padding'.
> In some cases you'll need to put the port number into a 32bit field.
I'd rather not. There's no point in wasting extra cy
Hey Ted,
On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote:
> One somewhat undesirable aspect of the current algorithm is that we
> never change random_int_secret.
Why exactly would this be a problem? So long as the secret is kept
secret, the PRF is secure. If an attacker can read arbitrary k
Hi David,
On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote:
> Just marking the structure __packed, whether necessary or not, makes
> the compiler assume that the members are not aligned and causes
> byte-by-byte accesses to be performed for words.
> Never, _ever_, use __packed unless absolutel
's
time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
Cc: Linus Torvalds
Cc: Eric Biggers
Cc: David Laight
---
Changes from v2->v3:
- There is now a fast aligned version of the function and a not-as-fast
unaligned version. The
1 file changed, 85 insertions(+), 81 deletions(-)
diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
index 88a8e429fc3e..00eb141c981b 100644
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -1,3 +1,5 @@
+/* Copyright (C) 2016 Jason A. Donenfeld . All Rights
Reserved. */
+
#incl
the call chain does add a degree of natural entropy. So, in keeping with
this design, instead of the massive per-cpu 64-byte md5 state, there is
instead a per-cpu previously returned value for chaining.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Ted Tso
---
Changes from v2-&g
Hi again,
On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote:
> [3.606139] random benchmark!!
> [3.606276] get_random_int # cycles: 326578
> [3.606317] get_random_int_new # cycles: 95438
> [3.607423] get_random_bytes # cycles: 2653388
Looks to me like my siphash implementation
Hi Tom,
On Wed, Dec 14, 2016 at 8:18 PM, Tom Herbert wrote:
> "super fast" is relative. My quick test shows that this faster than
> Toeplitz (good, but not exactly hard to achieve), but is about 4x
> slower than jhash.
Fast relative to other cryptographically secure PRFs.
>> SipHash isn't just
Hi Hannes,
On Wed, Dec 14, 2016 at 8:22 PM, Hannes Frederic Sowa
wrote:
> I don't think this helps. Did you test it? I don't see reason why
> padding could be left out between `d' and `end' because of the flexible
> array member?
Because the type u8 doesn't require any alignment requirements, it
Hi Hannes,
On Wed, Dec 14, 2016 at 4:09 PM, Hannes Frederic Sowa
wrote:
> Yes, numbers would be very usable here. I am mostly concerned about
> small plastic router cases. E.g. assume you double packet processing
> time with a change of the hashing function at what point is the actual
> packet pr
Hey Tom,
Just following up on what I mentioned in my last email...
On Wed, Dec 14, 2016 at 8:35 PM, Jason A. Donenfeld wrote:
> I think your suggestion for (2) will contribute to further
> optimizations for (1). In v2, I had another patch in there adding
> siphash_1word, siphash_2w
On Wed, Dec 14, 2016 at 9:12 PM, Tom Herbert wrote:
> If you pad the data structure to 64 bits then we can call the version
> of siphash that only deals in 64 bit words. Writing a zero in the
> padding will be cheaper than dealing with odd lengths in siphash24.
On Wed, Dec 14, 2016 at 9:27 PM, Han
Interesting. Evidently gcc 4.8 doesn't like my use of:
enum siphash_lengths {
SIPHASH24_KEY_LEN = 16,
SIPHASH24_ALIGNMENT = 8
};
I'll convert this to the more boring:
#define SIPHASH24_KEY_LEN 16
#define SIPHASH24_ALIGNMENT 8
--
To unsubscribe from this list: send the line "unsubsc
Hey Tom,
On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert wrote:
> Those look good, although I would probably just do 1,2,3 words and
> then have a function that takes n words like jhash. Might want to call
> these dword to distinguish from 32 bit words in jhash.
So actually jhash_Nwords makes no s
Hey Tom,
On Thu, Dec 15, 2016 at 12:14 AM, Tom Herbert wrote:
> I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword
> functions are good enough. If someone needs to hash over some odd
> length they can either put them in a structure padded to 64 bits or
> call the hash function that
Hi Hannes,
On Wed, Dec 14, 2016 at 11:03 PM, Hannes Frederic Sowa
wrote:
> I fear that the alignment requirement will be a source of bugs on 32 bit
> machines, where you cannot even simply take a well aligned struct on a
> stack and put it into the normal siphash(aligned) function without
> addin
Hey Linus,
On Thu, Dec 15, 2016 at 12:30 AM, Linus Torvalds
wrote:
> No. The bug is talking about "words" in the first place.
>
> Depending on your background, a "word" can be generally be either 16
> bits or 32 bits (or, in some cases, 18 bits).
>
> In theory, a 64-bit entity can be a "word" too
Hey Ted,
On Wed, Dec 14, 2016 at 8:12 PM, Jason A. Donenfeld wrote:
> I think this opens up a big window for optimizing it even
> further.
I optimized it a bit further and siphash is now the clear winner over chacha:
[1.784801] random benchmark!!
[1.785161] get_random_long #
d5| speedup |
--
get_random_long | 137130 | 415983 | 3.03x |
get_random_int | 86384 | 343323 | 3.97x |
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Ted Tso
---
Changes from v3->v4:
- Speedups by using the 3qwords function.
drivers/
values directly to the
short input convenience functions.
Signed-off-by: Jason A. Donenfeld
Cc: Andi Kleen
Cc: David Miller
Cc: David Laight
Cc: Tom Herbert
Cc: Hannes Frederic Sowa
---
Changes from v3->v4:
- For the IPv4 cases, we can now use the Ndwords helper functions,
which m
These restore parity with the jhash interface by providing high
performance helpers for common input sizes.
Linus doesn't like the use of "qword" and "dword", but I haven't been
able to come up with another name for these that fits as well.
Signed-off-by: Jason
a widely known high-speed solution to a widely known problem, and it's
time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
Cc: Linus Torvalds
Cc: Eric Biggers
Cc: David Laight
---
Changes from v3->v4:
- Renamed from siphash24
Hi David,
On Thu, Dec 15, 2016 at 11:14 AM, David Laight wrote:
> From: Behalf Of Jason A. Donenfeld
>> Sent: 14 December 2016 18:46
> ...
>> + ret = *chaining = siphash24((u8 *)&combined,
>> offsetof(typeof(combined), end),
>
> If you make the first argu
Hi David & Hannes,
This conversation is veering off course. I think this doesn't really
matter at all. Gcc converts u64 into essentially a pair of u32 on
32-bit platforms, so the alignment requirements for 32-bit is at a
maximum 32 bits. On 64-bit platforms the alignment requirements are
related a
d5| speedup |
--
get_random_long | 137130 | 415983 | 3.03x |
get_random_int | 86384 | 343323 | 3.97x |
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Ted Tso
---
drivers/char/random.c | 32 +---
1 file changed, 13 insertions(+
values directly to the
short input convenience functions.
Signed-off-by: Jason A. Donenfeld
Cc: Andi Kleen
Cc: David Miller
Cc: David Laight
Cc: Tom Herbert
Cc: Hannes Frederic Sowa
---
net/core/secure_seq.c | 133 --
1 file changed, 52
ooks good to you, please send along your Reviewed-by,
so we can begin to get this completed. If there are still lingering issues,
let me know and I'll incorporated them into a v6 if necessary.
Thanks,
Jason
Jason A. Donenfeld (4):
siphash: add cryptographically secure PRF
siphash: add Nu{
a widely known high-speed solution to a widely known set of
problems, and it's time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Daniel J. Bernstein
Cc: Linus Torvalds
Cc: Eric Biggers
Cc: David Laight
---
include/linux/siphash.h | 32 +++
These restore parity with the jhash interface by providing high
performance helpers for common input sizes.
Signed-off-by: Jason A. Donenfeld
Cc: Tom Herbert
---
include/linux/siphash.h | 33 ++
lib/siphash.c | 157 +---
lib
On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa
wrote:
> ARM64 and x86-64 have memory operations that are not vector operations
> that operate on 128 bit memory.
Fair enough. imull I guess.
> How do you know that the compiler for some architecture will not chose a
> more optimized instruct
On Thu, Dec 15, 2016 at 10:09 PM, Peter Zijlstra 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.
On Thu, Dec 15, 2016 at 10:14 PM, Linus Torvalds
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 sho
On Thu, Dec 15, 2016 at 10:17 PM, Hannes Frederic Sowa
wrote:
> And I was exactly questioning this.
>
> static unsigned int inet6_hash_frag(__be32 id, const struct in6_addr *saddr,
> const struct in6_addr *daddr)
> {
> net_get_random_once(&ip6_frags.rnd,
Hi Hannes,
Good news.
On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa
wrote:
>> How's that sound?
>
> I am still very much concerned about the API.
Thanks for pushing me and putting up with my daftness... the constant
folding works absolutely perfectly. I've run several tests. When gcc
k
On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa
wrote:
> By the way, if you target net-next, it is currently closed. So no need
> to hurry.
Honestly I have no idea what I'm targeting. The hash function touches
lib/. The secure_seq stuff touches net/. The rng stuff touches
random.c. Shall t
ions, so that in case you disappear your useful
reviews will still keep the ball moving.
Thanks for all the great feedback thus far.
Jason
Jason A. Donenfeld (5):
siphash: add cryptographically secure PRF
secure_seq: use SipHash in place of MD5
random: use SipHash in place of MD5
md5:
since there are more modern ways of doing what it once achieved.
Signed-off-by: Jason A. Donenfeld
---
crypto/md5.c | 95 +++-
lib/Makefile | 2 +-
lib/md5.c| 95
3 files change
values directly to the
short input convenience functions.
Signed-off-by: Jason A. Donenfeld
Cc: Andi Kleen
Cc: David Miller
Cc: David Laight
Cc: Tom Herbert
Cc: Hannes Frederic Sowa
---
net/core/secure_seq.c | 133 --
1 file changed, 52
SHA1 is slower and less secure than SipHash, and so replacing syncookie
generation with SipHash makes natural sense. Some BSDs have been doing
this for several years in fact.
Signed-off-by: Jason A. Donenfeld
---
net/ipv4/syncookies.c | 20
net/ipv6/syncookies.c | 37
d5| speedup |
--
get_random_long | 137130 | 415983 | 3.03x |
get_random_int | 86384 | 343323 | 3.97x |
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Ted Tso
---
drivers/char/random.c | 32 +---
1 file changed, 13 insertions(+
in their kernels.
SipHash is a widely known high-speed solution to a widely known set of
problems, and it's time we catch-up.
Signed-off-by: Jason A. Donenfeld
Cc: Jean-Philippe Aumasson
Cc: Linus Torvalds
Cc: Eric Biggers
Cc: David Laight
---
MAINTAINERS | 7 ++
Hey JP,
On Fri, Dec 16, 2016 at 9:08 AM, Jean-Philippe Aumasson
wrote:
> Here's a tentative HalfSipHash:
> https://github.com/veorq/SipHash/blob/halfsiphash/halfsiphash.c
>
> Haven't computed the cycle count nor measured its speed.
This is incredible. Really. Wow!
I'll integrate this into my pa
Hi JP & George,
My function names:
- SipHash -> siphash
- HalfSipHash -> hsiphash
It appears that hsiphash can produce either 32-bit output or 64-bit
output, with the output length parameter as part of the hash algorithm
in there. When I code this for my kernel patchset, I very likely will
only i
Hi David,
On Fri, Dec 16, 2016 at 10:59 AM, David Laight wrote:
> You are still putting over-aligned data on stack.
> You only need to align it to the alignment of u64 (not the size of u64).
> If an on-stack item has a stronger alignment requirement than the stack
> the gcc has to generate two st
Hi David,
On Fri, Dec 16, 2016 at 6:06 PM, David Laight wrote:
> A 32bit hash would also remove all the issues about the alignment
> of IP addresses (etc) on 64bit systems.
The current replacements of md5_transform with siphash in the v6 patch
series will continue to use the original siphash, si
Hi George,
On Fri, Dec 16, 2016 at 6:36 PM, George Spelvin
wrote:
> A 128-bit output option was added to SipHash after the initial publication;
> this is just the equivalent in 32-bit.
> Personally, I'd put in a comment saying that "there's a 64-bit output
> variant that's not implemented" and pu
Hi JP,
On Fri, Dec 16, 2016 at 2:22 PM, Jean-Philippe Aumasson
wrote:
> It needs some basic security review, which I'll try do next week (check for
> security margin, optimality of rotation counts, etc.). But after a lot of
> experience with this kind of construction (BLAKE, SipHash, NORX), I'm
>
On Fri, Dec 16, 2016 at 9:41 PM, George Spelvin
wrote:
> What are you testing on? And what input size? And does "33% improvement"
> mean 4/3 the rate and 3/4 the time? Or 2/3 the time and 3/2 the rate?
How that I've published my hsiphash implementation to my tree, it
should be possible to cond
On Fri, Dec 16, 2016 at 9:17 PM, George Spelvin
wrote:
> My (speaking enerally; I should walk through every hash table you've
> converted) opinion is that:
>
> - Hash tables, even network-facing ones, can all use hsiphash as long
> as an attacker can only see collisions, i.e. ((H(x) ^ H(y)) & bi
Hi Ted,
On Fri, Dec 16, 2016 at 9:43 PM, Theodore Ts'o wrote:
> What should we do with get_random_int() and get_random_long()? In
> some cases it's being used in performance sensitive areas, and where
> anti-DoS protection might be enough. In others, maybe not so much.
>
> If we rekeyed the sec
Hi Daniel,
On Fri, Dec 16, 2016 at 9:44 PM, Daniel Micay wrote:
> On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote:
>>
>> That's about 3x of jhash speed (7 nsecs). So that might closer
>> to a more palatable replacement for jhash. Do we lose any security
>> advantages with halfsiphash?
>
> Ha
Hi George,
On Fri, Dec 16, 2016 at 10:25 PM, George Spelvin
wrote:
> But yes, the sequence number is supposed to be (random base) + (timestamp).
> In the old days before Canter & Siegel when the internet was a nice place,
> people just used a counter that started at boot time.
>
> But then someon
Hi Andy,
On Fri, Dec 16, 2016 at 10:31 PM, Andy Lutomirski wrote:
> I think it would be nice to try to strenghen the PRNG construction.
> FWIW, I'm not an expert in PRNGs, and there's fairly extensive
> literature, but I can at least try.
In an effort to keep this patchset as initially as uncont
Hi Andy, Ted,
I've made the requested changes. Keys now rotate and are per-CPU
based. The chaining value is now additive instead of replacing.
DavidL suggested I lower the velocity of `git-send-email` triggers, so
if you'd like to take a look at this before I post v7, you can follow
along at my g
On Fri, Dec 16, 2016 at 11:13 PM, George Spelvin
wrote:
> Remembering that on "real" machines it's full SipHash, then I'd say that
> 64-bit security + rekeying seems reasonable.
64-bit security for an RNG is not reasonable even with rekeying. No no
no. Considering we already have a massive speed-
Hi Andy,
> Agreed. A simpler contruction would be:
>
> chaining++;
> output = H(chaining, secret);
>
> And this looks a whole lot like Ted's ChaCha20 construction.
In that simpler construction with counter-based secret rekeying and in
Ted's ChaCha20 construction, the issue is that every X hits,
On Sat, Dec 17, 2016 at 12:44 AM, George Spelvin
wrote:
> Ths advice I'd give now is:
> - Implement
> unsigned long hsiphash(const void *data, size_t len, const unsigned long
> key[2])
> .. as SipHash on 64-bit (maybe SipHash-1-3, still being discussed) and
> HalfSipHash on 32-bit.
I already
On Sat, Dec 17, 2016 at 3:55 PM, Jeffrey Walton wrote:
> It may be prudent to include the endian reversal in the test to ensure
> big endian machines produce expected results. Some closely related
> testing on an old Apple PowerMac G5 revealed that result needed to be
> reversed before returning i
Hi Ted,
On Sat, Dec 17, 2016 at 4:41 PM, Theodore Ts'o wrote:
> On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote:
>> >> - Ted, Andy Lutorminski and I will try to figure out a construction of
>> >> get_random_long() that we all like.
>
> We don't have to find the most optimal solut
Hi JP,
With the threads getting confusing, I've been urged to try and keep
the topics and threads more closely constrained. Here's where we're
at, and here's the current pressing security concern. It'd be helpful
to have a definitive statement on what you think is best, so we can
just build on top
1 - 100 of 660 matches
Mail list logo
