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
