Amir Herzberg wrote:
For a stationary user, the extension compares _Iterations_ and confirm it is at most one less than previous value of _Iterations_ used with this site.
(Minor point - if relying on incrementing Iterations, this may impact password sharing scenarios. Whether that's a good thing or a bad thing depends...)
Also, the extension keeps a table r(PK) mapping the public key PK of each login site to an independant random value (we need this as real random value and can't derive them from the PW, to prevent dictionary attacks by fake sites).
I suspect this would not work so well in the (common enough?) cases where a site uses a farm of SSL boxes and certs; a couple of sites I've come across provide different certs every time (although admittedly I saw this with IMAP TLS not with browsing).
Now, using a single PW, extension computes for a site with given PK the value H(0)=h(PK, h(r(PK), PW).
What is the reason for hashing twice? Instead of the more obvious H(0)=h(PK, r(PK), PW) ? (Also, you are missing a closing parenthesis there so maybe your intent was other.) (Somewhat challenging your assumptions here) your design does not seem to cope with MITM. But, it may do if you are assuming there is an extension that is handling the client side, and the exchange is the setup for later transactions, not the transaction itself: the server can send back its token X which needs to be further hashed in order to gain the useful token for later: Y = h(..., X, PW); where Y could be the session identifier or cookie or something. In this way both sides have proven their possession of the password and hopefully eliminated other parties from further comms. (But I may have misunderstood something...) iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]