Subject: Re: ECC in OpenPGP proposal

From: [email-masked] (Daniel A. Nagy)
Date: Sat, 1 Mar 2008 10:03:15 +0100

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.

---

From: "David Crick" <[email-masked]>
Date: Sat, 1 Mar 2008 12:44:23 +0000

>  > with DSA - we can make specific restrictions in order to meet

(further to my point above, if we really want ECC to support
3DES then the ECC document needs to be updated for that)

>  to 6 recipients with 3DES symmetric key?

I use PGP 2.6, I upgrade to PGP 5.0.  Shiny new DH/DSS
keys - but no RSA support!  Until the RSA patent expired
(well, was placed prematurely into the public domain) we
ran parallel systems and/or kept "old" and "new" keys.

Even now with 3DES as a must, we have this delightful
phrase in 4880:

"Implementations MUST implement TripleDES.  Implementations SHOULD
implement AES-128 and CAST5.  Implementations that interoperate with
PGP 2.6 or earlier *need to* support IDEA, as that is the only symmetric
cipher those versions use.  Implementations MAY implement any other
algorithm."

"need to"!

But, NB, "might not be able to" - due to the IDEA patent.

I seem to recall one of the PGP (5+) versions popping up
a message about mixed V3/V4 (or RSA/DH) keys when I
attempted to encrypt something (or maybe it was due to
an IDEA/3DES conflict).  (Maybe Jon can confirm my vague
recollections here?)

>  the situation is different.

right.

>  hardware platforms that don't implement or don't like AES 256.

OK, but they SHOULD support AES-128 (which would make
a 128-256-256 ECC MUST not seem absolutely unworkable).

Question: how "interoperable" do these "embedded devices"
need to be with the rest of the world?

---

From: "David Crick" <[email-masked]>
Date: Sat, 1 Mar 2008 13:26:01 +0000

>  bad way, as described by Andrey.

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

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

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 03 Mar 2008 13:42:03 -0800

> 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.
> reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit
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.

> mobile world, even if Moore's law renders low computational costs
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.

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 03 Mar 2008 14:10:24 -0800

Let me explain my choices in this respect in the ECC proposal.

We need 3DES as a fallback default to smoothly integrate ECC keys into 
existing installed base, as I mentioned earlier.

Fortunately, we are lucky with signatures.

* We know that most of deployed applications support SHA-256 already, 
the code is written and tested. 
* We can assume that when an applications understands ECC keys, it 
understands SHA-256.
* Although there are smartcard hardware vendors today that insist on 
exclusively using SHA-1, they only support RSA keys.
  (We hope their new release with ECC support will not have hardcoded 20 
bytes + ASN.1 prefix size check.)

It follows then that:

** Self-signatures can use SHA-256. (If an applications doesn't 
understand SHA-256, it doesn't understand ECC.)
** Because the key's self-signatures must be verified, data signatures 
and certifications with ECC keys can use SHA-256.
** Certifications on RSA/DSA keys with ECC keys can use SHA-256 too.
** Back signatures by subkeys can use SHA-256 too.

So, SHA-1, which is too weak for any curve in this proposal, can be 
safely disallowed for generation or verification of signatures made by 
an ECC key. Applications should be tolerant to SHA-1 on other keys or 
existing structures.

---

From: "David Crick" <[email-masked]>
Date: Mon, 3 Mar 2008 22:49:09 +0000

>  We need 3DES as a fallback default to smoothly integrate ECC keys
>  into existing installed base, as I mentioned earlier.

then (reluctantly, but not violently against) how about:

MAY implement ECC
  o MUST implement SHA256
  o MUST implement ECC256
[ o MUST implement 3DES - directly inherited from 4880, like it or not]
  o MUST implement AES128 [or just inherit the SHOULD from 4880??]

  o SHOULD implement AES256-SHA512-521ECC
  o MAY implement    AES256-SHA384-384ECC

  o SHOULD try to match cipher strength with ECC strength, where
    recipient key preferences allow.

(then need to add wording in about restrictions required for if strict
Suite B compliance is required.)

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 04 Mar 2008 00:12:01 -0800

> Suite B compliance is required.)

David, I agree with this.

Assuming this is consensus, I will change section 11.1 to "MUST 
implement curve with ID 1 and SHOULD implement curve with ID 3". Also in 
section 11.1, I will change to "MUST implement SHA2-256 and should 
implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST 
for OpenPGP profile.

I will add a few sentences about Suite B and RFC4880 (in)compatibility.  
The problems are very very similar to the issue of FIPS mode of 
operation and RFC 4880.

Regarding algorithm tupples, Section 12 already lists 
AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations.

I think it is better to break tupples into 3 pieces and address them 
independently. The choice of symmetric algorithm is governed by key 
preferences of (multiple) recipients. We shouldn't disregard preference 
list and prefer AES-256 (even for ECC keys). So section 11.1 tell 
MUST/SHOULD for individual algorithms and section 12 gives SHOULD 
recommendations regarding dependencies between algorithms.

After above changes to section 11.1, the only missing correction there 
is "SHOULD implement AES-256".

---

From: "David Crick" <[email-masked]>
Date: Tue, 4 Mar 2008 14:55:33 +0000

>  implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST

this sounds like what what we've got to so far, although I note
that this makes the [AES256-]SHA384-384ECC an *implicit* MAY
rather than *specifically* mentioning SHA384 and ECC384 as
MAYs.

So, should we *explicitly* mention them?

(also, an aside regarding repetition of a point I've previous made:
the (e.g.) keywrapping text in -pre6 only talks about AES; this
needs to be made more general, referring instead to keylengths.)

>  The problems are very very similar to the issue of FIPS mode of

yes

>  AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations.

the -pre6 document specifically lists  P384-SHA384-AES192
in 12 (which, as per NIST, *are* the matching strengths), with
the "MAY use stronger" in the paragraph before the table, but
with the the AES256 (as per Suite B) in 11.2.2 before.

All these pieces *together* allow for our discussed
AES256-SHA384-384ECC combination, i.e. to support Suite B
and to "drop" AES192.

>  independently.

Maybe it's because I haven't re-read the document as a whole
with all our changes in place, but I'm personally finding it a bit
hard to read our discussed cipher suggestions when they are
split up as they currently are.

Do you want to try producing a -pre7 so that we can see if we
think it (a) matches our growing consensus and, (b) says it in
a clear manner?

If it does then great, otherwise some section, paragraph and
topic re-ordering might be required.

> The choice of symmetric algorithm is governed by key
>  list and prefer AES-256 (even for ECC keys).

