On Mon, Dec 15, 2014 at 05:01:02PM -0500, George Spelvin wrote:
> > 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
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
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 =
Am Montag, 15. Dezember 2014, 00:53:19 schrieb George Spelvin:
Hi George,
> > I have send these vectors about a week ago. Do you have results?
>
> BTW, here is my current home-grown debugging output.
That output is good for the VST test vectors. For the MCT vectors, I need the
1th value.
>
Am Sonntag, 14. Dezember 2014, 14:47:30 schrieb George Spelvin:
Hi George,
> >> 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
Am Sonntag, 14. Dezember 2014, 15:37:38 schrieb George Spelvin:
Hi George,
> 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
> 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
Am Sonntag, 7. Dezember 2014, 07:26:08 schrieb George Spelvin:
Hi George,
> This is a reworked version of my earlier patch series, based on feedback
> from Neil Horman and Stephan Mueller. Thank you both very much!
>
> It's mostly the same content as before, but I've tried to improve comments
>
This is a reworked version of my earlier patch series, based on feedback
from Neil Horman and Stephan Mueller. Thank you both very much!
It's mostly the same content as before, but I've tried to improve comments
and commit messages to address questions, to reorder the patches to put
the questiona
20 matches
Mail list logo
