[<prev] [next>] [day] [month] [year] [list]
Message-ID: <6a376be4f56fb997e1d93a7880d3616e@smtp.hushmail.com>
Date: Sun, 17 Jun 2012 01:43:00 +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:42, magnum wrote:
> 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?
Lol, no, not if that was the 0x80. OK, I'll leave this to you :)
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.