4880 section 13.2 says this:

   An implementation MUST NOT use a symmetric algorithm that is not in
   the recipient's preference list.  When encrypting to more than one
   recipient, the implementation finds a suitable algorithm by taking
   the intersection of the preferences of the recipients.  Note that the
   MUST-implement algorithm, TripleDES, ensures that the intersection is
   not null.  *The implementation may use any mechanism to pick an
   algorithm in the intersection.*

I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC
applications.  So, our ECC document would have something like:

  Having obtained an intersection of symmetric algorithm preferences,
  implementations SHOULD attempt to match symmetric algorithm size
  with public key size.

[*Personally*, I'd like to continue:
  ", favouring longer lengths where possible."]

  The following table provides current equivalent recommendations
  (SP800-57). Note TripleDES is considered to have 112-bit security.

           Asymmetric  |  Hash  |  Symmetric  |  Elliptic
            key size   |  size  |   key size  |  curve key
           (RSA + D-H) |        |             |  size
           ------------+--------+--------------------------
              1024        160         80           160
              2048        224        112           224
              3072        256        128           256
              7680        384        192           384
             15360        512        256           521

[the columns should probably be in a "better" order, this was
just copied from 4800 with ECC then added on the end]

>  So section 11.1 tell

Subject to my "clarity" point above, then OK, yes, I can see
this is how you are conveying this at present.

>  is "SHOULD implement AES-256".

yup.

---

From: Ian G <[email-masked]>
Date: Tue, 04 Mar 2008 16:02:38 +0100

> existing installed base, as I mentioned earlier.

Can you say more about this?  I do not see any reason to 
specify 3DES with ECC.

(Yes, I know it is in RFC4880.  I just don't know what that 
has to do with a separate ECC proposal.)

We all know that 3DES should be retired in favour of AES. 
This means, in principle, not to write it into any new 
proposals, and smooth the way forward to let the 
implementors phase it out.

The installed base is about private/public keys.  They 
*will* create the ECC keys any way you tell them.  If you 
don't tell them to set a preference for 3DES ... they won't 
do it.

Or have I got something wrong?

>> we've still got 3DES as our OpenPGP vestigial tail.

Sure.  Leave it there in RFC4880.  That's history.

Or are you telling us that Suite B mandates 3DES???

>> 3DES with it,or maybe we need to crack on with V5, make it ECC

iang

---

From: Ian G <[email-masked]>
Date: Tue, 04 Mar 2008 16:41:34 +0100

OK, I think I found it.  Sorry for not keeping up!

> bad way, as described by Andrey.

I disagree, below :)

> security-critical applications they are still perfectly adequate.

Right.  The question is not about the security of the 
algorithms (which are more or less Pareto-secure-ish). 
Instead, it is about the business aspects of delivering the 
most security to the most people.

>>> with DSA - we can make specific restrictions in order to meet

Yes.  This is a natural fork.  It is for people who want 
Suite B.  Which means the various USG organisations.  Which 
before have not in the past been that impressed with 
OpenPGP.  Actually, not impressed with anything in the open 
world, I'd say.  We are really in new territory now that the 
NSA/NIST people have opened their hearts and declared Suite B.

Which isn't to say that we shouldn't consider compatibility, 
but to say that this is a good, natural fork.  We should 
also think about taking it...

(I would.  I remember the pain that was PGP 5.)

>> * I added 6th recipient to the list, which uses ECDH key.

OK I see that.  If...

>> to 6 recipients with 3DES symmetric key?

Sorry, I don't agree.  The RFC4880 specification is only for 
applications that apply (more or less) to RFC4880!

Applications that implement both RFC4880 *and* 
OpenPGP/ECC/Suite B are given no guarantee that this is 
likely to be seamless and joyful and without any degradation 
in their promised user experience.

Just like S/MIME and RFC4880.

To imagine otherwise would be to say that RFC4880's promise 
is that *all future work* is also compatible.  That's 
hopeless.  How far do we want to take that promise?  OpenPGP 
quantum key exchange?  What happens if the Russkies decide 
they want an OpenPGP GOST and they decide it is incompatible 
by definition with OpenPGP ECC?  Or, we can retitle S/MIME 
as OpenPGP/S/Mime and insist on compatibility :)

My point:  It is *not* a given that people using OpenPGP 
Suite B can talk to people using RFC4880.  Desirable, sure, 
but not a given.

(I'd bet the NSA would prefer this *not* to be the case ;)

Example:  Consider properly written small-device platforms 
using the ECC stuff:  They will likely implement the 
AES128-ECC-SHA "small" profile, and not include 3DES at all. 
  The last thing anyone in the smart card / mobile world 
wants is incompatibility forced by vestigial circumstances. 
  They want all *their* people talking, and that means one 
system, one algorithm.  Talking to other people is a distant 
second in most business plans, and a controversial one at that.

>> the situation is different.

Yes, there are security ramifications.  Are we really 
implementing Suite B if the application can leak info by 
sending out emails encrypted in Suite B (strong) and in 3DES 
to some 512 RSA key (not so strong)?

iang

---

From: "David Crick" <[email-masked]>
Date: Tue, 4 Mar 2008 16:13:13 +0000

sorry, I did "reply to Ian" rather than reply to all (including the list),
which I meant to do.

---------- Forwarded message ----------
From: David Crick <[email-masked]>
Date: Mar 4, 2008 4:07 PM
Subject: Re: ECC in OpenPGP proposal
To: Ian G <[email-masked]>

 >  has to do with a separate ECC proposal.)

The argument has been that if we are to "add" ECC *onto*
 OpenPGP (which for the WG means "RFC4880") then we
 "MUST" implement 3DES.

 If we wanted to create an ECC-*only* standard or application
 then no 3DES would be fine, but it wouldn't be compliant with
 4880 or (necessarily) interoperable with an OpenPGP application
 (which might only understand 3DES) or respectful of a user's
 [existing] key preferences.

 >  implementors phase it out.

NIST have handled it this way:

 FIPS46-3 has been withdrawn.

 FIPS187 is the standard, which you are *encouraged* to use.

 3DES has been taken out of FIPS46-3 and issued as a (lesser)
 "special recommendation".  3DES lifetime is until 2030.

 Therefore, NIST say 3DES is OK but that AES is the preferred
 choice.

 *We* (4880) say that 3DES is a MUST and that AES128 (and
 CAST5, which CSE are also OK with) are SHOULDs.

 *NSA*, meanwhile, say that for *classified* stuff you may use
 any of the AESes, but that for TOP SECRET you must use
 one of the larger.  Further, they specify PK strengths, which
 at these lengths are ECC rather than absurdly big IFP/DLP
 RSA/DH ones.

 So, now that we are coming to implement ECC in OpenPGP,
 we naturally want to base things on the NIST/NSA guidelines,
 as well as considering implementation limitations and market
 requirements.

 We also have our OpenPGP history to take into account.
 So this means that have to support the 4880 MUSTs to
 remain compatible with current applications and user base.

 >  Or have I got something wrong?

