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

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 02:06:04 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format

On 2015-09-14 23:43, Thomas Pornin wrote:
>> I also think parameter values can be limited to non-negative integers at
>> this time, unless you are aware of any password hashing schemes which
>> would be incompatible with this.
>
> In Makwa, at least, it is preferable to have a binary identifier for the
> used modulus (in the current spec, it is a hash of the modulus,
> truncated to 8 bytes). This parameter does not map to a non-negative
> integer (well, you _could_ make it an integer, since every sequence of
> bits can be interpreted as an integer, but you see what I mean).
>
> Another case would be PBKDF2, which is configurable with an iteration
> count, an output length, and an underlying PRF (usually HMAC with a
> given hash function). The hash function name could be made part of the
> function identifier (i.e. you have 'pbkdf2-sha1', not 'pbkdf2' with a
> 'sha1' parameter), but, conceptually, you could make the hash function
> one of the parameters (as a symbolic string).

Then perhaps negative integers could be excluded?

-- 
Alexander Cherepanov