| to-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 <https://password-hashing.net/> |
| * ...? |
| |
| * 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 |
| <https://pthree.org/2016/06/28/lets-talk-password-hashing/> |
| * 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, to encourage use beyond the GNU ecosystem? |
| * Replace crypt-md5.c with original md5crypt from FreeBSD? |
| * Other files subject to the (L)GPL are crypt.c, crypt-static.c, |
| crypt-gensalt-static.c, crypt-obsolete.h, crypt-port.h, |
| test-badsalt.c. It is not clear to me how much material originally |
| assigned to the FSF remains in these files. |
| Several of them are API definitions and trivial wrappers that |
| could not be meaningfully changed without breaking them (so are |
| arguably uncopyrightable). |
| * Most of the test suite lacks any license or even authorship |
| information. We would have to track down the original authors. |
