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 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: Tue, 29 Sep 2015 09:10:39 +0000
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format (2)

On Mon, Sep 28, 2015 at 5:07 PM Thomas Pornin <pornin@...et.org> wrote:

>
> (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 ?)
>
>
Converted the document to pandoc-Markdown (
https://docs.google.com/document/d/1QJva4xsY3eHNm2YiT0yPS9spRqd-N8NamYRpF5lkIzM/edit?usp=sharing
).

I attach the resulting HTML.



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

Content of type "text/html" skipped

View attachment "string-format.html" of type "text/html" (15472 bytes)