add better object-id derivation idea

2 files changed, 51 insertions, 5 deletions

diff --git a/TODO b/TODO
index c018dc8..7b56c90 100644
--- a/TODO
+++ b/TODO
@@ -39,11 +39,6 @@ Later:
 * Add some random padding to http requests and responses, to make it
   harder for traffic analysis to tell that given TOR traffic is
   keysafe traffic.
-* 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.
 
 Wishlist:
 
@@ -86,3 +81,20 @@ Wishlist:
   restore from working. (It also makes a malicious data attack (as described
   in https://keysafe.branchable.com/details/) possible by attackers who do not
   control the servers.
+
+Encryption tunables changes:
+
+* 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.
diff --git a/doc/details.mdwn b/doc/details.mdwn
index e0f85e5..b014b2b 100644
--- a/doc/details.mdwn
+++ b/doc/details.mdwn
@@ -363,3 +363,37 @@ This could be used in several ways:
   objects for both. If the user is being forced to give up their keysafe
   name and password, they could provide the fake name, and if it were
   used, their data would get deleted from the keysafe servers.
+
+### Better object-id derivation
+
+An idea from Ben M:
+
+> I was the fellow who mentioned using an HMAC instead of
+> append-index-and-hash to generate the object-ids in keysafe.
+> 
+> That's probably an okay approach if you need to bind the output to a
+> particular input string, but on reflection (unless I missed something)
+> it would be equivalent for keysafe to take a stream and chop it up, then
+> just "number" the chunks sequentially.
+> 
+> In that case, the "most correct" choice would probably be HKDF (RFC5869
+> [1]).  Specifically, the second part of HKDF -- "HKDF-Expand".
+> 
+> (The first part, HKDF-Extract, is appropriate to apply /before/ key
+> stretching, but stretching itself serves much the same purpose --
+> removing "structure" from the input key.  Especially given that Argon2
+> is designed specifically to handle user passwords, I expect that
+> HKDF-Extract is entirely unnecessary here.)
+> 
+> HKDF is what TLS 1.3 will use to expand its per-session master keys into
+> individual keys for encryption and MACing [2], and AFAIK is generally
+> considered The Right Way to generate a stream of distinct keys from a
+> master key, where the compromise of any key should not permit derivation
+> of the others.
+> 
+> So, um.  Pretend I never mentioned HMAC, but spruiked HKDF instead :)
+> 
+> (Of course, this is pretty much bikeshedding.  A first pre-image attack
+> on SHA-2 in the near term would be a rude shock, and a full break would
+> break HKDF too.  But HKDF may prove more robust in the face of partial
+> breaks, giving more time to move everyone to a new hash or scheme.)