Hi Milan,
seems you are right. I really feared the implicit cast is insecure (I
guess it would have been for an untyped tmp pointer).
Shame on me :-(.
Okay, back to the beginning, which options do we (I) have to investigate
this further?
Regards
-Sven
Milan Broz schrieb:
On 07/08/2010 08:44 PM, Sven Eschenberg wrote:
On Thu, 2010-07-08 at 17:11 +0200, Milan Broz wrote:
On 07/08/2010 04:29 PM, Sven Eschenberg wrote:
Hi Milan,
Even worse, actually byte swappig is done to store the int in a big
endian manner, unfortunately, since it is done wrong, on big endian
systems all block indeces would be zero and they are part of the Derived
Key. I wonder if this has a security impact as in quality of derived key
on big endian systems.
You mean when int is big endian and 64bit? Do you see system where it is wrong
or just guessing?
Should happen on 32 Bit already, okay, let's see, AA BB CC DD, most
significant byte is AA (mask BB CC DD, shift right logically, so we will
get AA as value), which in little endian looks like AA 00 00 00, which
is copied into position Slen+0, the 4 bytes will be filled with AA 00 00
00, next step would be copying BB 00 00 00 into the next position Slen
+1, notice that here the last zero byte exceeds the buffer on the stack
already ...
Swen,
please look at RFC2898, PBKDF2 definition, search for
"Here, INT (i) is a four-octet encoding of the integer i, most significant octet first."
Is it better now? And compiler interprets mask correctly according to endian type.
There should be no stack overflow, it works with char array, not int array.
FYI the same code is in gnutls, see lib/x509/pbkdf2-sha1.c
Do it still segfaults after your suggested change? Did you tried it?
Milan
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
