Identity/CryptoIdeas/01-PBKDF-scrypt: Difference between revisions

Identity/CryptoIdeas/01-PBKDF-scrypt (view source)

Revision as of 20:02, 6 June 2012

383 bytes added , 6 June 2012

→‎Protocol Diagram

Warner

Confirmed users

471

edits

@@ Line 349: / Line 349: @@
 == Protocol Diagram ==
-This four-page PDF diagram contains complete details on the protocol,
+The following PDF diagrams contains complete details on several variants of
-including how the salts are generated, and the client/server messages that
+the protocol, including how the salts are generated, and the client/server
-are exchanged. The first page describes the basic KDF operation and the
+messages that are exchanged.
-"init" message which establishes or retrieves the user's "S2" selection index
-and "S3" shared secret. The second page shows how S2/S3 are used to perform
-protected requests. The third page shows the "get" and "set" protected
-requests. The final page shows the "change password" request (which combines
-a "get" request, to fetch the UK, then uses a new "change" message to replace
-the stored data with a re-encrypted row).
-Note that this proposal abandons the use of SRP in favor of a shared-secret
+* [[media:Keywrapping-details-anon-noSRP.pdf|anonymous data, no SRP]]
-retrieved during the first (TOFU) request. This avoids revealing
+* [[media:Keywrapping-details-anon-SRP.pdf|anonymous data, yes SRP]]
-password-derived data during the subsequent requests (which would otherwise
+* [[media:Keywrapping-details-email-SRP.pdf|email-indexed data, yes SRP]]
-allow a MitM to get the same brute-force power as the server).
-[[media:Key-wrapping-details-noSRP.pdf|Protocol Diagram]]
+In each document, the first page describes the basic KDF operation and the
+"init" message which establishes or retrieves the user's SRP verifier or (for
+the non-SRP case) their "S2" selection index and "S3" shared secret. The
+second page shows how SRP or S2+S3 are used to perform protected requests.
+The third page shows the "get" and "set" protected requests. The final page
+shows the "change password" request (which combines a "get" request, to fetch
+the UK, then uses a new "change" message to replace the stored data with a
+re-encrypted row). There is also a "delete data" request that is similar for
+all variants.
+The anonymous-data forms never reveal the user's email address to the server,
+which somewhat increases an attacker's costs, but prevents account-based
+rate-limiting of online attacks. In all cases the "TOFU" window exists only
+during the init phase: once that setup has been performed, all subsequent
+messages could safely be sent in the clear.
 == Updates / Discussion ==