[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4bdbf00f1f242311cf1f4d79928bec33@smtp.hushmail.com>
Date: Tue, 18 Aug 2015 10:52:35 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Formats using non-SIMD SHA2 implementations
On 2015-08-18 10:39, magnum wrote:
> BTW both 7z and rar3 has a property that makes the entire message length
> for all rounds guaranteed even divisible by 64. Current RAR3 kernel
> takes that opportunity to shuffle data much faster (trading global
> memory but it's still a lot faster) like this:
>
> 1. Prepare a buffer not of 2*64 but of smallest size that ends exactly
> at (len % 64 == 0).
Correction: I believe this size is 32*64 for 7z regardless of password
length. So that is the size of your working buffer. For RAR3 it's 64*64
(it uses an 8-byte salt plus a 3-byte 'serial').
> 2. When copying a limb, do it 16 x 32-bits at a time (btw this will
> benefit SIMD scattering even more than OpenCL!) from that aligned buffer.
> 3. After each step 2, just update the "rounds" bytes within the buffer
> prepared in step 1.
>
> The above was the final idea that made our RAR3-opencl as fast as cRARk,
> which was my benchmark goal at the time.
On another note, it seems 7z is actually unsalted within the KDF. So one
could make extremely effective Rainbow tables for it.
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.
