On 30 May 2012, at 15:43, Douglas Huff wrote: > Not to mention that adding that functionality almost forces the real seed to > come from a prf/prng meaning using scrypt for the initial key deriv starts > making sense as you're now deriving a key for a cipher which is what scrypt > is for.
I'm unsure how that addresses Jonathan's concerns about loss of a master password. Adding a prng means I need to maintain state. I'm not entirely sure what you're envisioning here, I'd be interested to find out, though. > > You should also really look at using half of the derived key as an > authenticator like the example scryptenc code or similar. Why? It seems like scryptenc does that mostly so it can tell the user if they've used the wrong password (and thus decrypted junk rather than the original plain-text). I don't think I have a need for that. Have I missed something? > > The other issues with your counters aside: I don't understand your thought > process there. The stated goal was to not have to store state; but, the > counters are state that must be stored. The moment you chose to store > counters you failed your stated goal and lost the usability claim that could > be argued to outweigh some of the other issues brought up. Care to explain? > Did I miss something? The counter is a simple number that shall be 0, unless the user has willingly incremented it for a site. In that case, yes, they need to remember that they have. It's not a big deal, because even if the user forgets, it's not hard to walk the counter until Master Password gives him a password that passes the site's authentication. I don't believe it takes away significantly from the usability, while it is required for some use cases. > > You could remove the counters and replace them with an hmac-whatever of a > user+site+pass packed string. Then it's acting more like a traditional salt. > I think this would address state storage somewhat. Now you just need a way to > derive instead of store the position in the stream. I'm unsure what a HMAC of the inputs would add to the scheme. > > I also have similar misgivings about your about your output schemes as has > been brought up. Not to mention, that's more stored state. > > I'm just not seeing that you accomplished your stated goal? The output scheme requires the user remember a password type. This defaults to "Long Password", and again, unless the user willingly changes it. Again, it's not too difficult for a user that forgot to try the different types until the site stops complaining. The iOS implementation of Master Password stores state in a sense, in that it remembers all previously used site names along with the counter and type value for each. The stated goal is that if you drop that device down the toilet and buy a new one from the store, you can get all your passwords back purely from memory (and potentially some trial-and-error for some sites if you've forgotten the exact values of the parameters -- nothing unsurmountable for a recovery scenario).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
