Propping up SHA-1 (or MD5)
It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) However, this allows an attacker to play with Random (the advice I've seen is that if one is going to use an IV with a hash function, then one should transfer the IV with integrity checks to deny attackers this freedom). Another objection is that this construction changes the API at the sender end, which could lead to a great deal of complexity when the use of the hash API is deeply embedded. A third is that the length of the hash is changed, which could break existing protocols. Musing on these points, I wondered about the construction: H'(x)=H(H(x) || H(H(x) || x)) which doesn't allow an attacker any choice, doesn't change APIs and doesn't change the length of the hash. Does this have any merit? Note that this is essentially an HMAC where the key is H(x). I omitted the padding because it seems to me that this actually makes HMAC weaker against the current attacks. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: how to phase in new hash algorithms?
Hi, Ian G wrote: Steven M. Bellovin wrote: So -- what should we as a community be doing now? There's no emergency on SHA1, but we do need to start, and soon. The wider question is how to get moving on new hash algorithms. That's a bit tricky. Normally we'd look to see NIST or the NESSIE guys lead a competition. But NESSIE just finished a comp, and may not have the appetite for another. NESSIE is now called Ecrypt and _does_ do something on Hash functions, see http://www.impan.gov.pl/BC/05Hash.html It's not a call for a new hash function, I admit this, but I guess it's too early for something like this anyway at the moment. CU, Christopher - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: how to phase in new hash algorithms?
As ex-NESSIE project manager: NESSIE was an EU-funded research project with funding for 40 months (2000-2003). The "NESSIE guys" still exist as individual organizations but the NESSIE project is no longer in existence. There is a follow-up, but with somewhat different goals, called ECRYPT (http://www.ecrypt.eu.org). We are organizing a kind of stream cipher competition. On June 23-24 there will be a workshop on hash functions in Przegorzaly (Krakow), Poland. Xiaoyun Wang, Eli Biham, and Hans Dobbertin are invited speakers. Deadline for submissions: 1st May 2005 Early registration deadline: 31st May 2005 We plan to discuss at this workshop also the way to go forward on hash functions (for example, should there be a new competition for hash functions?). Organizing this kind of competitions is beyond the current scope and financial means of IACR, but IACR could consider to sponsor events related to such an activity. --Bart COSIC - Katholieke Universiteit Leuven On Mon, 21 Mar 2005, Ian G wrote: > Steven M. Bellovin wrote: > > > So -- what should we as a community be doing now? There's no emergency > > on SHA1, but we do need to start, and soon. > > The wider question is how to get moving on new hash > algorithms. That's a bit tricky. > > Normally we'd look to see NIST or the NESSIE guys > lead a competition. But NESSIE just finished a > comp, and may not have the appetite for another. > NIST likewise just came out with SHA256 et al, and > they seem to have a full work load as it is trying > to get DSS-2 out. > > How about the IACR? Would they be up to leading > a competition? I don't know them at all myself, > but if the Shandong results are heard at IACR > conferences, then maybe it's time to take on a > larger role. > > Most of the effort could be volunteer, and it would > also be easy enough to schedule everything aligned > with the conference circuit. > > Just a thought. Anyone know anyone at the IACR? > > iang > -- > News and views on what matters in finance+crypto: > http://financialcryptography.com/ > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Do You Need a Digital ID?
| if a re-issued a new token/card (to replace a lost/stolen token/card) is | identical to the lost/stolen token/card ... then it is likely that there is no | "something you have" authentication involved (even tho a token/card is | involved in the process) ... and therefor the infrastructure is just single | factor authentication. | | at the basics, a digital signature is an indirect indication of "something you | have" authentication aka the existance of a digital signature implies | that the originator accessed and utilized a private key in the generation of | the digital signature. a digital signature by itself says nothing about the | integrity of that "something you have" authentication ... since the digital | signature doesn't carry any indication of the integrity measures used to | secure and access the associated private key. This is a rather bizarre way of defining things. "Something you have" is a physical object. On the one hand, any physical object can be copied to an arbitrary degree of precision; on the other hand, no two physical objects are *identical*. So a distinction based on whether a replacement is "identical" to the original gets you nowhere. A digital signature is just a big number. In principal, it can be memorized, thus becoming "something you know". As a *number*, I don't see how it can, in and of itself, *ever* be something you *have*. >From a purely information point of view, there is not, and cannot be, any difference among the different authentication modalities. A house key can be represented as a fairly short number (the key blank number and the pinning). Even a very fancy and elaborate key - or any physical object - can, in principle, be represented as a CAD file. While "something I am" is difficult to represent completely this way (at least today!), it doesn't matter: A "something I am" *authentication element* has to ultimately be testable for veracity on the basis of information the tester has access to. The meaningful distinction here has to do with possible modes of attack, constrained by the *physical* characteristics of the system. An authentication element is "something you have" if an attacker must gain physical possession of it to be able to authenticate as you. The "closeness" and length of time the attacker must possess the element form the fundamental "measures of quality" of such an element. A house key is a prototypical "something you have". Duplicating it requires the ability to physically hold it. (One can, of course, imagine taking very detailed photographs from a distance, or using some other kind of remote sensing technology. While possible in principle, this would be a very expensive and difficult attack in practice, and we generally ignore the possibility.) Keys with restricted blanks are relatively difficult to duplicate even if you have physical possession. We generally assume that you can take a key back, thus revoking access. This is also a general property of any "something you have" authentication element - and is truely present only to some degree. Still, one can meaningfully ask of such an element "How many copies are in existence? Who has access to them?" Conversely, "something you know" can, in principle, only be learned by you revealing it. Once revealed, a "something you know" element cannot be revoked. It can be copied easily, and determining who might know it is usually impractical once there is any suspicion of compromise. A key card by itself is like a blank house key. It becomes "something you have" when it's encoded with a password, a digital signature private key, or some other secret that's, say, part of an interactive zero-knowledge proof system. The quality of the key card depends on how easy it is to extract the information and produce another key card that can be used in its place. Of course, quality is a *system* property. A house key "reveals its secret" when placed in a lock - any lock. While I could easily enough build a lock that would read off the pinning of any key inserted into it and send it to me on the Internet, this doesn't at present appear to be a threat that needs to be defended against. We generally assume that locks are simple physical devices that don't leak any information. On the other hand, a key card by its very nature sends information into a digital system, and protecting information once it is in digital form is challenging. If I could know to a sufficient degree of certainty that my keycard would only be used in "secure" readers which would send the information no further, there would be relatively little difference between a key card with a simple password encoded on a magnetic strip, and a house hey. Both would provide a "something you have" element. A "digital signature" isn't an authentication element at all! We incorrectly analogize it to a traditional signature, because inherent in the notion of the latter is a whole system embodyi
Re: how to phase in new hash algorithms?
- Original Message - From: "Steven M. Bellovin" <[EMAIL PROTECTED]> Subject: how to phase in new hash algorithms? We all understand the need to move to better hash algorithms than SHA1. At a minimum, people should be switching to SHA256/384/512; arguably, Whirlpool is the right way to go. The problem is how to get there from here. ... So -- what should we as a community be doing now? There's no emergency on SHA1, but we do need to start, and soon. Phase 1 is to change the hash function choice from implicit to explicit. Specifically instead of having hash = "457253W4568MM48AWA2346", move to hash = "SHA-1:lq23rbp8yaw4tilutqtipyu.". Then over time ratchet down the default. There is also an easy argument that it may be beneficial to skip SHA-256 entirely. The argument put succinctly is: 64-bit computing is arriving on 64-bit systems SHA-512 is nearly twice as fast as SHA-256 (crypto++ benchmarks). SHA-512 is at least as strong, and faster. Joe - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
