MAJOR=4 MINOR=32 DEVNAME=tty32 "l4( ) *j.)F i7to-do list for libxcrypt ------------------------ This list is categorized but not in any kind of priority order. It was last updated 20 October 2018. * Code cleanliness * Find and remove any code that still does dodgy things with type punning * Factor out all of the repetitive base64 code * Factor out the multiple implementations of HMAC and PBKDF * Testsuite improvements * Investigate branch coverage * Do some API fuzz testing and add missing cases to the testsuite * Many of the `test-crypt-*.c` files repeat more or less the same code with different data, consider merging them * Portability * Make sure the symbol versioning macros work with all of the compilers that anyone needs (they use GCC extensions that clang also supports). * Hardening * bcrypt-like selftest/memory scribble for all hashing methods * how do we know the memory scribble is doing its job? * build out of the box with compiler hardening features turned on * something bespoke for not having to write serialization and deserialization logic for hash strings by hand, as this is probably the most error-prone part of writing a hashing method * the most sensitive piece of data handled by this library is a cleartext passphrase. OS may have trusted-path facilities for prompting the user for a passphrase and feeding it to a KDF without its ever being accessible in normal memory. investigate whether we can use these. * Additional hashing methods * Argon2 * ...? * Runtime configurability (in progress on the [crypt.conf branch][]) * allow installations to enable or disable specific hash methods without rebuilding the library * make the default cost parameter used by `crypt_gensalt_*` for new hashes configurable * update the compiled-in defaults used by `crypt_gensalt_*` (not the defaults used when no explicit cost parameter is present in a hash; those can’t be changed without breaking existing stored hashes) * relevant benchmarking at * offer a way to tune cost parameters for a specific installation * N.B. Solaris 11 has all of these features but our implementation will probably not match them (they have a `crypt.conf` but it’s not the same, and their `crypt_gensalt` is API-incompatible anyway). [crypt.conf branch]: https://github.com/besser82/libxcrypt/tree/zack/crypt.conf * Potential API enhancements: * Support for "pepper" (an additional piece of information, _not_ stored in the password file, that you need to check a password) * Reading passphrases from the terminal is finicky and there are several competing, poorly portable, questionably sound library functions to do it (`getpass`, `readpassphrase`, etc) -- should we incorporate one? * If we do, should it know how to trigger the trusted-path password prompt in modern GUI environments? (probably) * Make the crypt and crypt_gensalt static state thread-specific? * Solaris 11 may have done this (its `crypt(3)` manpage describes it as MT-Safe and I don’t see any other way they could have accomplished that). * if allocated on first use, this would also shave 32kB of data segment off the shared library * alternatively, add a global lock and *crash the program* if we detect concurrent calls * Allow access to more of yescrypt’s tunable parameters and ROM feature, in a way that’s generic enough that we could also use it for e.g. Argon2’s tunable parameters * Other yescrypt-inspired features relevant to using this library to back a “dedicated authentication service,” e.g. preallocation of large blocks of scratch memory * the main obstacles here are that `struct crypt_data` has a fixed size which is either too big or too small depending how you look at it, and no destructor function * Permissive relicensing