[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c22dbb5bc43eecdf96e1bff3c5af89c0@smtp.hushmail.com>
Date: Sun, 17 Jun 2012 01:42:07 +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:37, Tavis Ormandy wrote:
> On Sun, Jun 17, 2012 at 01:33:51AM +0200, magnum wrote:
>> On 2012-06-17 01:30, magnum wrote:
>>> On 2012-06-17 01:28, magnum wrote:
>>>> On 2012-06-17 01:25, Tavis Ormandy wrote:
>>>>> Regarding switching memrchr to strrchr, I dont think this is correct,
>>>>> they are strings on input, but I store them in a format that can be
>>>>> converted to SHA-1 input very quickly and there is no guarantee there
>>>>> is a nul byte at the end.
>>>>
>>>> Yes but we search for 0x80 and this *will* be present. I see no problem,
>>>> and it works just fine.
>>>
>>> Oh, I see what you mean now. You are probably right we should change this.
>>
>> 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
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.
