Message-ID: <532FBC5D.2000906@bindshell.nl>
Date: Sun, 23 Mar 2014 22:02:21 -0700
From: Jeremi Gosney <epixoip@...dshell.nl>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] pufferfish

Hey Steve,

On 3/23/2014 3:57 PM, Steve Thomas wrote:
> > On March 23, 2014 at 9:59 AM Jeremi Gosney <epixoip@...dshell.nl>
> wrote:
> >
> > I've pushed code to a public repository for the candidate I will be
> > submitting, pufferfish. This repository will be frantically updated
> over
> > the coming week as I prepare my submission, but I wanted to get some
> > initial feedback before the cutoff.
> >
> > https://github.com/epixoip/pufferfish
>  
> I fixed a few bugs for you. I keep forgetting the correct way to do a
> pull
> request  from the web interface on GitHub. So you might have gotten a
> few  emails  about  that :)

Thanks for the pull requests!


> > The dynamic s-boxes are of course the biggest differentiating factor
> > between pufferfish and blowfish. The s-box generation is as follows:
> >
> > 1. Hash the raw salt as sha512
> > 2. hmac-sha512 the password using the hashed salt as the key
> > 3. hmac-sha512 the password again, using the output of the hmac
> > operation in step 2 as the key
> > 4. These two hmac hashes are concatenated to initialize the 1024-bit
> state
> > 5. The four s-boxes are each filled with m_cost / 4 / sizeof (uint64_t)
> > words by iterating over the internal state with a variant of chacha8
>  
> You might want to pick SHA512 or ChaCha8 to lower the complexity.

This is something I will consider.


> > I elected to use this design because I really like bcrypt, and I really
> > like the idea of being memory hard while using as little memory as
> > possible. And I believe that the modifications I have made increase the
> > effectiveness and extend the longevity of the original bcrypt design.
>
> I was hoping someone would make bcrypt more memory hard. I was
> wondering  how did you come up with the rotation amounts: 22, 33, 53,
> and  61?

Experimentation, trial and error. I spent a lot of time on it, examining
the access patterns and frequencies. I picked the top four numbers that
had the highest dispersion in my testing. Granted, I'm not a
mathemetician, so this was an area I was hoping that you especially
would be able to provide guidance in.


> P.S. I actually wrote one just in case no one else did. And I really like
> yours .

Thank you for this comment :)


> I  was thinking of doing 64 bit by doing 4 calls of "F" instead of 2
> per  round, but  I left it as 32 bit. R otating might be  just as good
> . The
> main  difference I did was a  variable amount of fixed  sized sboxes vs
> fixed amount of  variable sized  sboxes. Each call to "F"  I use the
> next 4
> sboxes and I messed  with the round counts. The first pass I do 1 round,
> second pass 2 rounds, third 3... Minimum is 5 passes so this would be
> kind of like 15 round blowfish. t_cost increases the number of passes.
> So  basically I  turned  blowfish into a more than  likely non-
> cryptographic
> function.

The first version I wrote early last year used a variable amount of
fixed-sized s-boxes as well, but I gave it more thought and decided that
a fixed number of arbitrarily-sized s-boxes was a better approach. I
also considered doubling the number of calls to the F-function as well,
but I was afraid this would make the algorithm too "heavy" since the
number of calls to encipher are already increased with larger s-boxes. I
would be interested in collaborating on this with you before the dealine
though if you'd like to share your code with me.

Jeremi

Powered by blists - more mailing lists