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

Powered by blists - more mailing lists