From 063b9f60e0441f252df7cdf00fc5b5ee1774b99a Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 18 Jun 2019 16:50:47 +0100 Subject: [PATCH] Require a salt to defend against rainbow tables --- proposals/2134-identity-hash-lookup.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/2134-identity-hash-lookup.md b/proposals/2134-identity-hash-lookup.md index 9b448d68..bc25b92e 100644 --- a/proposals/2134-identity-hash-lookup.md +++ b/proposals/2134-identity-hash-lookup.md @@ -43,10 +43,12 @@ CpvOgBf0hFzdqZD4ASvWW0DAefErRRX5y8IegMBO98w SHA-256 has been chosen as it is [currently used elsewhere](https://matrix.org/docs/spec/server_server/r0.1.2#adding-hashes-and-signatures-to-outgoing-events) -in the Matrix protocol. As time goes on, this algorithm may be changed provided -a spec bump is performed. 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. +in the Matrix protocol. Additionally a hardcoded salt (“matrix” or something) +must be prepended to the data before hashing in order to serve as a weak +defense against existing rainbow tables. As time goes on, this algorithm may be +changed provided a spec bump is performed. 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. No parameter changes will be made to /bind, but identity services should keep a hashed value for each address it knows about in order to process lookups