On 1/16/12, Eric Dumazet <eric.duma...@gmail.com> wrote:
> Le lundi 16 janvier 2012 à 09:56 +0000, David Laight a écrit :
>> Doesn't this badly overflow W[] ..
>>
>> > +#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
>> > + t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i]; \
>> ...
>> > + for (i = 0; i < 16; i += 8) {
>> ...
>> > + SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
>> > + }
>>
>> David
>>
>>
>
> No overflow since loop is done for only i=0 and i=8
>
> By the way, I suspect previous code was chosen years ago because this
> version uses less stack but adds much more code bloat.
I think W[80] was use because it's the most straightforward way to
write this code
by following spec.
All SHA definitions have full message schedule pseudocoded
before hash computation.
> size crypto/sha512_generic.o crypto/sha512_generic_old.o
> text data bss dec hex filename
> 17369 704 0 18073 4699 crypto/sha512_generic.o
> 8249 704 0 8953 22f9 crypto/sha512_generic_old.o
This is because SHA-512 is fundamentally 64-bit algorithm multiplied by
excessive unrolling.
Surprisingly, doing variable renaming by hand like in spec:
t1 = ...
t2 = ...
h = g;
g = f;
f = e;
e = d + T1;
d = c;
c = b;
b = a;
a = t1 + t2;
bring stack space on i386 under control too.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
