[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 17 Jun 2012 10:43:12 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: [patch] optional new raw sha1 implemetation
On 2012-06-17 01:58, Tavis Ormandy wrote:
> On Sun, Jun 17, 2012 at 01:46:00AM +0200, Tavis Ormandy wrote:
>> On Sun, Jun 17, 2012 at 01:42:07AM +0200, magnum wrote:
>>>>> On a third thought, are we not actually guaranteed there will be a
>>>>> zero byte? They are zeroed in set_key().
>>>>>
>>>>> magnum
>>>>
>>>> I dont think so, for example, consider testing two 15 byte keys, I would
>>>> store them in contiguous aligned buffers like this:
>>>>
>>>> 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 80
>>>> 41 41 41 41 41 41 41 41 41 41 41 41 41 41 42 80
>>>> 00 00 00 ...
>>>>
>>>> get_key(0) with strrchr would return AAAAAAAAA\x80AAAAAAAAAAAB, no?
>>>
>>> OK, so let's just put a zero in ((unsigned char*)key)[15] before the
>>> strrchr. That ought to work fine, right?
>>>
>>> magnum
>>
>> Hmm, you mean make key[] in sha1_fmt_get_key 5 instead of 4? Hmm, I think
>> that sounds okay.
>>
>> Tavis.
>>
>
> Oh, i think if I put string.h first and #define _GNU_SOURCE, the
> prototype becomes visible. I think I'll just do that unless you object.
>
> Annoying that such preprocessor voodoo is required to get such a basic
> protoype..wtf.
No, that was what I did first but memrchr is not portable. Not everyone
runs GNU or Linux. I think allocating a 17 byte key and ensure the last
is null is the simplest fix. In fact we only need to to this once as we
never overwrite it:
static uint32_t *result;
if (!result)
result = mem_calloc_tiny(SHA1_DIGEST_SIZE + 1, MEM_ALIGN_WORD);
I'll commit the above for now but you are obviously free to change it to
something else.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
