Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 31 Dec 2012 06:32:41 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Formats dmg, encfs and strip crash on longer passwords

On 31 Dec, 2012, at 6:09 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:

> On Mon, Dec 31, 2012 at 9:52 AM, magnum <john.magnum@...hmail.com> wrote:
>> On 31 Dec, 2012, at 5:03 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
>>> 4. ZIP files using AES 256-bit encryption require very long PBKDF2 output (upto 66 bytes). Can the new PBKDF2 code do this? Strangely the zip OpenCL handles this just fine!
>> 
>> As-is, it produces 40 bytes but only 32 are used. It can output up to 40 bytes with a super trivial modification. How do they do more, another bunch of iterations?
> 
> I just looked at zip_kernel.cl file and after reading it I have *no*
> clue how it outputs 66 bytes. However, I think it does output 66
> bytes. Can you take a look?

It's the 3x for loop plus 1x after it. Each big_hmac_sha1() does 1000 iterations and produces 20 bytes. So that kernel actually produce 80 bytes of output in 4000 iterations but only 66 are used.

I could change my kernel to be as flexible as Gladman's derive_key() but I'd have to be careful to keep it optimized.

magnum

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.