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
| ||
|
Message-ID: <20150914204301.GA505@bolet.org> Date: Mon, 14 Sep 2015 22:43:01 +0200 From: Thomas Pornin <pornin@...et.org> To: discussions@...sword-hashing.net Subject: Re: [PHC] Specification of a modular crypt format On Mon, Sep 14, 2015 at 05:05:11PM +0100, Hugo Landau wrote: > The need for key-value extensibility for password hashing functions > is, presumably, nil Actually I am not doing it for extensibility, but for readability. If you have three parameters (say, the p, m and t or Argon2) then you can have something like: $argon2i$42$5$5000$... but then you have to remember, as a human reader, in which order the p, m and t appear in the string. In my proposal you get: $argon2i$m=42,p=5,t=5000$... which is clearer (for humans). Since the order is fixed, this should not be more complex to parse (instead of checking "does it start with '$'", code checks for "does it start with ',p='", which is still a single strncmp() call for a C-based parser). Accepting named parameters in arbitrary order, and/or ignoring unrecognized parameters, would indeed make parsing more complex, but I personally don't want that. I want the whole encoding to be fully deterministic so that test vectors work well. This also implies that the parsing can remain relatively easy. I'll try to write the parsing code in a few days, so that we may have a baseline for the complexity of implementations. > 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). > I'm not convinced by this rationale. Firstly, I'm not aware of any > base64 functionality provided by programming language standard libraries > which does line wrapping, etc. .NET's System.Convert.ToBase64String() includes newlines by default (which might be OS-dependent, even). However, there are four versions of that call, two of which accepting an extra parameter of value Base64FormattingOptions.None to avoid inserting line breaks every 76 characters (yes, 76, not 64). "openssl base64" (command-line tool, for shell scripts) also includes line breaks (and requires them upon decoding...). None of this is an irremediable point. "True" Base64 is not harder to implement than the "crypt" variant. I'll give it a go (I already did in both C and Java, neither of which having innate abilities at Base64). (I note that the B64 implementations already in place for bcrypt and the SHA-2-based crypts works only in the encoding direction, which is the easier of the two. For salt _decoding_, we need a decoder, which is relatively harder to implement.) > Developers in this circumstance (or, preferably, people developing > password hashing libraries) Yes, much preferably, please. --Thomas Pornin
Powered by blists - more mailing lists