that 3DES is an implied preference, even if not there.

 >  Or are you telling us that Suite B mandates 3DES???

no, Suite B doesn't mandate 3DES it doesn't.

 If we want to integrate into/with the current 4880 then
 3DES needs to be in[herited in!] OpenPGP-ECC.

 I'm not "over-joyed" by this, but if my "longer keys are
 preferred" bit is added onto the "SHOULD try and match
 sym. and pub. key lengths" bit then that's about as near
 to the "encouraging" of AES over 3DES as we are likely
 to be able to get.

---

From: "David Crick" <[email-masked]>
Date: Tue, 4 Mar 2008 16:36:19 +0000

> OK, I think I found it.  Sorry for not keeping up!

no problem.

Also, note that yours and my emails have overlapped in
our composing/sending, and that I unintentionally sent
me last email to just you rather than the list.

Hopefully everyone can now re-follow the discussion!
>  > bad way, as described by Andrey.

yes, I have also disagreed - and still do "in principle".

*However,* I can (now) accept that as a "way forward"
compromise we can have both ECC and some interoperability
with current OpenPGP.

I'm attempting to (subtly ;) ) try and implement wording for
us that similarly "encourages" use of AES over 3DES by having
an "implementations SHOULD try and match sym & pk key
lengths" bit, together if possible (help me here Ian ;) ) with a
further "longer lengths should be preferred".

Maybe we should even add an example:

  If Alice has a 1024 bit RSA key and Bob a 521-bit ECC key,
  and both Alice and Bob have AES256 as one of their
  possible cipher preferences, then implementations SHOULD
  choose this stronger cipher.

This is a hack on 4880's "implementations may choose any
method of selecting from the intersection of preferences" -
i.e., for ECC we are saying how implementations SHOULD
(but, note, not any stronger than SHOULD).  I feel this is both
within the spirit of 4880 *as well as* our best intentions to
encourage AES.

> Yes.  This is a natural fork.

But it has been pointed out that we can still keep 4880 compliance
by inheriting its 3DES (and then "encouraging" AES when used with
Ecc).

>  It is for people who want
>  Suite B.

I think there are "people who want *ECC*" and *also* people
who want Suite B.

Personally, I'd like to *only* see Suite B ECC, but consider
people thinking "hey, OpenPGP only has 384-bit ECC, but
<other product/standard> has 521-bit.  OpenPGP sucks!"

>  Which means the various USG organisations.
>  Which before have not in the past been that impressed with

yes, we certainly are.

>  (I would.  I remember the pain that was PGP 5.)

We could "force" a split, *or*, we could orchestrate a slow
migration, through adding ECC ("hey, cool, PGP has a new
public key algorithm.  It must be better!"), and then perhaps
with V5 keys.

>  in their promised user experience.

we're now saying there's a way.

>  AES128-ECC-SHA "small" profile, and not include 3DES at all.

Then they're not OpenPGP/4880 compliant/compatible/

>  second in most business plans, and a controversial one at that.

That one algorithm *at present* is 3DES.

>  to some 512 RSA key (not so strong)?

Going forward we need to re-establish what is considered
minimally secure.

With ECC we're effectively closing off SHA1 (as a hash; it'll
still be there for, e.g., the fingerprint, at least as I understand it).

With V5 keys we could vape SHA1 entirely, and set 2048 (IF/DLP)
/ 256 (ECC) public keys as the minimum lengths.

2030 is our next "target" - that will likely mark the point when we
need to shift from 3DES, SHA224 and 2048IFDLP/224ECC to (for
the lowest strength) SHA256-AES128-3072IFDLP/256ECC.

---

From: "David Crick" <[email-masked]>
Date: Tue, 4 Mar 2008 16:48:39 +0000

> Going forward we need to re-establish what is considered

I should have also have added that in our OpenPGP-ECC doc
we are pointing out equivalent strengths and further stating
that for Suite B compliance there are further restrictions.

I can see quite easily a PGP option checkbox or Gnupg flag
that says --strict-SuiteB-ECC.  This could *refuse* to encrypt
to multiple keys using a smaller cipher.

We have the same situation today.  There's no point me
changing my GnuPG source to allow me to generate a 7K
RSA encryption key, because unless all my correspondents
*also* use the same/equivalent/stronger lengths, then the
session key is at the mercy of the smallest public key size.

---

From: Len Sassaman <[email-masked]>
Date: Tue, 4 Mar 2008 08:52:04 -0800 (PST)

> as someone said about alternative V5 key routes - let's absolutely

That was more than one person, I think, but I was one of them.

Breaking compatibility on the protocol level doesn't mean breaking it on
the actually application level. In a different thread, there as discussion
of people using "regular" DSA/EG keys and then adding a recipient who uses
ECC. So what? The application can encrypt twice, and send the properly
encrypted messages to the appropriate people.

Backwards compatibility on the protocol level means forward compatibility
on protocol level attacks. Let's not do that, eh?

[Obviously we don't want to be breaking compatility all the time, but for
something as big as v5, that we've been talking about for almost a decade,
I think it's reasonable to both get it right, and cut the last decade+'s
legacy of cruft loose, and leave the application to support v4 and v5 if
the designer so desires. A lot of the things done in OpenPGP are, in
hindsight, missteps. Hindsight is cheap. Let's make use of it when it is
appropriate.]

--Len.

---

From: "David Crick" <[email-masked]>
Date: Tue, 4 Mar 2008 17:17:23 +0000

sorry, I once again did reply to sender rather than reply
to all - my reply was meant for everyone and not just
Len.

Hey, it's a *good* security habit to have! :)

---------- Forwarded message ----------
From: David Crick <[email-masked]>
Date: Mar 4, 2008 5:15 PM
Subject: Re: ECC in OpenPGP proposal
To: Len Sassaman <[email-masked]>

 > That was more than one person, I think, but I was one of them.

thanks for clarifying this.

 >  encrypted messages to the appropriate people.

I think I've also pointed this out (either that or I've thought it
 but not explicitly said it!)

 >  hindsight, missteps. Hindsight is cheap. Let's make use of it when it is

I really would *ideally* like to see just one cipher suite, which I see
 could see would be: SHA384-AES256-ECC384_DH_DSA.

 This uses our largest respective algorithms while being Suite B
 compliant.  As Ian pointed out, we really are into new territory with
 Suite B - PGP (2) used to say "military strength" when listing larger
 key sizes; now we can legitimately say "TOP SECRET strength"!

 [Yes, as an aside, I know that the latter would actually require
 restricted key generations, physical security measures, tamper
 evident seals, blah, blah, blah.]

 I'm actually more concerned that web sites are still using 1024
 bit (well, 1120 Bits it says for gmail for me) SSL public keys and
 SHA1, rather than the fact that somebody might use 3DES as a
 cipher when sending a message to my 521-bit ECC key.

