From f28476f0f3887535fe8c21603933c8831db9d203 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Wed, 19 Jun 2019 16:29:24 +0100 Subject: [PATCH] line wrap and fix wording --- proposals/2134-identity-hash-lookup.md | 28 ++++++++++++++++---------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/proposals/2134-identity-hash-lookup.md b/proposals/2134-identity-hash-lookup.md index cd5e3868..8ccfcfce 100644 --- a/proposals/2134-identity-hash-lookup.md +++ b/proposals/2134-identity-hash-lookup.md @@ -53,7 +53,12 @@ Then, clients making a request to `/lookup` must use the hashing algorithm defined in whichever version of the CS spec they and the IS have agreed to speaking. -Identity servers can specify their own peppers, which can be handy if a rainbow table is released for their current one. Identity servers could also set a timer for rotating this value to further impede rainbow table publishing. As such, it must be possible for clients to be able to query what pepper an identity server requires before sending it hashes. Thus a new endpoint must be added: +Identity servers can specify their own peppers, which can be handy if a rainbow +table is released for their current one. Identity servers could also set a +timer for rotating this value to further impede rainbow table publishing. As +such, it must be possible for clients to be able to query what pepper an +identity server requires before sending it hashes. Thus a new endpoint must be +added: ``` GET /_matrix/identity/v2/lookup_pepper @@ -81,15 +86,15 @@ Thus, a call to `/bulk_lookup` would look like the following: "threepids": [ [ "email", - "user@example.org" + "vNjEQuRCOmBp/KTuIpZ7RUJgPAbVAyqa0Uzh770tQaw" ], [ "msisdn", - "123456789" + "0VnvYk7YZpe08fP/CGqs3f39QtRjqAA2lPd14eLZXiw" ], [ "email", - "user2@example.org" + "BJaLI0RrLFDMbsk0eEp5BMsYDYzvOzDneQP/9NTemYA" ] ], "pepper": "matrixrocks" @@ -143,13 +148,14 @@ that needs updating every time a new bind is made. Further considered solutions are explored in https://signal.org/blog/contact-discovery/ Signal's eventual solution of using SGX is considered impractical for a Matrix-style setup. -Bit out of scope for this MSC, but there was an argument for not keeping all -IDs as hashed on disk in the identity server, that being if a hashing algorithm -was broken, we couldn't update the hashing algorithm without having the -plaintext 3PIDs. Well @toml helpfully said that we could just take the old -hashes and rehash them in the more secure hashing algorithm, thus transforming -the algo from ex. SHA256 to SHA256+SomeBetterAlg. This may spur an MSC in the -future that supports this, unless it is just an implementation detail. +While a bit out of scope for this MSC, there has been debate over preventing +3pids as being kept as plain-text on disk. The argument against this was that +if the hashing algorithm (in this case SHA-256) was broken, we couldn't update +the hashing algorithm without having the plaintext 3PIDs. Well @toml helpfully +added that we could just take the old hashes and rehash them in the more secure +hashing algorithm, thus transforming the hash from SHA-256 to +SHA-256+SomeBetterAlg. This may spur on an MSC in the future that supports +this, unless it is just an implementation detail. ## Conclusion