around.
> On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote:
>> For example, two mix-backs of 64 bits gives you 65 bit security, not 128.
>> (Because each mixback can be guessed and verified separately.)
> Exactly, but the full reseed after running out of entropy is strong
&g
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
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 yo
(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 the code
Hannes Frederic Sowa wrote:
> A lockdep test should still be done. ;)
Adding might_lock() annotations will improve coverage a lot.
> Yes, that does look nice indeed. Accounting for bits instead of bytes
> shouldn't be a huge problem either. Maybe it gets a bit more verbose in
> case you can't sat
> I do tend to like Ted's version in which we use batched
> get_random_bytes() output. If it's fast enough, it's simpler and lets
> us get the full strength of a CSPRNG.
With the ChaCha20 generator, that's fine, although note that this abandons
anti-backtracking entirely.
It also takes locks, so
> Having slept on this, I like it less. The problem is that a
> backtracking attacker doesn't just learn H(random seed || entropy_0 ||
> secret || ...) -- they learn the internal state of the hash function
> that generates that value. This probably breaks any attempt to apply
> security propertie
> True, but it's called get_random_int(), and it seems like making it
> stronger, especially if the performance cost is low to zero, is a good
> thing.
If it's cheap enough, I don't mind. But it's documented as being
marginal-quality, used where speed is more important.
In particular, it's *not*
Andy Lutomirski wrote:
> I don't even think it needs that. This is just adding a
> non-destructive final operation, right?
It is, but the problem is that SipHash is intended for *small* inputs,
so the standard implementations aren't broken into init/update/final
functions.
There's just one big f
> Plus the benchmark was bogus anyway, and when I built a more specific
> harness -- actually comparing the TCP sequence number functions --
> SipHash was faster than MD5, even on register starved x86. So I think
> we're fine and this chapter of the discussion can come to a close, in
> order to mov
As a separate message, to disentangle the threads, I'd like to
talk about get_random_long().
After some thinking, I still like the "state-preserving" construct
that's equivalent to the current MD5 code. Yes, we could just do
siphash(current_cpu || per_cpu_counter, global_key), but it's nice to
pr
Theodore Ts'o wrote:
> On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote:
>> SipHash annihilates the competition on 64-bit superscalar hardware.
>> SipHash dominates the field on 64-bit in-order hardware.
>> SipHash wins easily on 32-bit hardware *wit
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
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 thing
Actually, DJB just made a very relevant suggestion.
As I've mentioned, the 32-bit performance problems are an x86-specific
problem. ARM does very well, and other processors aren't bad at all.
SipHash fits very nicely (and runs very fast) in the MMX registers.
They're 64 bits, and there are 8 of
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
>>
> 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
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
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;
>> uint32_t
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. https://oeis.org
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 th
> I already did this. Check my branch.
Do you think it should return "u32" (as you currently have it) or
"unsigned long"? I thought the latter, since it doesn't cost any
more and makes more
> I wonder if this could also lead to a similar aliasing
> with arch_get_random_int, since I'm pretty sur
> 64-bit security for an RNG is not reasonable even with rekeying. No no
> no. Considering we already have a massive speed-up here with the
> secure version, there's zero reason to start weakening the security
> because we're trigger happy with our benchmarks. No no no.
Just to clarify, I was disc
An idea I had which mght be useful:
You could perhaps save two rounds in siphash_*u64.
The final word with the length (called "b" in your implementation)
only needs to be there if the input is variable-sized.
If every use of a given key is of a fixed-size input, you don't need
a length suffix.
> 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.
This is tricky. The entire get_random_int() structure is an abuse of
the hash function
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 haven'
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 sec
>> 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
> l
> 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 1
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 the
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 32-b
> 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 is
> 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 u
> 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 connect
>> 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 so
> 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
- struct
Herbert Xu wrote:
> I'm currently working on cts and I'm removing the stack usage
> altogether by having it operate on the src/dst SG lists only.
Wow, I should see how you do that. I couldn't get it below 3
blocks of temporary, and the dst SG list only gives you
one and a half.
> BTW, the only c
crypto_cipher_encrypt_one() or avoid stack buffers entirely.
commit c0aa0ae38dc6115b378939c5483ba6c7eb65d92a
Author: George Spelvin
Date: Sat Oct 10 17:26:08 2015 -0400
crypto: cts - Reduce internal buffer usage
It only takes a 3-block temporary buffer to handle all the tricky
CTS cases
> 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.
> - rem
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 ch
> 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 d
> 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 t
>> 1. It DOES depend on the attacker. Any statement about independence
>>depends on the available knowledge.
>> 2. XOR being entropy preserving depends on independence ONLY, it does
>>NOT depend on identical distribution. The latter is a red herring.
>>(An English metaphor for "irrele
> 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 w
(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. so
>From smuel...@chronox.de Fri Apr 29 04:56:49 2016
From: Stephan Mueller
To: George Spelvin
Cc: herb...@gondor.apana.org.au, linux-crypto@vger.kernel.org,
linux-ker...@vger.kernel.org, sandyinch...@gmail.com, ty...@mit.edu
Subject: Re: random(4) changes
Date: Thu, 28 Apr 2016 22:15:17 +0
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 entro
Andi Kleen wrote:
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
I came up with some very pretty code to fix this, which
tried to copy_to_user with a lock held.
After all my attempts to fix that fatal fla
> 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 *doe
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 is
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 t
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
> Could you rename and instrument your /sbin/modprobe to do something like:
>
> #!/bin/sh
> echo "$@" >> /root/modprobe.log
> exec /sbin/modprobe.bin "$@"
Thanks for the script, bit it turned out not to work... modern modprobe
is a link to kmod, and if the basename of argv[0] is not exactly
"modpr
> 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 bisect
> 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 th
> 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 e
> Ah, now I see it. Yes, all AES 128 are covered.
>
> What about AES 192 and 256?
The implementation doesn't support them, and I didn't add them.
It would require either:
* Trickery based on the supplied seed length, which would conflict
with the existing optional-DT support, or
* A separate c
> - 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 wi
> 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 =
> 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 y
In an earlier conversation with Neil, I had an idea that I'd like
your opinion on.
I still think whether true-random mode is wanted is up in the air,
but if it is, a better way to proide it would be to create a separate
crypto_alg for it, with a smaller seed size (no DT seed) and its own name.
Bu
>> 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
> 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
> 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 postin
> Wait, I'm confused. You mention in this note that this is an RFC patch, but
> not
> anywhere else in the series. Are you proposing this for inclusion or not?
Er, in the 0/25, I mentioned that I put the least certain stuff last,
and in particular I wasn't sure if the the last three patches were
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
The idea is to catch as many programmer mistakes as possible.
Signed-off-by: George Spelvin
---
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/testmgr.c
@@ -1459,6
There's no way to set it, so it's dead code.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 74ec151e..f6a1e987 100644
--- a/crypto/ansi_cprng.c
++
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
---
c
This makes no difference to the generated code, but I like to use bool
where appropriate for documentation.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index
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
---
crypto/ansi_cprng.c | 47 ++-
1 file changed, 14 insertions(+), 33 deletions
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
---
crypto/ansi_cprng.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
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
-
every possible alignment in
the CPRNG's internal buffer.
Signed-off-by: George Spelvin
---
crypto/testmgr.c | 98 ++--
1 file changed, 89 insertions(+), 9 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6bf43682..a15860ad 10
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
---
crypto/ansi_cprng.c | 10 +-
1 file changed, 5 i
It doesn't need a second input or a length parameter.
Signed-off-by: George Spelvin
---
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/ansi_cprng.c
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
---
crypto/ansi_cprng.c | 12 +++-
1 file changed, 7 insertions(+), 5
Huge diff, but simple.
Signed-off-by: George Spelvin
---
crypto/tcrypt.c | 46 +++
crypto/tcrypt.h | 30 ++--
crypto/testmgr.c | 58
crypto/testmgr.h | 410 +++
4 files changed, 276 insertions(+), 268 deletions(-)
diff --git
Yes, they're equivalent to "unsigned char", but let's stick with what
the crypto API uses externally.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/crypto/ansi_cprng.c b
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
---
The public crypto API uses "unsigned int", but the internals used
a mixture of that and size_t, which are different sizes on 64 bits.
This shuts up a GCC warning about printf format.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 8
1 file changed, 4 insert
Signed-off-by: George Spelvin
---
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/ansi_cprng.c b
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
---
crypto/ansi_cprng.c | 50
ave a "CPRNG"
that's not deterministic.
Signed-off-by: George Spelvin
---
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
Signed-off-by: George Spelvin
---
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/ansi_cp
Calling the lower-level function does what's needed with less overhead.
Signed-off-by: George Spelvin
---
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
--- a/crypto/ansi_cp
This ensures alignment and makes xor_block more efficient,
but it's mostly in preparation for later changes.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 73 ++---
1 file changed, 41 insertions(+), 32 deletions(-)
diff --git a/c
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
---
crypto/testmgr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
The local variable "output" is no longer required.
Signed-off-by: George Spelvin
---
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/ansi_cpr
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
---
crypto/ansi_cprng.c | 25
It's more legible, and the code is 16 bytes smaller (i386).
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 91 +
1 file changed, 35 insertions(+), 56 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index b63
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 when he finds them.
* Is non-deterministic mode (last three patches) wanted?
George Spelvin (25):
crypto: ansi_cprng - unr
> 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.
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 impleme
>> --- 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[] */
>> +
> 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 D
> 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 gettin
> 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, finalize
> 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 n
1 - 100 of 142 matches
Mail list logo
