begin quoting David Brown as of Fri, Aug 29, 2008 at 08:51:52AM -0700: > On Fri, Aug 29, 2008 at 01:29:15AM -0700, SJS wrote: > >begin quoting David Brown as of Fri, Aug 29, 2008 at 12:04:50AM -0700: > >>On Thu, Aug 28, 2008 at 11:03:01PM -0700, SJS wrote: > >> > >>>(Plus, there are now "new" attacks on hashing functions, so the > >>>"hash a secret" technique might not last for too much longer. Whee!) > >> > >>The hashes are still secure as long as the attacker doesn't get to > >>choose the secret. > > > >Well, when you have a counter or a timestamp, you've got a > >partially-known plaintext. I shudder to think about how much > >effort it would take to extract a key with such means... > > My point is that people haven't yet found weaknesses against the hash > functions as far as finding an input text that produces a given hash. > This still requires brute force.
Your point was that we're not looking at chosen-plaintext attacks, when in fact it's not quite that simple when you're dealing with a sequence of known values. How do you compute a permutation of bits? You _count_. Given a permutation function, the difference between choosing a plaintext and using a known plaintext is a matter of timing. Granted, it isn't much, it isn't ideal, and it's by no means complete. But it's also not terribly clear-cut. > If your secret is 64-bits, it requires 2^63 tries on average to find > the secret. Having the small number as part of it doesn't help any. Hm. I thought the number you were tossing about was 20 bits. Besides, you're assuming that the attacker is going to engage in a brute-force attempt at logging in to the server. That's a really poor assumption. > Otherwise, all you're saying is just FUD. You can shudder all you > want, but that isn't an attack. The hash functions are currently > believed to be secure when used in this manner. WTF are you blathering about? Shove your FUD where the sun doesn't shine and stop adopting the mannerisms of a snake-oil salesman. I didn't say it was EASY. It would take a ton-and-a-half of effort even if the cryptanalysis weenies could use the information to come up with something orders of magnitude better than brute-force. > >>The broken hashes aren't useful for signature purposes, since the > >>attack allows two arbitrarily modified documents to produce the same > >>signature. > > > >I lost your point at "since". > > The attacks that have been discovered against the hash functions are > very specific, in that they allow an attacker to start with a given > plaintext and modify it in two different ways that both end up > producing the same hash. This effort has been made trivial for MD5, > but not yet for SHA-1. > > The other attack, which is against HMAC, but not against commonly used > hash functions, allows arbitrary messages to be authenticated. This > requires specific and weak hash functions, and still doesn't reveal > the secret. So you're NOT talking about Shamir's new approach, which (according to the handful of summaries I've read) appears to provide information on the key. And you were talking about two attacks, not just one, which is part of what I found confusing. (As to whether the ability to modify a document and retain the hash being useful for signature purposes... that's fodder for another thread. There's probably a couple of non-esoteric ways to turn that capability to one's advantage, but they're not applicable to Andrew's desired solution.) > My point here is that this attack is completely irrelevant to the Ah. That is why I got lost as the "since" -- it seemed completely irrelevent. > keying model we're discussing. None of the plaintext can be chosen by > the attacker. The secret is unknown, and the counter is a well-known > integer. If you try using the wrong counter, the server will reject > it. A counter is just a permutation engine. And you seem to have mistaken my comment about "not lasting much longer" as being a claim that hashing is already broken, which I did NOT say; if I somehow implied such a thing, I did not mean to. I am continually amazed at just how much information the cryptanalysis folks can extract from encrypted traffic. Smug complacency doesn't seem terribly wise -- better to go with cautious optimism. (Or maybe optimistic cynicism.) > A homebuilt fob would have a significant weakness over the RSA fob, > however, since I doubt we would be able to design something capable of > destroying the secret upon tampering. I still suggest basing it on a > smartcard, where someone else has already solved many of the security > problems. Yes, but the reliability problems are far more significant, and the infrastructure isn't there, so you're still hauling around a USB adaptor in order to use the smartcard... I really like the idea of smartcards. But I'm finding out that they're basically broken and not yet suitable for general use. -- Why not just use a OTP and store five year's worth of data on the device? Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
