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: Thu, 08 Oct 2015 09:22:17 +0000
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] Specification of a modular crypt format

Do you think the specs/code at
1) cannot be finalized as they are and require major changes
2) could use some optimization but are acceptable as they are
3) are perfectly fine

On Thu, Oct 8, 2015 at 12:38 AM Solar Designer <> wrote:

> On Sat, Sep 19, 2015 at 07:02:51PM +0200, Thomas Pornin wrote:
> > The code includes some generic Base64 encoder/decoder (about 150 lines),
> > then code specific to Argon2i (about 200 lines), and some test vectors.
> > The Base64 code is constant-time with regards to the data contents (no
> > data-dependent table lookups or branches); this is probably useless in
> > most situations, but easy enough to achieve.
> It is in fact (at least theoretically) desirable to have salt decoding
> cache-timing-safe when (or just in case) the hashing scheme itself is
> not cache-timing-safe or/and the hash comparison is not timing-safe.
> This also means that en/decoding the salt, instead of using it verbatim,
> results in extra risk.  Yet we seem to have chosen to do that to provide
> a more generic interface to the underlying hashing scheme.  (I did post
> this sort of rationale in here.  I should have mentioned the above
> drawback in that same message.)
> While we probably can implement things safely ourselves, third-party
> implementations are a (bigger) concern.
> Alexander

Content of type "text/html" skipped

Powered by blists - more mailing lists