Sheng, I am not talking about finding a collisional public-private key pair, whatever that is.
I'm talking about a CGA hash function with broken pre-image resistance. Given a CGA CGA1 generated (via the hash function) from a public-private key pair PK1/SK1, if can find a preimage to the CGA1, I can extract from the preimage another public-private key pair PK2/SK2 that yields the same CGA CGA1, and thus I can impersonate that CGA CGA1 by signing messages with the public-private key pair PK2/SK2. There's no need to break anything in the SEND specification, neither the digital signature algorithm, or the hashes. I simply break the hash function used for CGA generation. --julien On Wednesday 02 July 2008, Sheng Jiang wrote: > Hi, Julien, > > Your example is correct. However, it is misleading. You were talking > about you have found a collisional public-private key pair. In that > case, no matter how strong the hash algorithms are, you can break the > whole security system. Our assumption here is: based on a collision > free public-private key pair, whether one hash algorithm with two > results or two hash algorithms with two results are stronger. My > choice is the latter. > > Best regards, > > Sheng JIANG, Ph.D. > > IP Research Department, Networking Research Department, Network > Product Line, Huawei Technologies Co. Ltd. > > > *-----Original Message----- > *From: julien laganier [mailto:[EMAIL PROTECTED] On > *Behalf Of Julien Laganier > *Sent: Wednesday, July 02, 2008 6:17 PM > *To: Sheng Jiang > *Cc: [email protected]; [EMAIL PROTECTED] > *Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version > *of "Send Hash Threat Analysis") > * > *Hi Sheng, > * > *If I can generate a public-private key pair that yields an > *arbitrary CGA (attack against your A below), then I can > *impersonate that CGA's owner by simply signing with that > *public-private key pair -- no need to break the digital > *signature algorithm (your B). > * > *--julien > * > *On Wednesday 02 July 2008, Sheng Jiang wrote: > *> Hi, Julien, > *> > *> I can agree with you that SEND and CGA may use the same hash > *function. > *> Actually, in the current protocol, they do use the same sha-1. > *> However, we should also allow/support that they use different > *> algorithms through we may not recommended it. > *> > *> I don't agree with your statement "the security of the resulting > *> system can't be stronger than the weakest of its components". > *> Actually, in many cases, it may be opposite: the strongest > component *> decides the attacker's difficulty. Let's put it into a > concrete *> example here, say, SEND uses algorithm B that stronger > than *algorithm > *> A in CGA and there is an attacker who can break algorithm A > *but not B. > *> Then, the attacker may produce a faked CGA option, but because he > *> cannot produce a faked SEND signature option that use > *algorithm B, he > *> can still get through the SEND verification. When multiple > *algorithms > *> are use together, the attacker has to break all algorithms to > break *> the security system. > *> > *> Best regards, > *> > *> Sheng > *> > *> *-----Original Message----- > *> *From: [EMAIL PROTECTED] > *> *[mailto:[EMAIL PROTECTED] On Behalf Of Julien Laganier > *> *Sent: Tuesday, July 01, 2008 10:24 PM > *> *To: [email protected]; [EMAIL PROTECTED] > *> *Subject: [CGA-EXT] Hash Agility in SEND (Was: new version of > *"Send *> Hash Threat Analysis") > *> * > *> * > *> *Hello Ana, CSI'ers, > *> * > *> *I think I disagree with the paragraph of the draft copied *below > my *> note. > *> * > *> *To me it seems OK to specify that SEND should use the same *hash > *> function than CGA. Since they are used together to *provide > *security, > *> and since the security of the resulting *system can't be > *stronger than > *> the weakest of its components, *the maximum level of security can > be *> reached by choosing *mechanisms (hash functions in this case) > with *> similar security *strength for both CGA and SEND. > *> * > *> *Improving the security level of only one of the component > **would not > *> increase the overall security of the system. > *> * > *> *Has anybody an opinion on the topic? > *> * > *> *--julien > *> * > *> *> 4. Support for the hash agility in SeND *> > *> *> While all of analyzed hash functions in SeND are > theoretically *> *> affected by recent collision attacks, these > attacks indicate *> the *> possibility of future real-world > attacks. In order to *> *increase the > *> *> future security of SeND, we suggest the support for the > *hash and *> > *> algorithm agility in SeND. > *> *> > *> *> The most effective and secure would be to bind the hash > *> function *> option with something that can not be changed at > all, *> like *> [rfc4982] does for CGA - encoding the hash function > *> information into *> addresses. But, there is no possibilty *to do > that > *> in SeND. We could *> decide to use by default the same hash > *function > *> in SeND as *in CGA, but *> this solution is architecturally > strange *> and it does not really *> increase the security since the > difficulty *> for attackers remain to *> break one single hash > function. *> Furthermore, it may even reduce the *> security level by > providing *> more relevant information of the hash *> function. On > the *other side, > *> the use of two different hash *algorithms *> makes attacker's life > *> harder. > *> *> > *> *> Another solution is to incorporate the hash function option > *> into *> SeND message. By putting a new hash function option in > SeND *> message *> before RSA Signature option, attacker will have to > break *> both the *> signature and the hash input at the same time > since the *> new option *> will be input field for the Digital > Signature in RSA *> *Signature option. > *> *> However, we can not avoid a downgrade attack totally because > peer *> *> might be using just ND and not SeND. A completely safe > *solution *> here *> does not exist. A new hash function option in > SeND *message is > *> a *> reasonable and the best solution for the hash algorithm > agility *> *> support in SeND. > *> *> > *> *> Each implementation SHOULD use different hash or signature > *> *> algorithms for each of the relevant fields (Key Hash > *field, Digital > *> *> Signature, PKIX signature algorithm). Since all > *algorithms are in > *> *> different procedures, making them the same does not make those > *> *> procedures simpler, but making them different complicates > *possible *> > *> attacks. > *> * > *> * > *> *On Tuesday 01 July 2008, Ana Kukec wrote: > *> *> The new version of draft-kukec-csi-hash-threat is submitted. > *> *Comments > *> *> are welcome! > *> *> > *> *> Filename: draft-kukec-csi-hash-threat > *> *> Revision: 02 > *> *> Title: SeND Hash Threat Analysis > *> *> Creation_date: 2008-07-01 > *> *> WG ID: Independent Submission > *> *> Number_of_pages: 15 > *> *> > *> *> Abstract: > *> *> This document analysis the use of hashes in SeND, > *possible *threats > *> and *> the impact of recent attacks on hash functions used by > SeND. *> *> Current SeND specification [rfc3971] uses SHA-1 [sha-1] > hash *> *algorithm *> and PKIX certificates [rfc3280] and does not > provide *> support for the *> hash algorithm agility. Based on > previous *> analysis, this document *> suggests multiple hash support > *that should > *> be included in the SeND *> update specification. > *> *> > *> *> > *> *> Ana > *> *> > *> *> _______________________________________________ > *> *> CGA-EXT mailing list > *> *> [email protected] > *> *> https://www.ietf.org/mailman/listinfo/cga-ext > *> * > *> * > *> * > *> *_______________________________________________ > *> *CGA-EXT mailing list > *> [EMAIL PROTECTED] > *> *https://www.ietf.org/mailman/listinfo/cga-ext > *> * > * > * > * > > > > _______________________________________________ > CGA-EXT mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cga-ext _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
