Re: [Cryptography] RSA equivalent key length/strength
ianG writes: On 14/09/13 18:53 PM, Peter Fairbrother wrote: But, I wonder, where do these longer equivalent figures come from? http://keylength.com/ (is a better repository to answer your question.) I assume that web site only takes account of time, it does not base its calculations to cost of doing cracking, which would also include the space needed to do the actual calculations. Old paper from year 2000 which takes also space calculations in to account http://www.emc.com/emc-plus/rsa-labs/historical/a-cost-based-security-analysis-key-lengths.htm says that to crack 1620 bit RSA key you need 10^10 years, with 158000 machines each having 1.2*10^14 bytes (120 Tb) of memory (year 2000 $10 trillion estimate). Cost of that amount of memory today would still be quite high (at $3-$10 per GB, the price would be hundreds of thousands - over million dollars per machine). Most of key size calculations in the net only take account the time needed, not the space at all, thus they assume that memory is free. For symmetric crypto cracking that is true, as you do not need that much of memory, for public keys that is not true for some of the algoritms. -- kivi...@iki.fi ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Password hashing
Joseph Ashwood writes: On NetBSD HMAC-SHA1: There is a shortcut in the design as listed, using the non-changing password as the key allows for the optimization that a single HMAC can be keyed, then copied and reused with each seed. this shortcut actually speeds attack by a factor of 3. The fix is to use the salt as the HMAC key, this assumes much less of the hash function. When you are trying to crack password, you do know the SALT and iteration count. You do not know the password. You need to try all possible passwords with different salts. As we use the password we are trying as an input to our test function we need to initialize hmac_sha1 again for each pasword we are guessing. Or did I understand something wrong. With your fix I could take the SALT from the passwd string and initialize first level of hmac with it and then feed different password to it. On USERID || SALT || PASSWORD: Adding USERID to the calculations will firstly break API compatibility, as the crypt function do not know the userid. It will also break the ability to copy the encrypted passwords from one machine to other, even when you would need to change user id in the progress (If I need to set up account for someone on my machines, I usually either ask them to send me already encrypted password I can put in to my /etc/password, or ask them to send me ssh public key... -- [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
