summaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
authorZack Weinberg <zackw@panix.com>2018-10-20 12:36:02 -0400
committerZack Weinberg <zackw@panix.com>2018-10-20 12:36:02 -0400
commit4bb73c595925a4603393ff25751ada66921919d9 (patch)
treefdae530af6af60d915265b37dbe218747b650334 /TODO
parenta19bb7e1ae3e954b8852f50fd70ca496839989b5 (diff)
downloadlibxcrypt-4bb73c595925a4603393ff25751ada66921919d9.tar.gz
libxcrypt-4bb73c595925a4603393ff25751ada66921919d9.tar.bz2
libxcrypt-4bb73c595925a4603393ff25751ada66921919d9.zip
Revise the to-do list.
Diffstat (limited to 'TODO')
l---------[-rw-r--r--]TODO57
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