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

Powered by blists - more mailing lists