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]
Re: Password hashing
- Original Message - From: "Tero Kivinen" <[EMAIL PROTECTED]> Sent: Monday, October 15, 2007 5:47 AM Subject: 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. It is true that the first two iterations of the compression function in my supplied solution are computationally irrelevant, while in the current design the first two are computationally relevant, but the second time through the HMAC the situation reverses, the password keyed HMAC has exactly the same pre-salt state as the in the first HMAC iteration, and so in the second and subsequent HMAC iteration the first two applications of the compression function are computationally irrelevant, but in my solution there is no prior knowledge of the key for the second and subsequent HMAC iteration and so the first two applications of the compression function are computationally relevant. So my given solution trades the computation in the first two compression function computations for the millions of subsequent compression function computations. Asymptotically this is a 3 fold improvement, and so it is a very good change. It is also worth noting that most passwords, even so called "good" passwords, have only a small amoutn of entropy, and a 50,000 word list will contain a significant number of all passwords on a system, there are more salts, and so storing the precomputations of the passwords versus the precomputations of even a 32-bit salt is radically different. On USERID || SALT || PASSWORD: Adding USERID to the calculations will firstly break API compatibility, as the crypt function do not know the userid. There is a choice, do it right, or keep the API. I am firmly on the side of doing it right. While the USERID is irrelevant if the SALT can be made to never repeat, that is a very hard thing to truly accomplish, especially across multiple disconnected systems. It will also break the ability to copy the encrypted passwords from one machine to other, So it prevents people from doing something that is poor security. 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... While the design is being changed (as you noted making this change would necessitate other changes) it is worthwhile to eliminate other security poor decisions as well. Joe - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: fyi: Storm Worm botnet numbers, via Microsoft
[EMAIL PROTECTED] said: > I have two problems with this report. thanks for commenting on it. I pointed to it in order to see what denizens of this list might have to say about it. I'm simply curious. Also, as I'd noted, I haven't really seen any estimates of Storm's extent -- other than that article [0] -- that actually go into any details about how the number is arrived at (however bogus or not the approach might be). Also, I'm personally mostly just curious and have done only modest searches for info. And based on that, I've only come across the (typically) unsubstantiated "one or two million zombies" [1] to "(breathless) maybe /50 million/ out there" [2] articles/posts. > Firstly, I don't think this is a very > representative sampling technique compared to the estimates from security > companies. I haven't come across any detailed Storm extent analysis, even with having Google search specific security company sites (e.g. using "site:sec-corp.com"). So if anyone has pointers to pages (other than the MSFT blog article pointed to in an earlier post) that present a sane and substantiated analysis of Storm extent, please post 'em. Maybe folks don't want to (post 'em or point to 'em)? Are there papers in submission? ;-) > If you look at the sample that's being used, "Windows machines > that have automatic updates turned on", then the typical machine is going to > be configured with something like Windows XP SP2 with all available hotfixes > and updates applied, in other words the very systems that are (one would hope > :-) the *least* likely to be affected by malware. agreed. > If you take the rule-of- > thumb estimate that's sometimes used on MSDN blogs of 1B Windows machines out > there then 2.6M machines is < 0.3% of that total. Now this in itself > wouldn't be so bad if it was an unbiased sample, but in fact it's probably a > rather non-representative 0.3%. ..as compared to the overall population of windows machines, on the Internet, globally. agreed. > Although some of the numbers from security > companies for infections may be just guesswork, they also use broad sampling > across all Windows machines (not just ones with Windows Defender), honeypots, > monitoring of botnet traffic patterns, and other methods as well. pointers? > So while it's valid to say that this [the Anti-Malware Engineering > Team blog post [0]] provides data for Storm on fully patched, > up-to-date machines running Windows Defender, I don't think this generalises > for all Windows machines. agreed. > Secondly, the text completely contradicts the figures given. If the figures > really are accurate and not a typo, then 274K machines infected out of 2.6M > puts Storm on 10% of Windows PCs, which would make the worldwide infection > rate 100M systems, or ten times larger than the previous worst-possible case > estimate. a resonably-substantiated worst-case estimate? Because it's only twice as many as the 50M number thrown around in the likes of [2]. But yes, it'd be alarming if there's really 1B windows machines on the Internet (one way or another) and there's a reasonable probability of 10% being Storm zombies. > Storm may be big, but it's not *that* big. I think there's > something wrong with the figures. Yeah, one hopes so. So, it'd seem to me (tho I'm not a statistician) that if one could get a set of articles wrt Storm extent that say at least something to substantiate how they arrived at the numbers, and then do some back-of-the-envelope calcs, we'd have a better idea of what's going on, at least here in the public domain. I have to believe that there's folks working hard on this given the down-the-road risks, and are just keeping the info close to their collective chest. =JeffH [0] http://blogs.technet.com/antimalware/archive/2007/09/20/storm-drain.aspx [1] http://www.secureworks.com/media/press_releases/20070802-botstorm [2] http://www.neoseeker.com/news/story/7103/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Quantum Crytography to be used for Swiss elections
| Date: Sat, 13 Oct 2007 03:20:48 -0400 | From: Victor Duchovni <[EMAIL PROTECTED]> | To: cryptography@metzdowd.com | Subject: Re: Quantum Crytography to be used for Swiss elections | | On Fri, Oct 12, 2007 at 11:04:15AM -0400, Leichter, Jerry wrote: | | > No comment from me on the appropriateness. From Computerworld. | > | | Why so shy? ... Only that we've been over this ground so many times before. | There is real charm in the phrase "endowed with relevance and | purpose". | | One might, by analogy with the 2nd law of thermodynamics, speculate | that prior to some of the relevance and purpose of the election data | rubbing off on the QC system, the QC system was the one more lacking | in these desirable attributes. If wants to really go out on a limb, | one might try to apply the fist law also, and conclude that the | election data has as a result less relevance and purpose. | | In our physical analogy, heat is replaced with | "trust/relevance/purpose". One can transfer this "heat" from the | election to a technology or from a technology an election, always in | the expected direction. Ah, but this is a quantum system. I think it's more a matter of inducing correlations than a physical transfer. Are trust, relevance, and purpose orthogonal variables? That seems unlikely. So you need to trade of your ability to measure them. Ah, there are some trustworthy photons. Oops, we can trust them, but we don't know if they are relevant. Ah, there's a relevant photon -- Jerry :-) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Password hashing
| > ... What's wrong with starting | > with input SALT || PASSWORD and iterating N times, | | Shouldn't it be USERID || SALT || PASSWORD to guarantee that if | two users choose the same password they get different hashes? | It looks to me like this wold make dictionary attacks harder too. As others have pointed out, with a large enough salt, dictionary attacks become impossible. But it's worth mentioning another issue: People's userid's do change and it's nice not to have the hashed passwords break as a result. (This is pretty counter-intuitive to users who change their names, and a disaster if a large organization needs to do a mass renaming and somehow has to coordinate a mass password update at the same time.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Password hashing
Martin James Cochran <[EMAIL PROTECTED]> writes: >This might work, although 90% of the steps seem to unnecessarily (and >perilously) complicate the algorithm. What's wrong with starting with input >SALT || PASSWORD and iterating N times, where N is chosen (but variable) to >make brute-force attacks take longer? Or just use PBKDF2, RFC 2898. It does what's required, has been vetted by cryptographers, is an IETF standard, has free implementations available, ... Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