---

From: Len Sassaman <[email-masked]>
Date: Tue, 4 Mar 2008 09:49:26 -0800 (PST)

>  could see would be: SHA384-AES256-ECC384_DH_DSA.

I'm with you on the one cipher suite. I think good protocols must have
methods by which new ciphers can be added (and implementors might actually
want to have them in the code and tested and ready should they need to
enable them), but the more options we add to a cipher suite, the more that
can go wrong.

(This is also my argument for why we should be using Whirlpool with AES,
but the counter argument of popularity/support for the second-gen SHAs
probably out-weighs it.)

Ian G. has written about this a lot, and he and I don't always agree on
everything, on this point, we do. OpenPGP already wants to do what I want
it to do; except the current notion is that if a cipher is broken,
everyone will disable support for it. That might have been a reasonable
assumption when only cypherpunks were using it, but it is naive now. If
you give the user a way to break their security, they will -- especially
if "not doing something" means breaking their security.

(As for which ciphers should go in, I'm going to remain agnostic. I would
pick differently than you did, but we all have our pet favorites. What
matters is that we limit the avenues of attack -- it's not about putting
all our eggs in one basket, as some confused people think; rather, it's
about limiting the possible crypto-level attacks on has available to them
when trying to break the system.)

--Len.

---

From: "David Crick" <[email-masked]>
Date: Tue, 4 Mar 2008 19:12:49 +0000

>  when trying to break the system.)

hey, you quoted my One Cipher choice without my corresponding
relevant justification! :)  But yeah, I agree that others will disagree.

I think we *all* agree that we'd like to see ECC in OpenPGP
(and for those that don't, the current proposal appears to
supplement, not obsolete, 4880, so they can continue in
their non-ECC world).  ECC will:

1) bring equiv. of 3K pub key to small devices
2) bring equiv. of 7 to 15K pub key to larger devices
3) allow OpenPGP to compete in the ECC marketplace
4) bring Suite B support (this is subset of some of the previous)

Now, we're currently fixating on the general topic of reducing
algorithms.  AES192 seems to be departing without too much
protest, but 3DES (and the wider topic of 4880 compatibility)
seems to be the current "issue."

With V5 keys I think we're envisaging some form of incompatibility?
For instance, Daniel's recently posted "Thoughts and suggestions
on V5 key format" suggests using SHA512 for the fingerprint
(which I'd agree with given present specified 4880 hashes).  Clearly
that would make SHA512 a MUST for V5 key applications - but it's
not even widely implemented/deployed yet (e.g. the last time I
checked, PGP9 wouldn't recognise SHA512 as a cert-digest-algo).

* So for me I think the whole ECC current point in question appears
to be: _when_ do we want to introduce ECC?  Do we want to have
it as an alternative V4 choice (in which case we seem to, e.g., by
default allow 3DES with ECC), or do we wait until V5 (when we then
might be able to say: only AES with ECC) ? *

Now, let's say our user installs PGP 10 and is allowed to generate
a V4 ECC key.

Several years later ;) with PGP 12 they are prompted to generate
a different (V5) ECC key as the default.  They are left wondering:
"didn't I already switch to the "new" ECC keys a few years ago???"

I think we want/need ECC in OpenPGP *soon*; I also think we need
to move away from SHA1/1024 bit IFP/DLP *soon* as well (where for
me, given various national and security bodies' recommendations,
"soon" = "by/before 2010").

So, do we try and do both together, or do we try and get ECC done
as a V4 alternative *now*, and think about V5 keys afterwards?

Thinking about is as I'm typing, I would favour ECC *first* and then
V5 after, the reason being that we're (hopefully!) likely to get
ECC consensus in a relatively short time, whereas V5 may take
longer and might/should also take into account the result of the
SHA3 contest, which isn't scheduled to finish until 2012.  (We could
probably (??!) flesh out V5 before then, just leaving a gap for the
details on SHA3.)

---

From: Ian G <[email-masked]>
Date: Tue, 04 Mar 2008 21:12:14 +0100

Lots of questions!  For me, the confusion is swirling around 
these questions:

The proposal in question is:

    (a) Suite B
    (b) ECC, and/or
    (c) mobile

Is it one of these?  All of them?  Two of them?

I would argue that (a) sounds good.  When the NSA speaks, I 
listen.  (normally it is the other way around...)  I like 
their Suite B and would copy it exactly, word for word, no 
deviations.

(b) sounds less good, as this involves much more work (e.g., 
doing it properly) and would tempt me to say "wait for V5!" 
  or "just listen to the NSA, guys."

(c) is something that should be done by the mobile guys, as 
Dani pointed out, there are special things that need to be 
considered.

One-size-fits-all will probably result in nobody being happy.

iang

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 04 Mar 2008 12:21:47 -0800

I respectfully remind you that the target of this proposal is 1) to 
better match AES key strength with OpenPGP by extending RFC 4880, 2) to 
meet Suite-B, 3) to offer more usable alternative for mobile/embedded 
systems.

Suite B is limited to section 11.2. Suite B will have limited 
interoperability with RFC 4880, just like currently FIPS certification 
is incompatible with RFC 4880. Most of your comments in this e-mail 
apply to small section 11.2.

The discussion earlier was mostly about OpenPGP ECC keys that are 
compatible with RFC 4880.

Ian G wrote:
> Right.  The question is not about the security of the algorithms 
> (which are more or less Pareto-secure-ish). Instead, it is about the 
> business aspects of delivering the most security to the most people.
>
>
> Yes.  This is a natural fork.  It is for people who want Suite B.  
> Which means the various USG organisations.  Which before have not in 
> the past been that impressed with OpenPGP.  Actually, not impressed 
> with anything in the open world, I'd say.  We are really in new 
> territory now that the NSA/NIST people have opened their hearts and 
> declared Suite B.
>
> Which isn't to say that we shouldn't consider compatibility, but to 
> say that this is a good, natural fork.  We should also think about 
> taking it...
>
>>> 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 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?
>
>
> Applications that implement both RFC4880 *and* OpenPGP/ECC/Suite B are 
> given no guarantee that this is likely to be seamless and joyful and 
> without any degradation in their promised user experience.
>
> To imagine otherwise would be to say that RFC4880's promise is that 
> *all future work* is also compatible.  That's hopeless.  How far do we 
> want to take that promise?  OpenPGP quantum key exchange?  What 
> happens if the Russkies decide they want an OpenPGP GOST and they 
> decide it is incompatible by definition with OpenPGP ECC?  Or, we can 
> retitle S/MIME as OpenPGP/S/Mime and insist on compatibility :)
>
> My point:  It is *not* a given that people using OpenPGP Suite B can 
> talk to people using RFC4880.  Desirable, sure, but not a given.
>
> Example:  Consider properly written small-device platforms using the 
> ECC stuff:  They will likely implement the AES128-ECC-SHA "small" 
> profile, and not include 3DES at all.  The last thing anyone in the 
> smart card / mobile world wants is incompatibility forced by vestigial 
> circumstances.  They want all *their* people talking, and that means 
> one system, one algorithm.  Talking to other people is a distant 
>>> If the application is operating in Suite-B mode, or FIPS more, etc, 
>>> then the situation is different.
>
>
> Yes, there are security ramifications.  Are we really implementing 
> Suite B if the application can leak info by sending out emails 
> encrypted in Suite B (strong) and in 3DES to some 512 RSA key (not so 
> strong)?
>
> iang

