Dan McDonald wrote: > On Tue, May 15, 2007 at 06:29:47PM +0400, lamo at ccs.ru wrote: >> Dan McDonald wrote: >>> On Tue, May 15, 2007 at 05:02:51PM +0400, lamo at ccs.ru wrote: >>>> Hi all, >>>> >>>> I've got a question about implementing combined mode algorithm to be >>>> used in IPsec. >>> Is it a well-known algorithm? We haven't used any such algorithms in our >>> IPsec yet - your experience would benefit the community. >> No. It's not a well-known algorithm. But the ability to use such type of >> combined mode algorithm is written in RFC 4303. I think it'd be great to >> have OpenSolaris IPsec implementation to support *both* types of >> combined mode algorithm (if it turns to be possible, because it may be >> too algorithm-specific). > > I see - you're looking at section 3.2.3 of 4303, which says: > > For example, the SPI and Sequence Number fields might be replicated > within the ciphertext envelope and an ICV may be appended to the ESP > trailer. None of these details should be observable externally. > > And that will be needed to be taken into account for some algorithms... just > not any that are specified today. >
Not only this particular section but also sections: 2, 2.4, 2.8, 3.2.3, 3.3.2.2, 3.3.3, 3.4.4.2 > Can you share your cipher with us as well? Or is it some sort of classified > algorithm? It'll be VERY hard to justify supporting the second kind of > cipher without some publishable algorithm that exploits the > copy-SPI-and-replay field. > It's a pity but this is algorithm is classified. And I understand the burden to implement such algorithm. But I think that actual implementation is irrelevant in this case. I can provide basic algoritm characteristics as block length, key length, ICV lenght and etc. The main goal is to implement the support for such kind of combined mode algorithms. But again, it may turn out that to support this type of algorithm is not generic enough:( And here I agree with you completely that we need more examples of such algorithms in public domain. >> I've read it before starting my work ( as well as RFC 4309 - AES CCM). And >> it's an example of the other type of the combined mode algorithm >> i.e. integrity for (data that is encrypted + additional data which is not >> encrypted). The same is true for rfc 4309. > > Both AES modes take the ESP/replay into their calculations, but without > adding 'em to the ciphertext. It's called AAD (Additional Authentication > Data). > >> Please, correct me if I'm wrong. > > I think you're right.f > >>> If there's shortcomings for combined-mode algorithms in our ESP, ESP's >>> interfaces to/from the Crypto Framework, or both, this would be a fine time >>> to address 'em. >>> >>> Off the top of my head: >>> >>> - I *think* ipsecalgs(1M) may need to be extended to indicate a >>> combined-mode cipher. Right now I think we assume all the world's >>> CBC, which isn't accurate. >>> >>> - We may need help in the IPsec-to-Crypto interfaces. I know the >>> crypto folks are working on AES-CCM for reasons not related to >>> IPsec. It's most likely we could get RFC 4309 (AES-CCM with ESP) >>> working before RFC 4106 (AES-GCM). >> To the best of my knowledge, atm, you have to do nothing (global) to >> current IPsec implementation to use AES-CCM and AES-GCM besides >> actually writing this algorithms' kernel modules:) > > How do you pass the values that need to be included but aren't part of the > explicit ciphertext? I don't see how to do that. We need a way to pass AAD > into a combined-mode cipher. We have a way to do it with MAC algorithms, but > not with ciphers. We also have a way to pass it to "dual" algorithms. See crypto_dual_cipher_mac_ops (9s) for exaple. ( hail to SCF guys ). > >> But to add the second type we ( community if you offer us such >> opportunity of course) have to discuss the best way to modify current >> IPsec implementation and (very probably) IPsec-to-Crypto interfaces. It >> will depend upon the way we choose to implement (i.e. just extendind the >> Payload Data or provide additional space which will be on of the >> argument to kCF functions or another way). > > We're going to have to account for AAD whether or not we copy it into the > packet's ciphertext. > >>> If you're ready to get combined-mode ciphers working with ESP, we're ready >>> to >>> help. It's an architectural issue, so we'll need to ARC it, but don't let >>> that bother you. >> I'm ready:) > > I wish you could share your copy-AAD-into-ciphertext algorithm. As it is, if > you can wait for the crypto folks to deliver AES-CCM, then you could get > AES-CCM working with IPsec! > I'll discuss the possiblity to redesign an algorithm (i.e. to make it conform to first type of combined mode algorithm same as AES CCM ( GCM)) with the authors. Seems to me that atm this way is the fastest one:) After that I can, of course, share the skeleton ( w/o actual algorithm implementation). But, I think the guys which are on AES CCM case ( which was mentioned by Darren) will do it faster than me:) Though, we may compete:) > Thanks! > Dan > > __________ NOD32 2264 (20070514) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > >
