On Tue, Mar 27, 2012 at 12:23, Markus Schaber <m.scha...@3s-software.com> wrote: > Von: Greg Stein [mailto:gst...@gmail.com] >>On Mar 27, 2012 12:55 AM, "Daniel Shahaf" <d...@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
