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) 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.