Revise the to-do list.

1 files changed, 1 insertions, 56 deletions

diff --git a/TODO b/TODO
index 66db86b..cde952b 100644..120000
--- a/TODO
+++ b/TODO
@@ -1,56 +1 @@
-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)
+TODO.md
\ No newline at end of file