These are a bunch of code cleanups I worked out a couple of years ago,
split up into least publishable units. They're logically independent,
although some overlap so will take some fixing to apply without the
earlier ones.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto
Did that mixture of shifting by 8 and 16 generate better code
on some architecture? This is easier to read.
---
crypto/des_generic.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/crypto/des_generic.c b/crypto/des_generic.c
index afde5b4..1b74adf
I think a modern compiler can do without the step-by-step
instructions and schedule it pretty well by itself.
---
crypto/des_generic.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/crypto/des_generic.c b/crypto/des_generic.c
index
It was using the array name implicitly, or to be precise, macros it was
calling were using it implicitly. Changed so it's explicit.
(And the sub-macros were inlined as unnecessary.)
---
crypto/des_generic.c | 135 --
1 files changed, 65
des3_ede_setkey now ignores unused bits (often used for parity)
when comparing keys to report weak combinations.
---
crypto/des_generic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/des_generic.c b/crypto/des_generic.c
index 24d7f93..d9a81d8 100644
---
---
crypto/des_generic.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/crypto/des_generic.c b/crypto/des_generic.c
index d9a81d8..647189e 100644
--- a/crypto/des_generic.c
+++ b/crypto/des_generic.c
@@ -934,9 +934,7 @@ MODULE_ALIAS(des3_ede);
static int __init
---
crypto/des_generic.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/crypto/des_generic.c b/crypto/des_generic.c
index a4f3165..ff95f7b 100644
--- a/crypto/des_generic.c
+++ b/crypto/des_generic.c
@@ -67,6 +67,12 @@ static const u8 pc1[256] = {
One basic question... why limit this to /dev/random?
If we're trying to avoid fd exhaustion attacks, wouldn't an atomically
read a file into a buffer system call (that could be used on
/dev/urandom, or /etc/hostname, or /proc/foo, or...) be more useful?
E.g.
ssize_t readat(int dirfd, char const
In the end people would just recall getentropy in a loop and fetch 256
bytes each time. I don't think the artificial limit does make any sense.
I agree that this allows a potential misuse of the interface, but
doesn't a warning in dmesg suffice?
It makes their code not work, so they can are
I don't like partial reads/writes and think that a lot of people get
them wrong, because they often only check for negative return values.
The v1 patch, which did it right IMHO, didn't do partial reads in the
case we're talking about:
+ if (count 256)
+ return -EINVAL;
I keep wishing for a more general solution. For example, some way to
have a spare extra fd that could be accessed with a special O_NOFAIL
flag.
That would allow any number of library functions to not fail, such as
logging from nasty corner cases.
But you'd have to provide one per thread, and
I've been trying to understand the crypto layer, and it's a bit of a
struggle because I'm trying to learn how it's supposed to work by
reading the code, and I keep finding code I want to fix.
ansi_cprng.c is the current itch I'm eager to scratch.
Other than enough implementation stupidities to
I'm trying to understand the Linux crypto layer, and a lot of
the code I read for guidance I instead end up wanting to fix.
My current itch to scratch is crypto/ansi_cprng.c.
There is a lot of questionable code I'll submit patches for, particularly:
- The rand_data_valid variable, which is
Sorry for the duplicate; I had a crash and I thought the mail was lost.
First message was not quite finished, second is a rewrite from scratch.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Other than enough implementation stupidities to make me scream
(particularly the rand_data_valid variable name which is actually a
Its actually a counter of the number of valid random data bytes in the buffer
being returned to a caller, as well as an index into the internal buffer from
which
The other one, which I have to think *very* hard about, is whether
using the same seed material as /dev/random in this much weaker
cryptographic construction will introduce a flaw in *it*.
I have no idea what you are referring to here. The caller is requred to
seed the DRNG. Typically that
See Documentation/DocBook/crypto-API.tmpl in the cryptodev-2.6 tree.
There you will find tons of documentation (which will be merged during
3.19-rc1)
Yes, I've been reading that. It certainly helps a great deal, but
still leaves me with some significant questions.
I started researching the
Thank you all for your hospitality to my amateurish efforts.
Given that this all started with me reading the code in an attempt to
understand it, it is likely that some of the problems I address are
actually misunderstandings on my part. If all I get from this patch series
is some enlightenment,
It's more like rand_data_invalid (data which has already been output),
so it's a pretty bad misnomer. But rand_data_pos is even better.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff
It's simply not necessary.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index c9e1684b..c0a27288 100644
--- a/crypto
It doesn't need a second input or a length parameter.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 6b844f13..4856c84c7 100644
--- a/crypto
-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Patch 15 is a prerequisite for this one.
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 4ed7c0cf..875c4bf9 100644
--- a/crypto/ansi_cprng.c
+++ b/crypto
From smuel...@chronox.de Tue Dec 02 08:57:23 2014
X-AuthUser: s...@eperm.de
From: Stephan Mueller smuel...@chronox.de
To: George Spelvin li...@horizon.com
Cc: herb...@gondor.apana.org.au, nhor...@tuxdriver.com,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH 02/17] crypto: ansi_cprng - Eliminate
if (byte_count DEFAULT_BLK_SZ) {
empty_rbuf:
- while (ctx-rand_data_valid DEFAULT_BLK_SZ) {
- *ptr = ctx-rand_data[ctx-rand_data_valid];
- ptr++;
- byte_count--;
- ctx-rand_data_valid++;
-
That is an old version. The updated version (published in 2005), and
specified in the ansi_cprng.c file removes that language.
Oh! Thank you! I'm pretty sure I read the 1998 version.
In fact, apparently there's a 2010 version:
http://www.codesdownload.org/3761-ANSI-X9-TR-31-2010.html
I
Not sure what you're concerned about, or what you're even referencing.
Sorry for the confusion, but it's genuine. See below for what I think is
the solution.
The shash_desc structure represents a discrete block of data that is
being hashed. It can be updated with new data, reset, finalized,
NACK
The assumption that its not needed is incorrect. In fips mode its explicitly
needed to validate that the rng isn't reproducing identical random data.
Please take a second look. The validation is still there; I fully
understand that and preserved that. (Well, I broke it later getting
I'm only ok with removing I if you can continue to be able to output it.
given that I is listed as part of the test sequences that NIST provides,
I'd like to be able to compare the values.
I can do that easily, but I can't print the *input* I, which
is the result of encrypting the previous DT,
--- a/crypto/ansi_cprng.c
+++ b/crypto/ansi_cprng.c
@@ -51,9 +51,9 @@ struct prng_context {
unsigned char rand_data[DEFAULT_BLK_SZ];
unsigned char DT[DEFAULT_BLK_SZ];
unsigned char V[DEFAULT_BLK_SZ];
-u32 rand_read_pos; /* Offset into rand_data[] */
+unsigned
The order of the v1 patches is somewhat in order of increasing scale,
reflecting my learning about the code. But if this unroll is okay,
it would probably make the most sense to reorder things so it's
first and then other changes can be made on top of the simpler code.
Given the unusual
So, generally speaking I'm ok with most of this I think,
One open issue... I thought you had said that the non-determinsitic
version was not in the current X9.31 and I had the impression that it
wasn't wanted. I've got reorganized patch series that gets rid of that
and just tweaks the comments.
It's more legible, and the code is 16 bytes smaller (i386).
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 91 +
1 file changed, 35 insertions(+), 56 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto
to know what result format is wanted.
* Stephan says he has the FIPS test vectors referred to above and
will send them to me when he finds them.
* Is non-deterministic mode (last three patches) wanted?
George Spelvin (25):
crypto: ansi_cprng - unroll _get_more_prng_bytes
crypto: ansi_cprng
The local variable output is no longer required.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index ce315bf7..143e0cfa 100644
--- a/crypto
This uses more meaningful labels (if you have the spec as a
reference), and avoids printing some stuff (like the original DT)
twice.
It also strips out the len parameter and uses a fixed length of
DEFAULT_BLK_SZ.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 25
Calling the lower-level function does what's needed with less overhead.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index f6a1e987..249b944f 100644
This ensures alignment and makes xor_block more efficient,
but it's mostly in preparation for later changes.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 73 ++---
1 file changed, 41 insertions(+), 32 deletions(-)
diff
If crypto_rng_get_bytes returns an error code, returning it is a good
idea, but if it simply returns zero, the test shouldn't abort successfully.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/testmgr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/testmgr.c b/crypto
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c| 11 ++-
crypto/krng.c | 2 +-
crypto/rng.c | 3 ++-
include/crypto/rng.h | 2 +-
include/linux/crypto.h | 6 --
5 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/crypto
Careful use of the other available buffers avoids the need for
these, shrinking the context by 32 bytes.
Neither the debug output nor the FIPS-required anti-repetition check
are changed in the slightest.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 50
a CPRNG
that's not deterministic.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 52
1 file changed, 40 insertions(+), 12 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 4d256d74..d39ce301
-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 74 ++---
1 file changed, 25 insertions(+), 49 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index c1c81266..a8cf98a5 100644
--- a/crypto/ansi_cprng.c
+++ b/crypto
possible alignment in
the CPRNG's internal buffer.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/testmgr.c | 98 ++--
1 file changed, 89 insertions(+), 9 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6bf43682
Since it counts the number of bytes in rand_data which have been output,
and are no longer available for output, it's hardly a count of
valid bytes. rand_data_pos is more appropriate.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 10 +-
1 file changed, 5
It doesn't need a second input or a length parameter.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index a8cf98a5..f345b575 100644
--- a/crypto
The standards documents are silent on how to handle multi-part
output, so this is an RFC for something in the spirit of the
source specifications, but not actually required by them.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 12 +++-
1 file changed, 7
Huge diff, but simple.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/tcrypt.c | 46 +++
crypto/tcrypt.h | 30 ++--
crypto/testmgr.c | 58
crypto/testmgr.h | 410 +++
4 files changed, 276 insertions(+), 268
The current code stores three pointers to three arrays, and three lengths,
and then has to kmalloc an array just to concatenate them.
This seems ridiculous. Just store one combined array and combined
length, and don't do any reformatting at run-time.
Signed-off-by: George Spelvin li
This makes no difference to the generated code, but I like to use bool
where appropriate for documentation.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto
The PRNG_NEEDS_RESET flag ensures that it will be called, so
reset_prng_context() no longer needs to support NULL key and V pointers.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 47 ++-
1 file changed, 14 insertions(+), 33
ctx-flags only has 2 bits assigned, so there's no need for a
32-bit field. Likewise, rand_data_valid is at most 16.
A typical x86 spinlock_t is 16 bits, so they fit very nicely
right next to it, shrinking the 64-bit context structure to
64 bytes.
Signed-off-by: George Spelvin li...@horizon.com
Since the goal is to compare to NIST test vectors, which are printed
on a single like without spaces, this comes much closer.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/ansi_cprng.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/crypto/ansi_cprng.c b
The idea is to catch as many programmer mistakes as possible.
Signed-off-by: George Spelvin li...@horizon.com
---
crypto/testmgr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 9faf265f..6bf43682 100644
--- a/crypto/testmgr.c
+++ b/crypto
It's not based on the NIST-recommended algorithm, it *is* the
NIST-recommended algorithm, and has even passed their validation
tests.
Also make clear that it's intended to be a determinsitic generator,
despite the confusing name of the DT vector.
Signed-off-by: George Spelvin li...@horizon.com
By the way, this patch includes a bug due to a last minute oh, I can
make that more efficient! which I realized after a night's sleep.
(The v1 patch worked, FWIW.)
Anyway, it's an RFC; I'm not even sure if I want this personally,
but it's a bit of extra paranoia to always genreate fresh seed per
Not your motivations, just the posting mechanics. If you just want to
discuss a patch, and aren't yet proposing it for inclusion, you should
put RFC in the prefix of every patch header.
I understand the principle, and I should have on those patches (mea
culpa), but really *all* patch postings
Due to the huge number of diffs, I may have missed the following point.
Therefore, please help me:
No problem at all! If you're doing me the kindness of actually reading
and reviewing this, I have *lots* of time to act as a tour guide.
I've just had my nose in this code, and your memory is
Pending issues:
* Neil would like me to post the results of the NIST and FIPS test
vectors. The current code doesn't print anything on a successful
test; I need to know what result format is wanted.
* Stephan says he has the FIPS test vectors referred to above and
will send them to me
I have send these vectors about a week ago. Do you have results?
BTW, here is my current home-grown debugging output.
With some minor editor massaging (deleting the timestamps and
inserting a blank line before every COUNT line), it matches the
ANSI931_AES128MCT.fax and ANSI931_AES128VST.fax you
That output is good for the VST test vectors. For the MCT vectors, I need the
1th value.
That was test 9 in the first group:
[167586.784923] COUNT = 9
[167586.784925] Key = 10379b53317a2500879e88ad445ea387
[167586.784927] DT = 055a913d7587d54ee58c053fd4beb4a2
[167586.784928] V =
- the non-determinism you get from get_random_int is very weak. If you start
thinking about the information theoretical entropy behind that function that
is used once in a while, you may not get much entropy. Please, please, please,
I do not want to start a discussion around entropy -- I will
If you look into other X9.31 implementations, you see that the DT vector
is a time stamp (even sometimes initialized to just 0 or 1) and then
incremented each time. Thus, you get some form of a counter mode for
the AES core.
I'm not saying you're wrong, but that still seems to me an
With that then, I'm really fine with the changes given that they pass the NIST
tests.
So here's the current list of issues. First, minor ones:
1) Add const to DRBG interface, as per Stephan's request.
2) Revised version of that final patch that, you know, actually works.
3) Re-run tests at the
And now my head-scratching: your bisect shows that v3.19-rc7 fails,
but that prior to 4943ba16bbc2, things work correctly? As in, when
_only_ 5d26a105b5a7 is in your tree things _work_?
Basically, yes. v3.19-rc7 fails with basically the same symptoms:
wpa_supplicant keeps looping trying to
I discovered when (belatedly) testing 3.19-rc7 the other week that
my laptop wifi was broken and would no longer associate.
I wasted a lot of time trying to bisect changes in net/wireless and
net/drivers wireless before figuring out that it was sonewhere else in
the kernel. An unrestricted
Sorry for the long silence; the last e-mails arrived as I went on a trip,
and the packet got lost.
I just upgraded my laptop to 4.0.1 and had to remember the magic
incantation to get the wireless working. (modprobe ctr)
George, any updates on this?
It turns out that I found the problem. An
I'll be a while going through this.
I was thinking about our earlier discussion where I was hammering on
the point that compressing entropy too early is a mistake, and just
now realized that I should have given you credit for my recent 4.7-rc1
patch 2a18da7a. The hash function ("good, fast AND
> With that being said, wouldn't it make sense to:
>
> - Get rid of the entropy heuristic entirely and just assume a fixed value of
> entropy for a given event?
What does that gain you? You can always impose an upper bound, but *some*
evidence that it's not a metronome is nice to have.
> -
>From smuel...@chronox.de Fri Apr 29 04:56:49 2016
From: Stephan Mueller <smuel...@chronox.de>
To: George Spelvin <li...@horizon.com>
Cc: herb...@gondor.apana.org.au, linux-crypto@vger.kernel.org,
linux-ker...@vger.kernel.org, sandyinch...@gmail.com, ty...@mit.edu
Subject: Re: ra
(Note that we have two chains of e-mails crossing mid-stream. I'm in
the middle of working on a much longer reply to your previous e-mail.)
>> They're not independent, nor are they identically distributed.
> That is an interesting statement: you say that the time stamp has holes
> in it, i.e.
> I think there is a slight mixup: IID is not related to an attacker
> predicting things. IID is simply a statistical measure, it is either there
> or not. It does not depend on an attacker (assuming that the attacker
> cannot change the data). Note, the IID is only needed to claim that the
> XOR
Schrieb Stephan Mueller:
> Am Montag, 25. April 2016, 21:59:43 schrieb George Spelvin:
>> Indeed, this is an incredibly popular novice mistake and I don't
>> understand why people keep making it.
> Can you please elaborate on your statement to help me understanding the issue
> And considering that I only want to have 0.9 bits of entropy, why
> should I not collapse it? The XOR operation does not destroy the existing
> entropy, it only caps it to at most one bit of information theoretical
> entropy.
No. Absolutely, demonstrably false.
The XOR operation certainly
I'd like to apologise for the harsh tone of my earlier message.
I was frustrated, and it showed.
I hope I can be more gentle as I continue to elaborate on the shortcomings
of that scheme.
Concentrating entropy is hard. To paraphrase Princess Leia, "the more
you tighten your grip, the more
I just discovered this huge conversation and am trying to read it all
and get caught up.
I know I should finish reading before I start writing, but too many ideas
are bubbling up.
> not the rest of Stephan's input handling code: the parity
> calculation and XORing the resulting single bit into
> What I am saying that the bits in one given time stamp are mutually
> independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that
> very same time stamp.
And I'm saying that's wrong.
We are interested in the correlation from the point of view of someone
who knows all previous
> I think we can agree that we disagree.
Yes, we agree on that, at least!
The problem is, this is supposed to be a matter of fact, not opinion,
so there should be one right answer.
I suppose it's possible it's still an issue of terminology, but we've
exhausted
> Though, I will get back to the
> We have actually gained quite a bit of documentation recently.
> Have you looked at Documentation/DocBook/crypto-API.tmpl?
>
> More is always welcome of course.
It's improved since I last looked at it, but there are still many structures
that aren't described:
- struct crypto_instance
-
>> Also not mentioned in the documentation is that some algorithms *do*
>> have different implementations depending on key size. SHA-2 is the
>> classic example.
> What do you mean by that? SHA has no keying at all.
In this case, the analagous property is hash size. Sorry, I thought
that was
to
crypto_cipher_encrypt_one() or avoid stack buffers entirely.
commit c0aa0ae38dc6115b378939c5483ba6c7eb65d92a
Author: George Spelvin <li...@sciencehorizons.net>
Date: Sat Oct 10 17:26:08 2015 -0400
crypto: cts - Reduce internal buffer usage
It only takes a 3-block temporary buffer to
> There's a 32-bit secret random salt (inet_ehash_secret) which means
> that in practice, inet_ehashfn() will select 1 out of 2^32 different
> hash functions at random each time you boot the kernel; without
> knowing which one it selected, how can a local or remote attacker can
> force IPv4
> If a halved version of SipHash can bring significant performance boost
> (with 32b words instead of 64b words) with an acceptable security level
> (64-bit enough?) then we may design such a version.
I was thinking if the key could be pushed to 80 bits, that would be nice,
but honestly 64 bits
> While SipHash is extremely fast for a cryptographically secure function,
> it is likely a tiny bit slower than the insecure jhash, and so replacements
> will be evaluated on a case-by-case basis based on whether or not the
> difference in speed is negligible and whether or not the current jhash
Jean-Philippe Aumasson wrote:
> If a halved version of SipHash can bring significant performance boost
> (with 32b words instead of 64b words) with an acceptable security level
> (64-bit enough?) then we may design such a version.
It would be fairly significant, a 2x speed benefit on a lot of
Jason A. Donenfeld wrote:
> Isn't that equivalent to:
> v0 = key[0];
> v1 = key[1];
> v2 = key[0] ^ (0x736f6d6570736575ULL ^ 0x646f72616e646f6dULL);
> v3 = key[1] ^ (0x646f72616e646f6dULL ^ 0x7465646279746573ULL);
(Pre-XORing key[] with the first two constants which, if
> 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 implement one output length size. Right now I'm leaning toward
> 32-bit.
A
BTW, here's some SipHash code I wrote for Linux a while ago.
My target application was ext4 directory hashing, resulting in different
implementation choices, although I still think that a rolled-up
implementation like this is reasonable. Reducing I-cache impact speeds
up the calling code.
One
To follow up on my comments that your benchmark results were peculiar,
here's my benchmark code.
It just computes the hash of all n*(n+1)/2 possible non-empty substrings
of a buffer of n (called "max" below) bytes. "cpb" is "cycles per byte".
(The average length is (n+2)/3, c.f.
Jason A. Donenfeld wrote:
> I saw that jiffies addition in there and was wondering what it was all
> about. It's currently added _after_ the siphash input, not before, to
> keep with how the old algorithm worked. I'm not sure if this is
> correct or if there's something wrong with that, as I
>> On a 64-bit machine, 64-bit SipHash is *always* faster than 32-bit, and
>> should be used always. Don't even compile the 32-bit code, to prevent
>> anyone accidentally using it, and make hsiphash an alias for siphash.
> Fascinating! Okay. So I'll alias hsiphash to siphash on 64-bit then. I
>
Tom Herbert wrote:
> Tested this. Distribution and avalanche effect are still good. Speed
> wise I see about a 33% improvement over siphash (20 nsecs/op versus 32
> nsecs). That's about 3x of jhash speed (7 nsecs). So that might closer
> to a more palatable replacement for jhash. Do we lose any
Theodore Ts'o wrote:
> On Mon, Dec 19, 2016 at 06:32:44PM +0100, Jason A. Donenfeld wrote:
>> 1) Anything that requires actual long-term security will use
>> SipHash2-4, with the 64-bit output and the 128-bit key. This includes
>> things like TCP sequence numbers. This seems pretty uncontroversial
> I do not see why SipHash, if faster than MD5 and more secure, would be a
> problem.
Because on 32-bit x86, it's slower.
Cycles per byte on 1024 bytes of data:
Pentium Core 2 Ivy
4 Duo Bridge
SipHash-2-4 38.9 8.3 5.8
Eric Dumazet wrote:
> On Tue, 2016-12-20 at 22:28 -0500, George Spelvin wrote:
>> Cycles per byte on 1024 bytes of data:
>> Pentium Core 2 Ivy
>> 4 Duo Bridge
>> SipHash-2-4 38.9 8.3 5.8
>>
David Laight wrote:
> From: George Spelvin
...
>> uint32_t
>> hsiphash24(char const *in, size_t len, uint32_t const key[2])
>> {
>> uint32_t c = key[0];
>> uint32_t d = key[1];
>> uint32_t a = 0x6c796765 ^ 0x736f6d65;
>> uint
Linus wrote:
>> How much does kernel_fpu_begin()/kernel_fpu_end() cost?
>
> It's now better than it used to be, but it's absolutely disastrous
> still. We're talking easily many hundreds of cycles. Under some loads,
> thousands.
I think I've been thoroughly dissuaded, but just to clarify one
Eric Dumazet wrote:
> Now I am quite confused.
>
> George said :
>> Cycles per byte on 1024 bytes of data:
>> Pentium Core 2 Ivy
>> 4 Duo Bridge
>> SipHash-2-4 38.9 8.3 5.8
>> HalfSipHash-2-4 12.7 4.5 3.2
>> MD5
Hannes Frederic Sowa wrote:
> In general this looks good, but bitbuffer needs to be protected from
> concurrent access, thus needing at least some atomic instruction and
> disabling of interrupts for the locking if done outside of
> get_random_long. Thus I liked your previous approach more where
Hannes Frederic Sowa wrote:
> On 24.12.2016 00:39, George Spelvin wrote:
>> We just finished discussing why 8 bytes isn't enough. If you only
>> feed back 8 bytes, an attacker who can do 2^64 computation can find it
>> (by guessing and computing forward to verify t
(Cc: list trimmed slightly as the topic is wandering a bit.)
Hannes Frederic Sowa wrote:
> On Thu, 2016-12-22 at 19:07 -0500, George Spelvin wrote:
>> Adding might_lock() annotations will improve coverage a lot.
>
> Might be hard to find the correct lock we take later down
1 - 100 of 114 matches
Mail list logo
