[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a396e492a53ee0c7ae102793c04f9fcb@smtp.hushmail.com>
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.
