Am Montag, 15. Dezember 2014, 17:01:02 schrieb George Spelvin:
Hi George,
>> 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
> 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
Mathias,
I'm seeing some anomalous results with the "by8" AVX CTR optimization in
3.18.
the patch you're replying to actually *disabled* the "by8" variant for
v3.17 as it had another bug related to wrong counter handling in GCM.
The fix for that particular issue only made it to v3.18, so the c
On Mon, Dec 15, 2014 at 11:46:15AM +0100, Stephan Mueller wrote:
> Am Montag, 15. Dezember 2014, 05:21:49 schrieb George Spelvin:
>
> Hi George,
>
> > > 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
Am Montag, 15. Dezember 2014, 05:45:31 schrieb George Spelvin:
Hi George,
>>> You will agree, I hope, that the result from get_random_int *does*
>>> include the entropy of a high-resolution timestamp? Which is
>>> cryptographically equivalent to including the unobfuscated
>>> timestamp?
>>
>> g
Am Montag, 15. Dezember 2014, 05:21:49 schrieb George Spelvin:
Hi George,
> > 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.
Sorry, my bad. :-)
Then, I think the updated implementation ma
> 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
Am Montag, 15. Dezember 2014, 03:28:16 schrieb George Spelvin:
Hi George,
>> 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 = 10379b53317a2500879e88ad445ea38
Am Montag, 15. Dezember 2014, 03:42:44 schrieb George Spelvin:
Hi George,
>> - 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. Pl
> - 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 =
12 matches
Mail list logo