---

From: "David Crick" <[email-masked]>
Date: Tue, 4 Mar 2008 20:33:19 +0000

>  The proposal in question is:

the *original* document basically suggested (a), *BUT* with the
unsaid (but since spelled out) point that 3DES is implicitly
*also* allowed *if* we are extending 4880 / interoperating with
4880.

>  Is it one of these?  All of them?  Two of them?

was have since shifted to (b), with the (c) bit as the MUST.

>  listen.

It's the biggest endorsement (particularly after Suite B) that
[a subset of] our OpenPGP algorithms could possibly have.

> (normally it is the other way around...)

LOL

>  I like

ideally, yes, I'd say this too (extra ideally, I'd just go for
their bigger suite, the SHA384-AES256-ECC384_DH_DSA).

>   or "just listen to the NSA, guys."

agree with you on all your points here

>  Dani pointed out, there are special things that need to be

I think it was Dani that said that AES128 was too slow on the
Nokia (and so he was using RC4)?

In any case, I agree that just justifying the smaller algorithms
"*because of* mobiles" isn't in itself necessarily right.
(However, choosing the smaller algorithms "because of
mobiles *and* because they're secure enough generally
*and* because they're a Suite B subset  *is* closer to what
we're saying)

>  One-size-fits-all will probably result in nobody being happy.

How unhappy would *you* (personally; this is also open to
other people!) be with (each stage being possible points of
objection):

1) AES128-SHA256-ECC256 as the MUST (still talking V4 btw)
  2) with 3DES as an implicit MUST for 4880 interoperability
    2a) wording to encourage (SHOULD) matching algo. sizes
    2b) wording to point out additional restrictions for Suite B
      3) Future V5 keys to possibly make further restrictions

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 04 Mar 2008 12:55:18 -0800

Once again, this proposal is for each 3 of 1) ECC with OpenPGP within 
RFC 4880, 2) Suite B and 3) mobile.

This is a pragmatic proposal to extend RFC4880 to get benefits in each 
of 3 areas. This may not be perfect, for example, for PC folks and for 
mobile folks if they only focus on their hardware, but I believe it can 
be agreed upon if interested parties forgo some features in the interest 
of interoperability. This promotes the idea of a single key. Instead of 
having a SuiteB key, why not have an RFC 4880 ECC key that can be used 
for SuiteB or OpenPGP, PCs, PDAs, smartcards, HSMs, depending on 
software configuration?

Regarding V5, I don't see justification for it. I would view ECC DSA is 
a variant of DSA. Granted, it as a change in public key algorithm, but 
we have a mechanism to add new public key algorithm to RFC 4880.

Ian G wrote:
> Lots of questions!  For me, the confusion is swirling around these 
> questions:
>
> I would argue that (a) sounds good.  When the NSA speaks, I listen.  
> (normally it is the other way around...)  I like their Suite B and 
> would copy it exactly, word for word, no deviations.
>
> (b) sounds less good, as this involves much more work (e.g., doing it 
> properly) and would tempt me to say "wait for V5!"  or "just listen to 
> the NSA, guys."
>
> (c) is something that should be done by the mobile guys, as Dani 
> pointed out, there are special things that need to be considered.
>

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 04 Mar 2008 19:40:56 -0800

> So, should we *explicitly* mention them?

My thoughts on MAY were that since this spec is MAY in relation to 
RFC4880, the explicit MAYs on defined or otherwise referenced algorithms 
are redundant. If we define a curve and don't list it as SHOULD or MUST, 
I assumed that it follows that it is MAY.

Where do you see a benefit of explicit MAY? 384 ECC is defined in this 
spec, thus is MAY. SHA382 is MAY from RFC 4880 and AES256 is SHOULD in 
this spec.

Can using MAY once create questions as to why other combinations are not 
MAYs?

> needs to be made more general, referring instead to keylengths.)

You are right, there is a dependency on AES in this spec. It is 
currently required in AESWrap key wrapping method. I realize that you 
may have interpreted this differently. I prefer we fix AES with AESWrap 
method, and this is how the -pre6 is written. The argument about 
multiple recipients doesn't apply here, but relative strength does. I 
suppose that even embedded devices can use AES-256 as KEK for key 
wrapping and AES-128 for message encryption (or any other algorithm for 
latter) , because the performance of AESWrap is not an issue on up to 48 
bytes (the availability in hardware probably is). In any case, any of 3 
AES variants are allowed in current proposal for AESWrap, plus, we have 
AES-256 as SHOULD.

For example, http://www.ellipticsemi.com/products-clp-34.php shows 
hardware implementation, which is hardwired to AES 128 or 256.

(Just to be clear, nothing in this section applies to the choice of 
algorithm for symmetric message encryption key.)

> AES256-SHA384-384ECC combination, i.e. to support Suite B

Yes. The main reason to keep 192 is interoperability.

> topic re-ordering might be required.

Yes, I will update the spec based on latest feedback.

>   implementations SHOULD attempt to match symmetric algorithm size

I note that this issue is orthogonal to this spec, i.e. it applies to 
RFC 4880 as well. However, if there is a consensus, we can recommend 
this. One justification for "why now" is, practically speaking, ECC 
allows balanced strength while RFC 4880 doesn't. However, I would try to 
stay within RFC4880.

The issue of tightening is similar to other restrictions I put in 
section 12: MDC: SHOULD, S2K: iterated salted, SHA-1: MUST NOT. Ian 
suggested MDC/S2K to be MUST.

>   ", favouring longer lengths where possible."]

While we should not deprive implementations the allowed method to 
advertise prioritized preferences, I think we there is a room for 
improvement in "grey areas". For example,

