Hi Nicolás Just a few comments, with no good suggestions....
> 3. Project executables are signed by RSA-encrypting a MD5 hash of the > file. So, what it sounds like is somewhat like a signature, but using the public key rather than private key. I'm in uncharted territory at the moment, and I really can't comment. I'd need think about things after getting into the literature. And I'm not sure my thinking would produce anything useful :) Perhaps it would be a good idea to move to PSS or Full Domain Hashing? Full Domain Hashing was just being discussed on another list (in the context of RSA signatures and OAEP). http://www.cs.ucdavis.edu/~rogaway/papers/exact.pdf. > To break this you need a second-preimage attack. MD5 has known > collision attacks that make it useless for anything needing > collision-resistance, but the best known preimage attack brings the > complexity from a 2^128 brute-force to 2^123 We also have chosen prefix attacks. They were theoretical until Flame appeared. Confer: http://www.google.com/#hl=en&q=chosen+prefix+attack+md5. > With current attacks and hardware, the Sun > will turn into a red giant *long* before you can make a file that has > the same MD5 hash as an existing BOINC science app. Yes, agreed. But its usually not brute force we worry about. > "Your software will never be so secure that the easiest means of > attack comes down to the hashing algorithm" -- Cody Brocious Ah, yes. But it helps keep the beggars off, and I strive for perfection. Put another way, I don't allow another's short comings to lower my bar. Jeff On Sun, Jan 27, 2013 at 7:52 PM, Nicolás Alvarez <[email protected]> wrote: > 2013/1/27, Jeffrey Walton <[email protected]>: >> MD5 is completely broken, and has no cryptographic value. Yet it >> appears to be used in cryptographic routines. > > Follow-up: > > MD5's weaknesses aren't a problem for BOINC. > > 1. Passwords are stored in the server, and sent from the client to the > server, in a completely insecure way. To be clear: it has as much > security as using plaintext, despite using MD5. Changing the hash > algorithm won't solve that. > > 2. Authentication for everyday requests doesn't use the password > anyway. The password is only used when you attach the project, to get > the "account key" (a randomly-generated MD5-looking hex string), and > then the account key is used for all further communication, without > hashing or challenge-response or anything. This string has the > additional property that, unlike passwords, users cannot change it; so > if it's compromised you're doomed forever. > > 3. Project executables are signed by RSA-encrypting a MD5 hash of the > file. To break this you need a second-preimage attack. MD5 has known > collision attacks that make it useless for anything needing > collision-resistance, but the best known preimage attack brings the > complexity from a 2^128 brute-force to 2^123. That's still > *completely* infeasible. With current attacks and hardware, the Sun > will turn into a red giant *long* before you can make a file that has > the same MD5 hash as an existing BOINC science app. > > In summary, client-server authentication is completely insecure and > it's not MD5's fault, and executable signing is secure despite MD5. > > "Your software will never be so secure that the easiest means of > attack comes down to the hashing algorithm" -- Cody Brocious _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
