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: <20150922160934.GA15228@openwall.com> Date: Tue, 22 Sep 2015 19:09:34 +0300 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] Specification of a modular crypt format Hi Thomas and all, On Sun, Sep 13, 2015 at 08:26:50PM +0200, Thomas Pornin wrote: > here is my take at specifying a string format for the output of a > password hashing function; this aims at supporting password verification > in a way compatible, in particular, with the Unix crypt() API and the > /etc/shadow files. This is not for use of a function as a KDF. I tried > to remain as generic as possible, although of course the primary target > is Argon2. First of all, thank you for working on this! Then, I'm sorry for being a bit late with my feedback. Yet maybe better late than never, so here goes: I dislike use of <param>=<value>, as opposed to just listing the values. I also find it inconsistent that the proposed syntax mixes bloated constructions such as long identifier names, use of <param>=<value>, and use of decimal with the more compact choice of crypt(3) base64 encoding rather than RFC Base64. I think we should consistently opt for a compact or a bloated encoding, and I'd prefer compact, but if you do bloated, then do it to the fullest extent (and we'll have a compact alternative then). I do see value in listing of the parameters in a fixed order (and in having no defaults and in listing all parameters all the time as well, despite of the drawbacks). However, when that fixed order comes from lexicographic order of parameter names it may end up being otherwise weird, and inconsistent with what we already have for scrypt. Given that yescrypt builds upon scrypt and supports scrypt compatible mode, I'd like to have its parameters common with scrypt listed first and in the same order as is commonly used with scrypt. This is N, r, p, but lexicographic order would result in N, p, r. I find having to introduce this inconsistency, if we adopt your proposal as currently specified, unfortunate. It could also be nice to be able to omit yescrypt's additional parameters that are not in scrypt - in other words, use this opportunity to introduce a syntax for scrypt that would address some limitations of what we previously defined for scrypt, without having to list yescrypt's parameters. Well, I guess we can do that within your specification by allocating a separate identifier string for scrypt. The use of crypt(3) base64 could help encode the parameters in a more compact way, e.g. use just one char (and no separator before/after it) for (ye)scrypt's log2(N). I find it suboptimal to go for crypt(3) base64 yet not take full advantage of it. Overall, I think this verbose syntax might hamper adoption by some projects. I also think that if we go for a verbose and human and scripting friendly syntax for the parameters anyway, we should as well bite the bullet of RFC Base64 with its extra padding characters. Having 3 extra characters is negligible compared to the bloat we already have in the proposed long identifiers and the encoding of parameters. I actually prefer crypt(3) base64, but I dislike the bloat already proposed enough that going for RFC Base64 just doesn't make it all that much worse for me, while making it better for others. I'll probably come up with an alternative compact encoding anyway, and this one may be bloated to the fullest extent then. OTOH, it's nice to have a common encoding type (and common code) between the compact and bloated forms, so maybe your choice is right from that point of view. Also, if we go for a bloated syntax anyway, we probably should use the opportunity to allow for encoding of arbitrarily small or large salts, and arbitrary hash sizes. So that e.g. if crypt() is available via pgcrypto or something, thus via SQL queries in this example, its support for a PHC scheme could then be reused to compute that scheme with arbitrary inputs with no artificial restrictions. e.g. to derive multiple keys at once (where 256 bits could be too little). I don't feel about this strongly, but overall I feel that we should either avoid bloat or use the potential advantages of the bloat to the fullest, whereas the proposed encoding does neither. Sorry for the criticism. Again, I appreciate the effort. Thanks, Alexander
Powered by blists - more mailing lists