* Two recipient keys have following ordered prefs.: {AES128, AES256} and 
{AES256, AES128}.
* RFC 4880 allows either of these sets to be the ordered intersection.

In this case we can "tighten" as you suggested.

Many of these issues are in the realm of key managing software. If user 
is adding single AES128 preference to ECDH 521, the software can warn her.
  
>             key size   |  size  |   key size  |  curve key

I will integrate feedback from everybody into the next revision. Thank you.

---

From: Ian G <[email-masked]>
Date: Wed, 05 Mar 2008 11:41:01 +0100

> I assumed that it follows that it is MAY.

To me as an implementor I want to see what the defined sets 
are.  Commentary or definition on curves may be all very 
interesting, but I would want to see the MAY set to 
understand what the recommendation was.  I'd assume other 
other implementors were also thinking around those MAYs.  If 
the question came up, I'd want the team leader to say 
"implement only MAYs."  She doesn't want them to go beyond 
the clear compatibility consensus.

The code implementations take on a life of their own ... any 
signals to reduce confusion and tie the implementations 
within some distance of a common goal are good.  A strong 
MAY set is clearly something we should do if we are looking 
for a complete implementation.  In code world, nobody much 
has time to do anything that doesn't lead to a clear 
business imperative.

As a generalism, the people who implement the code know a 
little crypto, but not a lot.  They can't see very far. 
They are employed for their good software skills, their 
ability to turn specs into live code.

What to the crypto / institutional world may be elegence is 
simply code to these guys.  What might be a delicate path 
through conflicting requirements is a nightmare to the 
coders, they just don't know what was intended, and have 
only each other to figure it out.

(Just another reason why agility is a nice idea in the 
crypto tea room, but not robust in reality.)

iang

---

From: "David Crick" <[email-masked]>
Date: Wed, 5 Mar 2008 11:38:19 +0000

On 3/5/08, Ian G <[email-masked]> wrote:
>  understand what the recommendation was.

from my querying of it, I hope it is clear that I would also like
to specifically see the (e.g.) ECC384 curve stated as a MAY.

And, just to justify this (and to show why 4880 is so readable):

9.1.  Public-Key Algorithms
Implementations MUST implement ... SHOULD implement ...
* Implementations MAY implement any other algorithm.*

9.2.  Symmetric-Key Algorithms
Implementations MUST ...  Implementations SHOULD ...
... need to ...  *Implementations MAY implement
any other algorithm.*

9.3.  Compression Algorithms
Implementations MUST ...  Implementations SHOULD ...
... *Implementations MAY implement any other algorithm.*

9.4.  Hash Algorithms
Implementations MUST implement SHA-1.  *Implementations
MAY implement other algorithms.*

>  I'd assume other

---

From: "David Crick" <[email-masked]>
Date: Wed, 5 Mar 2008 11:56:48 +0000

>  spec, thus is MAY. SHA382 is MAY from RFC 4880 and AES256 is SHOULD in

readability and understandability (of our intentions/recommendations)

>  Can using MAY once create questions as to why other combinations are not

possibly, but the reverse it more true: it draws attention to the fact
that *this* is something you should *consider*.

>  algorithm for symmetric message encryption key.)

re the just to be clear, I think this is what has partly muddied the water.

But / so (for my sanity ;)), could you please explain how one uses
a 3DES session key with ECC D-H?

>  In this case we can "tighten" as you suggested.

great.  Again, I'd like to see "clear" wording in the ECC doc to
indicate this; otherwise implementers may either miss this fact
or be left scratching their heads wondering how to handle it.

>  >             key size   |  size  |   key size  |  curve key

just for *me* to make clear :), I was suggesting we add this table into
the spec, just as 4880 does in its.  As you've said, this key management
issue becomes more of an issue as we now have the ability (or the
requirement, with Suite B) to match lengths.   Again, including this,
but spelled out, makes it a lot clearer.

> I will integrate feedback from everybody into the next revision.

I think the ECC spec fits somewhere between 4880 and the Camellia
draft in terms of complexity of detail that is needed to be conveyed.

The Camellia draft is wonderfully short, since all it needs to say is
"this is an alternative cipher you can use.  in limited, certain situations
using Camellia can cause interoperability issues."

The ECC doc, however, has to spell out why and when using this new
public key system would be beneficial, possible ways of using it, the
most suitable ways of using it, and some more complex interoperability
issues.

I therefore feel we need to veer towards using *more* wording to justify
and explain usage of OpenPGP-ECC, rather than (necessarily) aiming
for the "less is more" approach that may be more preferable in general.

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 10 Mar 2008 14:16:07 -0700

Here is the updated revision of the proposal that incorporates most 
requested corrections that was possible to make without breaking or 
severely affecting interoperability.

   http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-7.txt

The same document in other formats:
   http://brainhub.googlepages.com/pgp .

Here is the partial list of changes:

1. Make curve ID 1 MUST, ID 3 SHOULD.
2. MUST SHA2-256 and SHOULD implement SHA2-512
3. Note on Suite-B / OpenPGP incompatibility
4. MUST support ECDSA and and ECDH
5. MDC MUST, MUST use Iterated and Salted S2K
6. Note on matching relative strength specified in section 12.
7. Removed open reference to hashes (removed "or its successor").
8. SHOULD use stronger algorithm, while maintaining RFC4880 rules

Thank you again for your comments.

---

From: "David Crick" <[email-masked]>
Date: Tue, 11 Mar 2008 12:43:48 +0000

11.1 I would like to see "MAY implement curve ID 2" explicitly stated
(this *is* mentioned in section 12, but would like to see it here too)

11.3 says "The best remedy to this .. is to add .. AES-256"

not sure about "best" - perhaps "simplest"?  The reason being is
that as AES128 is an ECC must, then this guarantees us *a* Suite
B acceptable cipher, although - as you're trying to get at - having
AES256 means that we'd cover *both* Suite B profiles.

I'm not sure if I agree with the sentiment of "adding .. to .. each
recipient's key" - doesn't quite sound right?  (Maybe because it
sounds like sender coercion, rather than a higher-level admin
led policy?)

12 "It is generally advisable to list at the head of the preference list
   a symmetric algorithm of strength corresponding to the public key."

Again, I see what you're trying to say, but as is noted elsewhere in
the ECC doc, it's merely the intersection - it's up to the implementation
to make its own decision thereafter (and so take advantage of any
ordering information).

I think section 12 also needs to explicitly deprecate AES-192, saying
that it's not necessarily going to be fielded widely (bring in the fact
that it is only a MAY here might help), isn't one of the Suite B ciphers,
and that it's probably only suitable if for some reason you *really*
need a 192-bit cipher: otherwise go for AES256 for security or -128
for performance.

