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.
Generated by dwww version 1.15 on Thu Jun 27 23:10:36 CEST 2024.