[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <532F45A4.6020308@riseup.net>
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