diff options
| author | Joey Hess <joeyh@joeyh.name> | 2017-01-25 15:32:31 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-01-25 15:32:31 -0400 |
| commit | d471029790667c3630078f7054fa86dc41ffadc4 (patch) | |
| tree | 447fcd2d0a94df47f4303cf2ec637fda4d4c75f1 /doc | |
| parent | 6da465ce37d737951fe61e32327002e0bf1a1aa1 (diff) | |
| download | keysafe-d471029790667c3630078f7054fa86dc41ffadc4.tar.gz | |
add better object-id derivation idea
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/details.mdwn | 34 |
1 files changed, 34 insertions, 0 deletions
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.) |