I'm going to attempt to summarize/rehash the comments I've found have a significant relevance to the quality of the algorithm. I've had a lot of great feedback, which I'm tremendously thankful for. My apologies in advance for any important aspects that any of you have highlighted if I forget to include them here.
[1] There's no way to recover or change the master password without forcing the user to set new passwords for each of their sites. [2] It's difficult for a user to come up with a master password that's high in entropy. [3] Master passwords with weak entropy put the user at a significant risk of having all their passwords "stolen". [4] The algorithm can do with some tweaking and cleaning up. (eg. no overly high scrypt output key size, employ HMAC over SHA1, remove scrypt in favor of alternative hashing functions, ...) [5] The terminology in the algorithm's documentation can be improved. [6] There are quite a few input values that the user is expected to remember in order to reproduce his passwords on another clean device. [7] The master password can be determined relatively easily using a rainbow table built for the given scrypt parameter values and either a hash of the master key or all of the site name + site password counter + site password type + site output password. [8] The modulo operator introduces a bias when used to choose an element from a range. [9] The "cipher" currently employed to construct an output password yields a password whose entropy is significantly below the ideal. Proposals to address these issues: [1] Instead of creating a hash of the master password, create a salt value on the device using a pseudo-number generator. Use that salt to computer the master key. This allows changing the Master Password, and protects against rainbow tables, but turns Master Password into a stateful solution. [2] I currently propose sentences. This may yet be insufficient. [3] Known issue. The master password must be decent. [4] Parameter values can be optimized such as scrypt parameters, ciphers, etc. We can also change things like use proven HMAC over SHA-1 where relevant. [5] The vocabulary must be fixed or amended. [6] Most of the current input values have good defaults which will not generally be changed by users. For those that users to change, the user can fairly easily recover from forgetting the parameter value by means of some trail-and-error. [7] A salt must be added when scrypt is used or afterwards, when the master key is used. This salt should be high enough in entropy that it makes it infeasible to construct a rainbow table for each salt value. [8] Consider replacing the modulo operator or fixing its bias. [9] Perhaps the cipher can be improved upon. Additional cipher candidates might help. Ideally, the solution does not sacrifice usability. If I've missed any issues, highlight them for me. I believe the algorithm can be fixed by introducing a salt, ideally one that's memorable to the user, and its initial goal preserved. Presumably, it will never be quite as secure as using the output of dd (| base64) as a password.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
