From: Milan Broz <mbroz@redhat.com>
To: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] crypsetup segfaulting during luksFormat
Date: Fri, 09 Jul 2010 09:22:42 +0200 [thread overview]
Message-ID: <4C36CE42.7070201@redhat.com> (raw)
In-Reply-To: <1278614664.3147.81.camel@Koma-Station.localdomain>
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
next prev parent reply other threads:[~2010-07-09 7:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 17:19 [dm-crypt] crypsetup segfaulting during luksFormat Sven Eschenberg
2010-07-07 17:36 ` Arno Wagner
2010-07-07 17:49 ` Sven Eschenberg
2010-07-07 20:19 ` Arno Wagner
2010-07-07 20:44 ` Milan Broz
2010-07-07 20:58 ` Sven Eschenberg
2010-07-07 21:22 ` Milan Broz
2010-07-08 2:22 ` Sven Eschenberg
2010-07-08 9:30 ` Arno Wagner
2010-07-08 13:37 ` Sven Eschenberg
2010-07-08 14:16 ` Milan Broz
2010-07-08 14:29 ` Sven Eschenberg
2010-07-08 15:11 ` Milan Broz
2010-07-08 18:44 ` Sven Eschenberg
2010-07-09 7:22 ` Milan Broz [this message]
2010-07-09 12:18 ` Sven Eschenberg
2010-07-09 12:46 ` Milan Broz
2010-07-14 18:14 ` Christoph Anton Mitterer
2010-07-14 18:24 ` Milan Broz
2010-07-14 18:56 ` Sven Eschenberg
2010-07-07 21:40 ` Milan Broz
2010-07-07 22:00 ` Arno Wagner
2010-07-08 2:13 ` Sven Eschenberg
2010-07-07 20:51 ` Arno Wagner
2010-07-07 18:36 ` Milan Broz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C36CE42.7070201@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
--cc=sven@whgl.uni-frankfurt.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox