From 1a1d0e95b8da5e67fb76589eecf72aa7592d7dd7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 4 Apr 2017 12:48:13 -0400 Subject: move TODO to doc/todo, expand a few items --- doc/todo/future_encryption_tunables_changes.mdwn | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/todo/future_encryption_tunables_changes.mdwn (limited to 'doc/todo/future_encryption_tunables_changes.mdwn') diff --git a/doc/todo/future_encryption_tunables_changes.mdwn b/doc/todo/future_encryption_tunables_changes.mdwn new file mode 100644 index 0000000..8a9b29d --- /dev/null +++ b/doc/todo/future_encryption_tunables_changes.mdwn @@ -0,0 +1,18 @@ +If switching any of the encryption tunables for some reason, +consider making these changes all at once: + +* Argon2d is more resistent to GPU/ASIC attack optimisation. + Switching from Argon2i would require new tunables, and delay restores + (of keys backed up using the old tunables, and when the user provides the + wrong name) by ~10 minutes, so deferred for now + until there's some other reason to change the tunables. +* The ShareIdents derivation currently appends a number and sha256 hashes + to generate a stream of values. Ben M points out that HMAC is a more + typical way to do such a thing. Even better, a HKDF-Expand + (RFC5869) can generate a stream which can then be chunked up into values. + Either of these would avoid a full pre-image attack on SHA-2 breaking + keysafe. Of course, such an SHA-2 attack would be a general security + disaster. HKDF may prove more robust in the face of partial SHA-2 breaks. + Deferred for now until tthere's some other reason to change keysafe's + tunables. +* Perhaps use CHACHA2 instead of AES? -- cgit v1.2.3