overall, though, I think we're getting there.

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 17 Mar 2008 02:30:58 -0700

> AES256 means that we'd cover *both* Suite B profiles.

Corrected.

> sounds like sender coercion, rather than a higher-level admin

With the mentioned correction this is one of possible alternatives. It 
is one of cleanest fixes in the sense of standard correctness. I realize 
that it is not a practical fix for the incompatibility. I can't fix the 
keys at at the moment I am sending a message. That's why we should 
mention the importance of proper key preferences in reference to 
relative security.

>    a symmetric algorithm of strength corresponding to the public key."

I watered down this statement to leave that at least the algorithm 
should be there.

> to make its own decision thereafter (and so take advantage of any

As a side note, per RFC4880 this "is an ordered list of octets with the 
most preferred listed firs". If each recipient has the same set of 
symmetric algorithms, shouldn't the intersection remain ordered? I think 
"merely an intersection" is not strictly correct, although I can agree 
with "in practice" or "in most cases" clarification.

> need a 192-bit cipher: otherwise go for AES256 for security or -128

I hope that we find a consensus in not explicitly promoting AES-192 
instead. There are many reasons why mobile/weak hardware devices may 
wish the middle-of-the-road approach with AES-192/ECC-384.

The evidence regarding performance shortcoming of AES-192 is not 
overwhelming.

On http://www.cryptopp.com/benchmarks.html AES/ECB 192 appears even 
faster than 128 in key setup (a measurement aberration, perhaps). The 
data encoding speed is decreasing smoothly for 128/192/256 keys with a 
factor ~1.13.

So is data encoding performance in http://www.linux.com/feature/114024 
for AES 128/192/256 with CBC for both 16 bytes and 8192 bytes. The 
throughput is reduced by a factor ~1.15 as we go to stronger AES.

GnuPG shows gradual slowdown for AES 128/192/256 
http://www.nchelp.org/committees/cl-elec-exch/msg00734.html. The factor 
is ~1.03.

If we were to discourage AES-192, we will need convincing references to 
data that support and explain our choice.

...

The latest version is:
    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-8.txt

The same version in other formats:
    http://brainhub.googlepages.com/pgp

---

From: "David Crick" <[email-masked]>
Date: Mon, 17 Mar 2008 13:10:55 +0000

>  > (this *is* mentioned in section 12, but would like to see it here too)

are you not going to add "MAY .. curve 2" into 11.1?

both Ian and I have requested this, and I have previously
pointed out that for *all* algos (asym, sym, hash) 4880
adds a "MAY implement any other" to the end of each
section (where for ours, there IS only one other, so may
as well be mentioned specifically, i.e. MAY curve 2)

>  > AES256 means that we'd cover *both* Suite B profiles.

great, this is now better.

>  I watered down this statement to leave that at least the algorithm

I *preferred* the original version ("at the head")! ....

>  with "in practice" or "in most cases" clarification.

... I was referring to THIS bit in 4880 (13.2):

"The implementation may use any mechanism to pick an
  algorithm in the intersection."

Thus, while the section you quote (5.2.3.7) is *also* correct,
what 13.2 is saying is "well, there's information you COULD
use, but it's really up to you [the implementation] to pick an
algorithm."

Therefore, I was *happy* with your original wording (and would
prefer to see it re-instatad!), but was just pointing out that it
was only part of the (i.e. [4880] rfc) story.

>  wish the middle-of-the-road approach with AES-192/ECC-384.

For SSL it was decided to just go with AES128 and AES256:

"The AES supports key lengths of 128, 192 and 256 bits.
However, this document only defines ciphersuites for 128-
and 256-bit keys. *This is to avoid unnecessary proliferation
of ciphersuites.*" (rfc3268)

(Similarly, with Camellia added to SSL again only the 128 and
256 length keys were added (rfc4132), again mentioning
that just the 128+256 are being done, despite 192 exisiting.)

With Suite B, NSA have chosen to also just go with 128 and
256, despite the other elements of the larger algo set being
192-equivelent in size.  From their footnote 1:

"CNSSP-15 correctly states that 192-bit AES keys are sufficient
for protecting even TOPSECRET information. However, Suite B
uses only 256-bit keys *to enhance interoperability*."

Our MUST is AES-128, our SHOULD is AES-256.  I think we should
be following the trend in promoting just 128 and 256 bit ciphers,
and by deprecating AES-192 - which we NEED to do with the
stronger Suite B set (perhaps possible the "only" reason to
implement Curve 2, give our MUST on C1 and SHOULD on C3).

---

From: Ian G <[email-masked]>
Date: Mon, 17 Mar 2008 16:20:03 +0100

> wish the middle-of-the-road approach with AES-192/ECC-384.

I agree with David, I personally have yet to see a valid 
engineering reason why one would use AES-192.

Jon has laid out some non-engineering reasons why it should 
be there, and that's a difficult area for us to argue 
against (maybe something Jon and I agree violently over). 
So I guess we are agreed that it should be possible to do 
AES-192 ... but that doesn't mean we should encourage it at all.

AES-128+friends gives a whole lot of security, and that is 
probably enough for most if not every mobile application.

You want more than 128?  Go for the top profile (or go find 
a machine with the top profile).  If your attacker can 
crunch AES-128+friends then we can't possibly recommend 
AES-192 because we just don't know what your attacker is up to.

I like David's skepticism in words, above.  RFC consumers 
who fancy something "a bit better than 128" should be 
discouraged, or understand that they are creating problems, 
they'd better be prepared for the consequences, and the 
community isn't working for them any more.  Deprecated is a 
good scary word.

> data that support and explain our choice.

I see no sweet spot in that data, so I read it as supporting 
the lack of value in AES-192.

iang

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 17 Mar 2008 16:57:00 -0700

> as well be mentioned specifically, i.e. MAY curve 2)

Done.

...

> I *preferred* the original version ("at the head")! ....

Reversed. (Can I be more overzealous in consensus building?).

> was only part of the (i.e. [4880] rfc) story.

OK, the above clears this one.

> that just the 128+256 are being done, despite 192 exisiting.)

TLS does have a problem of explosion of ciphersuites, something that 
OpenPGP doesn't. I recall that one of main technical reasons of 
preferring one Open PGP auth. spec to another in the past was this issue.

> uses only 256-bit keys *to enhance interoperability*."

At the same time, NSA employees submit other curves outside of Suite-B:

http://www.faqs.org/rfcs/rfc4753.html

Plus, a controversial decision to use weaker ECC curve with AES-256...

> implement Curve 2, give our MUST on C1 and SHOULD on C3).

I essentially added what you've asked regarding AES-192. Not outright, 
but with a premise that you and Ian are using, which is, if we see the 
world as divided into "weak" and "strong" systems, "strong" systems 
SHOULD use AES-256.

