Re: ECC in OpenPGP proposal

["David Crick" <dacrick@xxxxxxxxx>]

On 3/1/08, Daniel A. Nagy <nagydani@xxxxxxxxxxxxxxxx> 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.

as someone said about alternative V5 key routes - let's absolutely
make sure we break it!

>  Of course, SHA1 and 3DES are not without problems, but for most
>  security-critical applications they are still perfectly adequate.

SHA1 is due to be retired in 2010 (at least for US Federal agencies).

That means 1024-bit DSA keys are due to demise soon.  The most
recent bruteforce of RSA was on a "special" form of ~1024-bit keys
(2^1039 -1); no doubt the normal form will fall in the not too
considerable future.

Germany has apparently said 1024-bit crypto is no longer allowed
as of 2008 (this was posted regarding OpenPGP smartcards on
one of the gnupg mailing lists).

CSE say 80-bit ciphers will no longer be acceptable for Protected
A & B information from 2010 (for protected C it was 2005) and
that for A & B pk modulus 1024 will no longer be acceptable from
2010 (again, for C it is already 2048 minimum).


The writing is on the wall for 1024 pks / 160 hashes / 80 ciphers!


That means our applications (and RFCs) need to be updated to
reflect this (*now!*; someone tell SSL web site maintainers...).

3DES is more of a "problem" - it's set to co-exist with AES until
2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto
we've still got 3DES as our OpenPGP vestigial tail.


So maybe we can mangle ECC support so that we can still use
3DES with it, or maybe we need to crack on with V5, make it ECC
only, and - as with the PGP 2 -> PGP 5 transition - have people
run parallel apps (or send multiple messages) if they want to
inter operate with 2048-3072-bit mod. non-ECC OpenPGP users.


>  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.