phc-discussions - Re: [PHC] Specification of a modular crypt format (2)

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: Mon, 28 Sep 2015 17:06:37 +0200
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format (2)

On Mon, Sep 28, 2015 at 01:23:59PM +0000, Jean-Philippe Aumasson wrote:
> Fixing typos:

I have fixed another one, and changed the font to Courier New.

(Right now, I write things in pure ASCII, which is convenient for me,
but ugly. Do we want to change that ? And to what ? A nice PDF file ?
A document in RFC format ?)

> "with a strcmp() call": should we expect all strings to be null-terminated?

In the context of the C crypt() call, the strings are null-terminated;
such is the existing API. In other contexts, strings are not necessarily
null-terminated or even "terminated" (e.g. in C# or Java, this notion
makes no sense), but there would not be a strcmp() function either.

More generally, the traditional crypt() API merges both functionalities
(password registration, and password verification) into a single
function call. Personally, I would find a two-function API clearer. But
that crypt() API (or its reentrant counterpart crypt_r()) is firmly
entrenched and won't disappear any time soon, so I think it is important
to support it. Hence the dedicated section in the spec.

> add "The identifier for Argon2ds is 'argon2ds'"?

I have added it to the spec.

	--Thomas