Re: ECC in OpenPGP proposal

Daniel A. Nagy wrote:
> 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.
>
>   
I agree. As a side note, it is a easier to deal with hashes, because the 
sender produces one signature data structure. Compare this with 
encryption when the sender may need to creates multiple ESK. I think we 
can disallow encoding with SHA-1 from this proposal without 
compatibility issues, but not RFC 4880 encryption algorithms.
> 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.
>   
I will note that current proposal doesn't have this limitation. It 
doesn't use ElGamal ECC. It uses key wrapping mechanism defined in 
RFC3394 for session key transport. I provided source code to see how the 
wrapping is done: http://brainhub.googlepages.com/aeswrap-RFC3394.c.html.
> 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.
>   
I agree. It is likely that many mobile vendors that entertained the idea 
of implementing OpenPGP passed on this format because of resource 
constrains. We will never know for sure, but we should attempt to give 
them another opportunity. OpenPGP makes a lot of sense for mobile 
communication.
I paid special attention in this proposal to the size of per-message 
data structures, such as ESKs. I moved anything that can be moved from 
the per-message data structures into the public key.