Confirmed users
471
edits
Identity/CryptoIdeas/01-PBKDF-scrypt: Difference between revisions
Jump to navigation
Jump to search
→Updates / Discussion
| Line 277: | Line 277: | ||
* I'm going to try cross-compiling the scrypt() code to JS with [http://emscripten.org/ Emscriptem] to see how much of a slowdown we get. On Chrome, we could use conceivably use [https://developers.google.com/native-client/overview NaCl] to run the scrypt() code at full speed, although currently they're only allowing NaCl code to run inside apps downloaded from their app store. | * I'm going to try cross-compiling the scrypt() code to JS with [http://emscripten.org/ Emscriptem] to see how much of a slowdown we get. On Chrome, we could use conceivably use [https://developers.google.com/native-client/overview NaCl] to run the scrypt() code at full speed, although currently they're only allowing NaCl code to run inside apps downloaded from their app store. | ||
* the scrypt parameters (and PBKDF ones too) must be the same for all devices accessing the same account. If they aren't baked into the client code, the first device must choose them (and hope they aren't too slow for the other devices), MAC them with a derived KEY, then store the parameters on the server along with the SRP salt. Later, clients must fetch and use the parameters to derive the keys, then check the MAC before revealing any information about the derived keys. The goal is to prevent a server from providing artificially low parameters in the hopes of learning a less-well-protected oracle. There is subtlety here that needs thought. | * the scrypt parameters (and PBKDF ones too) must be the same for all devices accessing the same account. If they aren't baked into the client code, the first device must choose them (and hope they aren't too slow for the other devices), MAC them with a derived KEY, then store the parameters on the server along with the SRP salt. Later, clients must fetch and use the parameters to derive the keys, then check the MAC before revealing any information about the derived keys. The goal is to prevent a server from providing artificially low parameters in the hopes of learning a less-well-protected oracle. There is subtlety here that needs thought. | ||
* 01-May-2012: following Ben's advice, I'm updating this to remove email addresses from the Storage Server, instead indexing its storage with anonymous "account IDs", derived in the HKDF step along with the wrapping key and the SRP password. The only wrinkle is that we need to use a fixed SRP salt. | |||
* 01-Mar-2012: bitcoin miners are moving to [https://plus.google.com/108313527900507320366/posts/2ztAhLnXQKm FPGAs], dropping the likely cost of dedicated SHA256 hashing by perhaps 10x. | |||