phc-discussions - Re: [PHC] pufferfish

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <308938418.441849.1395615479869.open-xchange@email.1and1.com>
Date: Sun, 23 Mar 2014 17:57:59 -0500 (CDT)
From: Steve Thomas <steve@...tu.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] pufferfish

> 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 :).

> 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.

> 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?

P.S. I actually wrote one just in case no one else did. And I really like
yours . 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.
Content of type "text/html" skipped