Thanks. The fact that MD5 is fast is indeed an issue I've overlooked (although I understand this issue falls under "ugly but not too dangerous", I think the exploding tire example at crypto.se conveys how ugly it is).
The problem is that I'm specifically looking for a reasonably-secure backward compatible application for oplop users to migrate to. Maybe the best thing to do would be to find an existing better solution (is there one?) and write some glue code that can help with the migration, and maybe this problem can't be solved and oplop users should abandon it altogether (and do what instead?). I'm glad to hear that except for the first issue (strengthening the password), faults are only "ugly but not too dangerous". My question is: is there a way I could solve the first problem by adding something to the code (unless the user specifically asks for oplop compatibility)? On Mon, Nov 19, 2012 at 5:53 PM, CodesInChaos <codesinch...@gmail.com>wrote: > I didn't look at your code, but from what I remember oplop is a silly > scheme: > > 1. Doesn't strengthen the password (Uses MD5 instead of PBKDF2, scrypt,...) > 2. No clean domain separation between username and password > 3. The algorithm that ensures that the password contains numbers is really > weird > and leads to biased outputs. Should use a rejection based approach > instead. > 4. It uses MD5 instead of a newer hash-functions. While collisions > don't affect the scheme, > it's still preferable to use a strong hash-function. > > The first issue reduces security significantly, the rest are mainly > ugly but not too dangerous. > > We had a discussion of oplop on crypto.SE a few months ago: > > http://crypto.stackexchange.com/questions/3489/do-md5s-weaknesses-affect-oplop >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
