Re: scrypt Internet Draft

[Solar Designer <solar@openwall.com>]

On Mon, Nov 05, 2012 at 04:30:41AM +0400, Solar Designer wrote:
> On Thu, Nov 01, 2012 at 09:32:23PM +0400, Solar Designer wrote:
> > $7$Nrrrrrpppppsalt$hash
> > 
> > "N" is one base 64 character for log2(N)
> > "rrrrr" is little-endian encoding of r (30 bits)
> > "ppppp" is little-endian encoding of p (30 bits)
> 
> BTW, the current implementation of scrypt limits r*p to 30 bits, which
> matches the above well.  We may use a more compact encoding since at
> most one of r or p will fully use the 30 bits at once, but this might
> not be worth the added complexity.  Alternatively, for r we may choose
> to support powers of two only, which I expect will be sufficient in
> practice.  r is there primarily to support longer cache lines, and it
> feels unlikely that a future CPU will have cache line length that is not
> a power of two.

It occurred to me that "odd" values of r let us fully use memory sizes
that are not powers of 2, which may be handy.  If on some machine we can
afford e.g. 48 MB, we can actually use this much with r=3 or r=6 (if we
also need to support r=2's cache line length), etc.  So let's keep this
support in the interface.

"Odd" values of p may be handy, too - e.g., to parallelize individual
scrypt invocations on a 6-core CPU.

Alexander