On Tue, Mar 27, 2012 at 12:23, Markus Schaber <m.schaber_at_3s-software.com> wrote:
> Von: Greg Stein [mailto:gstein_at_gmail.com]
>>On Mar 27, 2012 12:55 AM, "Daniel Shahaf" <d.s_at_daniel.shahaf.name> wrote:
>> >...
>> > > On 27.03.2012 05:23, Greg Stein wrote:
>> > > >...
>> > > > While discussing this on IRC some, I did think of one case where you
>> > > > want to know they got the correct master passphrase: when they are
>> > > > updating a server's password. A mis-entry could completely garble the
>> > > > stored/encrypted contents.
>> >
>> > Don't ew have some other ways of addresing that use-case? Such as, say,
>> > encrypting a random string, and at decrypting compare the decrypted
>> > text's sha1 to the value computed at encryption time?
>
>> There ya go. I knew we could tease out a solution. That sounds good to me.
>> So, for each password, we store two more 16-byte blocks of encrypted data, and a SHA1 has (20 bytes). At decrypt time, we also decrypt those blocks, hash the 32 byte result, and compare against the hash.
>> I would also suggest that we append those two blocks to the padded password, so they get the advantage of CBC, without needing to pick a second IV.
>
> I know I'm supposed to shut up,
You don't have to shut up... I'd just prefer that you don't patronize me.
> but AFAICS, this design does not prevent the offline dictionary attacks mentioned by Greg Hudson.
Through the use of PBKDF2 to generate the per-password crypt keys, the
offline attacks will become computationally expensive.
> It is solving the "known plaintext" problem of the simpler implementation, though.
Right.
-g
Received on 2012-03-27 18:28:04 CEST