Thank you.

The latest version is:
    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-9.txt

---

From: "David Crick" <[email-masked]>
Date: Tue, 18 Mar 2008 18:44:09 +0000

On Mon, Mar 17, 2008 at 11:57 PM, Andrey Jivsov <[email-masked]> wrote:
>  > both Ian and I have requested this ...
>
>  Done.

thank you.

>  Reversed.

again, thanks.

>  >>  > I think section 12 also needs to explicitly deprecate AES-192,
>  >>
>  >>  instead.
>  OpenPGP doesn't.

I beg to differ!

We currently have 8 (including patent-encumbered IDEA,
and counting each of the AESes separately) ciphers, and
look like we will be adding a further three Camellias too.

I think that rfc3268's sentiments that I quoted above are
highly admiral, and the decision to add only 128- and 256-
bit Camellia further, and correctly, continues this policy.

>  http://www.faqs.org/rfcs/rfc4753.html

we've *got* three NIST-approved ECC curves for each
of the AES size keys, two of which are Suite B / NSA
approved.

Until there is either a market demand - *or* technical
or security considerations - that would warrant looking
at those other curves, then they're not even on my
radar.

>  Plus, a controversial decision to use weaker ECC curve with AES-256...

You've got this *completely* the wrong way around!!

The flow was:

1. NIST blesses AES for sensitive information
2. NSA says AES128 is OK for SECRET, and 192 *and*
    256 good enough for TOPSECRET.
3. NSA reveals Suite B, including suitable suites for
    SECRET and TOPSECRET use, the TOPSECRET
    cipher being AES256, the other components being
    the lower of *two valid* possible sets for TOPSECRET.

Now, NSA give "interoperability" as their reasoning for
excluding AES192; we can only guess what that means.

But anyway, what they've done is chose *a* TOPSECRET
strength for the public key and hash, and *a* TOPSECRET
cipher. And this is for *Their* use, so it's damned well gotta
be strong enough.

The *fact* is that the cipher is *stronger* - *not* that
they've "picked" a weaker hash/public key curve.

(And in fact up until now in PGP we've generally had higher
strength ciphers compared to public keys (2.6 with 128 IDEA
and 2K max, PGP5+ with 4K max and 256-bit AES/Twofish).)

So I don't think your argument holds, and if anything
actually *supports* AES256 over AES192.

But anyway...

>  world as divided into "weak" and "strong" systems, "strong" systems

I'm not quite happy with the wording - I think it needs to be more
"against" - plus, by having a single, clear sentence or two that
simply states:

  "please note, use of AES192 is deprecated.  You should only
  consider using it if you have very specific requirements."

would actually cut out a *lot* of our current "advisory verbiage."

*But*, having at least got *some* sort of wording into the draft
about AES192, I'm *somewhat* "placated" - even if I'd (still)
prefer it stated more strongly (*and* simply!).

But anyway (again)...

>  Thank you.

And again my thanks to you too - for helping us to bring ECC
to PGP.  I just want to try and do it in the best way possible!

I *still* think that some of the "security recommendations"
should be liberally sprinkled directly into each of the specific
algorithm sections.  This would make each section more
readable in its own right, and would enable us to convert
section 12 into a more general guidance section, rather than
how it is now, with guidance *and* specific recommendations.

However, it's your document!, and you've already stated that
you feel that it would be better the way you've structured it.

I really do think we've pretty much got the technical/application
level stuff fairly well hammered out now, and that's it's near to
the consensus [conflicting opinions ;) ]  that we're aired.

So from my point of view I think it's just honing the language
and structure of the document that remains - seeing if we can
more clearly and concisely put it across.

4880 is a highly readable RFC; I'd like to think we can make
the ECC document just as consumable.

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 19 Mar 2008 23:52:03 -0700

David Crick wrote:
...
>>  TLS does have a problem of explosion of ciphersuites, something that

I meant the space exhaustion. 4 dimensions DH/public alg/symm.alg/hash 
alg got some people worry about depletion of 16K space. There is no 
comparable problem faced by OpenPGP.

> bit Camellia further, and correctly, continues this policy.

I never disagreed with benefits of eliminating as many options as we 
can. This goal is high on my list. The performance of AES-256 is not the 
bottleneck for most of applications that run on PCs and servers, which 
are bound by IO or public key crypto in realistic applications.

> they've "picked" a weaker hash/public key curve.

It's a valid view angle. That's probably how AES-192 was "upgraded". So 
is another one -- ECC-521 is missing from Suite-B that is needed to 
perfectly match Suite-B symmetric algorithm today. Going forward, it is 
the public key algorithms that "age" faster than symmetric algorithms as 
processors get faster and mathematicians smarter. My use of "weaker" was 
in this forward looking meaning.

> would actually cut out a *lot* of our current "advisory verbiage."

I wish we had mobile/smartcard people voice their opinions, since
AES-192 is for them. It is hard to advocate on their behalf, because 
once you go down the path of less processing power, the diversity of 
systems increases (use diversity of smartcards as a proof).

Nonetheless, for what a generic statement is worth, suppose AES-128 was 
X dollars (or cents?) cheaper than AES-256 to support in a given device 
and a vendor chose AES-128 only. If for whatever reason AES-192 or 
better must now be supported, the vendor's choice is to accept X/2 extra 
cost for AES-192 or X for AES-256. Will X/2 saving achieved with AES-192 
matter for mass-produced devices like smartcards? Probably. The support 
for AES-192 is not an issue for this vendor, because another side is 
likely more capable system that implements every AES algorithm.

( I assumed above that crypto throughput scales proportionally for AES 
128/192/256, as my previous email indicates, and that the cost per unit 
is likewise proportional ).

> prefer it stated more strongly (*and* simply!).

That's a great relief, David. I will continue to think about how to make 
it closer to what everybody has requested.

> to PGP.  I just want to try and do it in the best way possible!

I appreciate your comments, as well as anyone else's. That's not the 
last time I say thank you, of course.

> more clearly and concisely put it across.

I put more weight on succinctness. This often goes against clarity. I do 
have preference against redundancy. In any case, I would appreciate 
suggestions on how to improve readability.

> the ECC document just as consumable.

Assuming we agree on technical details/options, is there interest in 
test vectors? Some methods, such as those used with ECDH, are 
parameterized uniquely, leaving implementers will no reference to check 
their code. Test vectors will help mitigate the concern of the multitude 
of options; this will increase the speed of adoption and reduce bugs. It 
may delay the progress of the document and put more burden on author(s). 
Alternatively, test vectors can be posted elsewhere. What does the group 
think about the value/route in this respect?

Thank you.