Skip to content

Latest commit

 

History

History
100 lines (84 loc) · 4.55 KB

TODO.md

File metadata and controls

100 lines (84 loc) · 4.55 KB
Raw

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

  • 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)
    • 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).

  • 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.