I think, Andrey makes a very important point here. The option to use 3DES symmetric encryption, SHA1 digest and ZLIB compression must remain open until a formal process of phasing them out is initiated, with a clear road map. Right now, excluding these algorithms would break interoperability in a very bad way, as described by Andrey. Of course, SHA1 and 3DES are not without problems, but for most security-critical applications they are still perfectly adequate. Also note that prior to ECC, any symmetric cipher could have been matched with any public key algorithm, because the secure block size for asymmetric encryption algorithms (ElGamal and RSA) well exceeded the key sizes for symmetric block ciphers. The encryption of session keys with random padding has never been an issue. With ECC, this is no longer the case. For instance, 256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit curves are used. Finally, I would like to draw the group's attention to a special need of moblie communication, that seems not to receive due attention. While it is true that computational power is less and less of an issue with mobile phones (although there are still plenty of under-powered devices in use and even in production), the message size issue is here to stay for much longer. In GSM networks, which are by far the most common around the globe, peer-to-peer messaging between handsets is done in 1120-bit chunks, for which operators charge money. Using an RFC4880-compliant format, even the shortest message using reasonably strong asymmetric encryption (1024-bit RSA), requires two chunks, which cost exactly twice as much for the sender (and in some North-American setups even the recipient) as a regular text message. Short public key and encrypted session key sizes of ECC may actually prove to be the primary driving force behind its adoptation in the mobile world, even if Moore's law renders low computational costs irrelevant. On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: > > David Crick wrote: > ... > > > >The ecc-pre-6.txt's section 2 pretty much says "this is how to > >do ECC with AES," and we've said that this proposal is a "MAY." > >In a sense this is therefore some kind of a fork (sub-superset?) > >of 4880, so we're not concerned with 3DES (or CAST), and - as > >with DSA - we can make specific restrictions in order to meet > >compliance. > > I think we need to be careful here. Let's examine a use case. > > I am a user of some RFC 4880 OpenPGP application. All algorithms are > available to me, e.g. I am not a government employee. > > * I use the application to encrypt mail to 5 recipients, my friends. > They use RSA/DSA/ElGamal keys. > > * I upgraded the application to the next version that happened to > implement "ECC in OpenPGP". > > I assume that we agree that if I encrypt to exactly the same 5 people > with new version, as far as algorithm selection is concerned, the result > is identical to the previous version. > > * I added 6th recipient to the list, which uses ECDH key. > > I hope we will agree that it must be possible to send single e-mail to 6 > recipients. RFC 4880 specifies that the default encryption algorithm is > 3DES, thus, there is always a match. Why shouldn't single e-mail be sent > to 6 recipients with 3DES symmetric key? > > If the application is operating in Suite-B mode, or FIPS more, etc, then > the situation is different. > > > > >Dependant on the "low spec" argument/evidence, we could just > >make one of the larger curve-hash pairs as the MUST, and make > >AES256 as the must cipher. Then if we need to encrypt to one > >of the two bigger curves *and* a smaller curve then we just > >"up" the cipher to AES256 for the small curve recipient. > > RFC 4880 currently grants to a user of embedded device a method to say > "don't do AES-256 to me" by using cipher preferences that exclude AES > 256. We should respect this. We cannot change the fact that there are > hardware platforms that don't implement or don't like AES 256.
Attachment:
signature.asc
Description: Digital signature