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]

Date: Sun, 23 Mar 2014 21:35:48 +0100
From: beloumi <beloumi@...eup.net>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] pufferfish

Am 23.03.2014 15:59, schrieb Jeremi Gosney:
> 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 am glad that someone has chosen Bcrypt as a basic for a submission.
This submission mightbenefit of the proven reliability of a long
existingalgorithm.

What bothers me a bit at first sight is the Base64 encoding. Instead of
Bcrypts particular Base64 encoding I would prefere the standard Base64
encoding of MIME. This would be an easement for implementations in
crypto libraries.

Just two unreflective ideas for Pufferfish:
1. Wouldn't it be easier to support variable output length by variable
(length of) ctext in Pufferfishs encryption step instead of an extra
hash? I can not see any security improvement for the hash.

2. Instead of replacing the s-box entries, wouldn't it be easy to expand
them to a memory-hard vector and use them piece by piece in the last
encryption step (that means: using a different s-box for each of the 64
encryptions or - more experimental - for each blowfish round)?
Please excuse that I write a comment although I have not fully reflect
the algorithm...