FM / libxcrypt

/usr/share/doc/libxcrypt

Name	Size	Mode	Actions
ChangeLog	6049	0644	edit dl rm
NEWS	6766	0644	edit dl rm
README	7573	0644	edit dl rm
THANKS	180	0644	edit dl rm
TODO	2583	0644	edit dl rm

Edit: /usr/share/doc/libxcrypt/TODO (2583B)

to-do list for libxcrypt
------------------------

* Near future:
  * Update all of the default cost parameters
    * relevant benchmarking at
      <https://pthree.org/2016/06/28/lets-talk-password-hashing/>
    * the default used by `crypt_gensalt_*` for new hashes should be
      controllable independently from the default used if there is no
      rounds= annotation in a setting string
  * Make the crypt and crypt_gensalt static state thread-specific?
    * if allocated on first use, this would also shave 32kB of
      data segment off the shared library
  * Factor out all of the repetitive base64 code
    * get rid of the de/serialization code in crypt-bcrypt.c that
      still does dodgy things with type punning
  * Attempt to determine the copyright holders and intended licensing
    of the test suite
  * Moar tests
  * Make sure the symbol versioning macros work with all of the compilers
    that anyone needs (they use GCC extensions that clang also supports).

* Longer term:
  * Hash algorithms newer than bcrypt tend to want to allocate and
    scribble all over a large (tens of megabytes at a minimum) block
    of memory, to make brute force hard in a way that GPUs and ASICs
    can't easily accelerate.  The existing API cannot handle this for
    three reasons:
    * `crypt_gensalt` only takes a single cost parameter, some
      algorithms have several
    * With everything except `crypt_ra`, all of the memory is
      allocated by the caller and there's no way for algorithms to say
      how much they need
    * There is no destructor function, even with `crypt_ra` - callers
      just pass the block to `free`

So we need to invent a new API that allows for more variety in
    cost parameters and allocations.  It could also make the "all the
    sensitive data, including stack scratch, is in crypt_data which we
    auto-erase" feature more robust by adding guard bands and calling
    mlock().

* Additional hashes to investigate adding:
    * scrypt <https://www.tarsnap.com/scrypt.html>
    * Argon2 <https://password-hashing.net/>
    * ...?

* 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)

cmd: