Subject: I have a technical idea/change for the ECC draft

From: "David Crick" <[email-masked]>
Date: Sat, 12 Apr 2008 22:21:52 +0100

"11.3. Interoperability with Suite-B profile" currently states:

   "If TripleDES is the only shared algorithms for a set
   of recipients, no Suite-B compliant recipient can be added to the
   mentioned recipient set."

but doesn't state how this may be enforced by the *recipient*
(who may not currently have a way of specifying this to the
sender).

I therefore have a suggestion:

implement a key-packet preference flag that says "strict SuiteB"

If this is set, then applications MUST NOT use any other cipher
other than one of the allowed AES sizes for that ECC key size.

This will allow us to disallow 3DES (and any other non-AES cipher)
by setting this key flag.

Independent of this, an application may additionally have an
--enforce-suiteB flag/checkbox

thoughts people?

(as an aside, re my "editorial [readability] changes," I might be
able to sit down and have a go at them on Monday or Tuesday.)

---

From: Ian G <[email-masked]>
Date: Sun, 13 Apr 2008 12:48:21 +0200

>    mentioned recipient set."

I had to look at all of 11.3 to try and make sense of this, 
and found that whole subsection to be hopelessly confusing. 
  Can we have a simple statement as to whether an 
OpenPGP-ECC key can be used with TripleDES or not?  Can 
messages be mixed-mode or not?

It seems to me that if an application creates and exports an 
OpenPGP-ECC key (only) then that public key cannot be used 
with TripleDES, as the document does not suggest it anywhere 
(and implies it is ruled out).  Which means there should be 
a specific claim that this ECC draft overrules the 
"guarantee" of TripleDES intersection in RFC4880.

(To me, this seems like a reasonable price to pay to get a 
good, clear result.)

Alternatively, there should be a specific claim permitting 
use of TripleDES and describing how/what.

(I should note that I do not recall the discussions of a few 
months back.  This should be a "good thing" because it 
allows me to view it as a first time reader.  My routine 
excuse is that if I can't understand it from a simple 
reading then I suspect we are putting an unnecessary burden 
on first time readers, but not many agree with that!)

> (who may not currently have a way of specifying this to the

Personally, I would have said that the recipient should 
reject the message with an error.  If there is a mixed mode 
message, then the sender is in error, allowing for a 
potential attack.  We might not be able to stop the attack 
through a misbehaving client, but we should red-flag it when 
we see it.

(but I've not seen the full sense yet, I may be wrong.)

(Apps have these flags to decrypt even when there are errors 
in modes, so that's ok.)

> --enforce-suiteB flag/checkbox

these complexities will roll forward in history :( ...

iang

---

From: "David Crick" <[email-masked]>
Date: Mon, 14 Apr 2008 19:26:34 +0100

>  However, I do see the benefit of a feature. If it were to make into the
> document I suggest to make it more generic and not Suite-B specific. The
> following alternatives achieve the same what Davit proposed but are easier
> do understand:
>
>  * this key has no implicit default algorithms
>  * this key replaces 3DES implicit algorithm with AES-128

This second one (AES-128 replaces 3DES) *really* appeals to me.

It should also further appeal to resource-constrained environments,
where (therefore) not having to implement (or use) 3DES would be
a bonus.

Actually, maybe we need to add / reconsider having a section
in the ECC doc that says

"if AES-128 is not explicitly in the set of preferred algorithms, then
it is implicitly added at the end.  If neither AES-128 or 3DES are
explicitly listed, then both of them are implicitly added, with 3DES
last."

NB, this is weaker than the idea of a "strict suiteB flag" (my original
proposal), and slightly weaker than your "AES128 replaces 3DES."

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 14 Apr 2008 11:14:16 -0700

You are saying there there is no way to remove 3DES from the set of
algorithm preferences, since it is implicitly there per RFC 4880.

If a key has {AES-128, AES-256} as a preference list, right now it is
effectively {AES-128, AES-256, 3DES}.

And I think it follows that the only logical intended action that your 
proposal seeks is to break the transmission if one of recipients is an 
ECC key that disallows 3DES, *if* 3DES is the only shared algorithm for 
the given set of recipients per RFC 4880.

It is possible to keep this feature limited to the mode of operation of 
the software (a command line option --cipher-algo, UI element, etc), 
v.s. making it depend on the attribute of a key.

This assumes that both sides "agree" to use the Suite-B profile. This is 
usually the case. Many other criteria must be met in order to be in 
highly regulated Suite-B profile, especially for Top Secret or 
classified category. These additional requirements include the type of 
authentication to local keys (which AFAIK must be hardware protected 
path authentication).

However, I do see the benefit of a feature. If it were to make into the 
document I suggest to make it more generic and not Suite-B specific. The 
following alternatives achieve the same what Davit proposed but are 
easier do understand:

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 14 Apr 2008 11:42:57 -0700

Ian G wrote:
> I had to look at all of 11.3 to try and make sense of this, and found 
> that whole subsection to be hopelessly confusing.  Can we have a 
> simple statement as to whether an OpenPGP-ECC key can be used with 
> TripleDES or not?  Can messages be mixed-mode or not?
OK, the suggestion noted. The support for TrippleDES follows from RFC 4880.

> OpenPGP-ECC key (only) then that public key cannot be used with 
> TripleDES, as the document does not suggest it anywhere (and implies 
> it is ruled out).  Which means there should be a specific claim that 
> this ECC draft overrules the "guarantee" of TripleDES intersection in 
> RFC4880.
>
The quote above is an example.  It has an "IF" in it. I didn't imply in 
11.3 to rule TrippleDES out.
> (To me, this seems like a reasonable price to pay to get a good, clear 
> result.)
I think it is important that new keys seamlessly integrate with existing 
keys and deployed applications. It's a good cause to allow 
non-government users to increase the strength of their public keys at 
lower cost that ECC provides.

We have similar issue with FIPS.
>
> Alternatively, there should be a specific claim permitting use of 
> TripleDES and describing how/what.

I will add an assertive statement about TrippleDES.

> (I should note that I do not recall the discussions of a few months 
> back.  This should be a "good thing" because it allows me to view it 
> as a first time reader.  My routine excuse is that if I can't 
> understand it from a simple reading then I suspect we are putting an 
> unnecessary burden on first time readers, but not many agree with that!)
>
>
> Personally, I would have said that the recipient should reject the 
> message with an error.  If there is a mixed mode message, then the 
> sender is in error, allowing for a potential attack.  We might not be 
> able to stop the attack through a misbehaving client, but we should 
> red-flag it when we see it.
>
> (Apps have these flags to decrypt even when there are errors in modes, 
> so that's ok.)
>
>
I agree. When Suite-B profile is involved user may not be able to send 
out (encode). Splitting a message into two, one using 3DES and another 
one using AES, is not an option. Depending on how the discussion about 
choosing the Suite-B goes (key or software?), I will add stricter 
statement about the the failure on the sender's side.

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 14 Apr 2008 12:00:54 -0700

> proposal), and slightly weaker than your "AES128 replaces 3DES."
I find implicit rules of the RFC 4880 controversial. They could have 
been like this: if there is no encryption keys preferences, only then 
3DES is implicitly present. That is, it would be limited to old keys. I 
would favor explicit rules, if possible.

Besides, even without this thought, I don't see how your latest proposal 
gives an ECC public key holder a mechanism to block transmission with 
3DES (because 3DES sneaks in as an alg. for ECC keys, it may be chosen 
by the sender).

---

From: "David Crick" <[email-masked]>
Date: Mon, 14 Apr 2008 20:11:19 +0100

> gives an ECC public key holder a mechanism to block transmission with 3DES
> (because 3DES sneaks in as an alg. for ECC keys, it may be chosen by the
> sender).

my point was that if we have a key preferences flag on the
key, then this is an instruction to the sender's software, i.e.
"strict suiteb ciphers only" - in other words, don't use 3DES.

---

From: Jon Callas <[email-masked]>
Date: Mon, 14 Apr 2008 12:40:39 -0700

I don't think this is a bad idea at all, but I also think I should  
bring up something that Jeff Schiller made clear to me years ago, and  
that's the difference between mandatory-to-implement, and mandatory-to- 
use.

In this group, we create what are legislative systems. There are also  
market systems, and we cannot create those. Let me give two examples.

As a result of various decisions made at the 1997 Munich IETF, there's  
broad "MUST" requirement of Discrete Log PK Crypto and 3DES for  
symmetric. This was an artifact of the patents for Discrete Log  
expiring in 1997, and the RSA patents expiring in 2000. However, in  
the X.509 certificate world, you will almost *never* see a DSA  
certificate. I have heard it said that there have been no DSA  
certificates created in the real world, only ones needed for "interop"  
testing for the "mandatory" algorithm.

Quibble with this if you want, but it's still true that in the real  
world there are only RSA certificates, despite RSA being an *optional*- 
to-implement algorithm.

Similarly, I would expect that in the OpenPGP world, you'll now see  
little to no use of 3DES. Mostly, you'll see AES. I have no supporting  
facts for my expectation, but I'd bet a beer on it.

In these cases, market trumped legislation. In the RSA case, people  
agreed to the political discrete log compromise, and then went on  
doing what they'd been doing -- using RSA. In the AES case, AES has  
replaced 3DES in the real world through organic growth.

So here's what we can do:

* I like David Crick's suggestion of a preference that says, "I'm  
going to be strict about Suite B." This is a legislative solution, and  
it would work well, it's simple, and elegant. End of story.

* Test, for interop purposes, 3DES with Suite B. But as an  
implementor, *don't* *do* *it*. This is similar to what they did with  
DSA in X.509. As an implementor, don't do anything other than strict  
Suite B. Don't put it in the UI, don't give any options. Just do Suite  
B. If you don't like this, you could do what David Crick suggested,  
but with reverse polarity. I mean that instead of having an "--enforce- 
suiteB" option, you have a "--loose-suiteB" option that you have to do  
to allow anything that's not strict.

Note that these are not exclusive. You can do both. There can be a SSB  
preference, and if enough people do it by default, then there's no  
issue. Even better would be for implementations to just not offer an  
alternative.

	Jon

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 14 Apr 2008 13:39:36 -0700

> it would work well, it's simple, and elegant. End of story.
I think that there is implicit assumption here that "Suite-B" and "only 
AES" are synonymous for this discussion, but clearly, only one of these 
terms is crystal clear while another one is not.

As it stands right now, Suite-B is vaguely defined, thus there will be a 
lot of questions as to what that Suite-B key is. What do we loose if we 
instead use "this key replaces TrippleDES implicit algorithm with 
AES-128" notation? This would be beneficial for RSA keys too.

---

From: "David Crick" <[email-masked]>
Date: Mon, 14 Apr 2008 22:23:51 +0100

> lot of questions as to what that Suite-B key is.

No, Suite B is very clearly defined:

384 ECC, 384 SHA hash, AES256 ("TOP SECRET")
256 ECC, 256 SHA had (384 also OK), AES128 (AES256 also OK) ("SECRET")

Our "problem" is that we are trying to layer an *ECC* spec
(of which Suite B is a *sub-set*, with specific restrictions)
on top of RFC4880.

Because of that, our "ECC OpenPGP" allows use of 3DES,
but this conflicts with the AES-only nature of the Suite B
subset of our ECC spec.

> What do we loose if we
> instead use "this key replaces TrippleDES implicit algorithm with AES-128"
> notation? This would be beneficial for RSA keys too.

what if we have:

Alice: {AES256, AES128, AESover3DESflag [, 3DES implicitly]}
Bob: {3DES [, AES128 implicitly]}

Then Bob or his software could legitamately choose 3DES.

whereas:

Alice: ECC-384/521 key with {AES256, SuiteBOnly}  and
Alice: ECC-256 key with { [AES128 implicit], SuiteBOnly}

would refuse to encrypt with anything except AES256 and
AES128 respectively.

(NB, we're going to hit the same thing with the hash when
- and I use "when" optimistically - Whirlpool gets added; a
SuiteB flag on the key would only allow the correct-sized
SHA2.

NB#2, I'm not entirely sure what "suiteb only" flag means if
you try to encrypt to an ECC key and a non-ECC key?)

---

From: "David Crick" <[email-masked]>
Date: Mon, 14 Apr 2008 23:33:35 +0100

>  it would work well, it's simple, and elegant. End of story.

are you referring to a "key" or "application" preference (or both?!)

>  * Test, for interop purposes, 3DES with Suite B.

sounds sound

>  If you don't like this, you could do what David Crick suggested,
>  Note that these are not exclusive. You can do both.

So are you saying we have:

o Strict Suite B key flag ("legislative"; allows recipient to specify strongly)

*plus* (potentially out of scope of the [legistlative] spec?)

o an --enforce-suiteB application flag (self-evident)
o a --loose-suiteB application flag (but can it override a key-flag? - or
are you using this instead of a keyflag)

>  Even better would be for implementations to just not offer an
>  alternative.

yes!

If all applications were to by default add AES (one or both) to
the head of any ECC generated keys, *and* prefer AES over
3DES as implicit, *but* still be able to "understand" messages
that are encrypted by non-AES ciphers.

---

From: Jon Callas <[email-masked]>
Date: Mon, 14 Apr 2008 19:22:56 -0700

> are you referring to a "key" or "application" preference (or both?!)

I was thinking a signature subpacket of some sort. That's a "key"  
preference. Strictly speaking, OpenPGP is a data protocol, and doesn't  
define applications preferences any more than SMTP tells you how to  
set up your sendmail or postfix conf file.

Any application-level things are beyond the scope of this group.

> are you using this instead of a keyflag)

I'm saying that I like the idea of a legislative solution. However, it  
would be reasonable for us to punt the legislative issue.

We did this with DSA/DSS. If you want to be strictly FIPS, you always  
use DSA with SHA-1, etc. and that gives you DSS. If, however, you look  
askance at SHA-1, you can use DSA with RIPE-MD/160. There are explicit  
and implicit issues with that, but you can do it within 4880.

We could similarly just not worry about it. Let the implementers  
handle it. Thems what care about strict-SB can implement it the right  
way.

I like the legislative solution, but I prefer doing nothing and  
letting the implementers handle it. This is a style issue. I believe  
that a standard exists for interoperability, and to make sure you  
don't end up with two implementations that *cannot* talk to each  
other. Beyond that, I am a minimalist. A standard is not a how-to  
guide for an implementer.

I were an implementer, I would not generate a "loose-Suite-B" message,  
*ever*. I'd decrypt them, but I wouldn't give my users the option to  
create them.

> that are encrypted by non-AES ciphers.

Frankly, I believe that an application should prefer AES or Twofish  
over 3DES, period.

Note that 4880 *explicitly* says that you take the intersection of  
Alice's and Bob's preferences and resolve them any way you see fit. It  
is acceptable for an implementation to use 3DES only when nothing else  
exists. It's acceptable for an implementation, thus, in Suite B, to  
always be strict. (To do Suite B, you have to have AES as an option.)

That's the way I'd do it. I'd do it in the code, not in the standard.

However, I realize that not everyone has my matters of taste, and so  
therefore, I support the legislative solution. I just prefer not  
worrying, as it's less work here.

	Jon

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 15 Apr 2008 18:32:08 +1200

Jon Callas <[email-masked]> writes:

>I have heard it said that there have been no DSA certificates created in the
>real world, only ones needed for "interop" testing for the "mandatory"
>algorithm.

There are DSA certs created for USG use but they're from a parallel universe
where X.509 PKI works just fine, people still send X.400 email, and everything
is predicated on the X.500 Directory, so I don't think it's a good
representative example :-).

Peter.

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 15 Apr 2008 00:06:01 -0700

> guide for an implementer.

I favor this too.

One additional issue I realized that we didn't address is the mixing of 
keys for two levels of Suite-B profile. It is similar to the issue of 
mixing non-Suite-B and Suite-B keys.

TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We 
cannot make TOP SECRET keys use AES-128, yet this is what happens with 
implicit AES-128. Making AES-256 implicit will not work either, because 
now SECRET keys will be picked as compatible with TOP SECRET keys. 
Finally, having no implicit preferences disallows TOP SECRET keys to 
receive SECRET information.

Do we now need two Suite-B flags?

---

From: Jon Callas <[email-masked]>
Date: Mon, 14 Apr 2008 23:55:10 -0700

> representative example :-).

Which is precisely my point. They are the mandatory-to-implement, but  
they exist with Bizarro Superman.

	Jon

---

From: "David Crick" <[email-masked]>
Date: Tue, 15 Apr 2008 11:29:25 +0100

> keys for two levels of Suite-B profile. It is similar to the issue of mixing
> non-Suite-B and Suite-B keys.
>
>  TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We cannot
> make TOP SECRET keys use AES-128, yet this is what happens with implicit
> AES-128. Making AES-256 implicit will not work either, because now SECRET
> keys will be picked as compatible with TOP SECRET keys. Finally, having no
> implicit preferences disallows TOP SECRET keys to receive SECRET
> information.
>

My initial reaction was "no": one flag restricts ciphers for both
profiles (TS and S) - and that's absolutely correct for "Suite B."

But "OpenPGP ECC" possibly has several categories (levels):

1. Strict Suite B TS
2. Strict Suite B S
3. ECC with AESes
(3a ECC with Twofish, Camellia)
4. ECC with 3DES
(4a ECC with Twofish, Camellia if you think 3DES is higher)
5. ECC with other ciphers / non-ECC keys

but maybe this is now into the realm of cipher preferences?

I need to give this a bit more thought.

---

From: "David Crick" <[email-masked]>
Date: Tue, 15 Apr 2008 11:12:23 +0100

On Tue, Apr 15, 2008 at 3:22 AM, Jon Callas <[email-masked]> wrote:
>  preference.

good.

>  Any application-level things are beyond the scope of this group.

again, this is what I was expecting.

>  *ever*. I'd decrypt them, but I wouldn't give my users the option to

I agree with you on all the above.

>  Frankly, I believe that an application should prefer AES or Twofish

It's what NIST says (of AES and 3DES; AES is the FIPS, while
3DES has been downgraded to a Special Recommendation).

NSA's blessing of AES (first for classified usage, and then an
even stronger endorsement through Suite B) as far as I'm
concerned is a very clear signal.  In fact, Suite B itself (and I
include SHA2 here, despite people's misgivings given SHA1)
is a strong signal about "what" we (crypto implementers)
should be doing - and why I've been pushing for us to focus
on Suite B (and AES with it) when looking at OpenPGP ECC.

>  always be strict. (To do Suite B, you have to have AES as an option.)

yes, although there *is* a section in 4880 that says about
the preference listing being ordered.  The two things together
*aren't* incompatible; rather they say, together, that here's
some information you *could* use, but really it's up to you.

>  therefore, I support the legislative solution.

I think the legislative solution should give clear enough
guidelines to the implementers about what they should
be doing!

---

From: Ian G <[email-masked]>
Date: Tue, 15 Apr 2008 14:25:06 +0200

A high level / managerial perspective.  Apologies in advance 
for where it drifts from actual specifications.

We are deep down the rabbit hole known as

     _profiles v. algorithms_

It is worth standing back and thinking about this because 
when V5 keys are looked it, it is possible that we could 
solve this.

PGP was designed in the early 90s when algorithms were 
thought to be all there was to crypto.  Now, we know that's 
wrong [1].  Now, we know it is all about applications and 
users, and they want communication before security, and 
security before crypto.  From a crypto standpoint, profiles 
are the only way forward, because they remove 
interoperability issues, which improves communications.

But, still, today, OpenPGP prefers to indicate algorithms 
not profiles, so what to do?

1. Leave it entirely out of the ECC document and let the 
implementors discuss it.  The problem with this is as 
highlighted by the Willmer/Laurie case.  They apparently had 
to backtrack from their "cleanroom dox" implementation and 
go find info that was "shared" not written.  So we are 
adding in an additional drag on the implementors.

That's fine if you believe that all implementors should talk 
anyway, but not so fine if some only talk in Chinese and 
others have poor social skills and good code is downloadable 
from sourceforge.

2. "legislative" position in the ECC document.  Something like:

    OpenPGP-ECC has no implied preference,
    and explicitly drops the TripleDES implied preference
    of RFC4880.  Each algorithm must be expressed.

    The existance of preferences AES-128 and AES-256 only
    MAY be taken as a signal that Suite-B is required.

Or somesuch.  Plus side might be that it might mean less 
interop testing and less code.  That would be a big win for 
ECC coders in the mobile field, as they could get a single 
tight profile.

Minus side might be that it might be ignored.  Or, it might 
not, if we choose carefully.  If it is ignored, we've lost 
nothing.  If it is followed, then we've won.

3. "Security Notes / Comments" to the effect that the world 
has moved on and implementations should avoid using the old 
stuff.  Something like:

   Although RFC4880 includes TripleDES as an obligatory
   and common algorithm, this algorithm is out of date.
   Implementors are likely to limit TripleDES to
   interoperability testing only, and application
   developers are likely to not offer TripleDES, or
   offer it under override conditions only.
   Implemetors should follow the profiles
   suggested in Suite-B.

This means that implementors still have to write TripleDES 
code and still have to interop test it.  But application 
developers can ignore it.

4.  Two Key flags to specify Suite-B (S + TS) as suggested 
by Andrey.  This in effect adds profiles.

If we can do this for Suite-B, we can do it for RSA and 
other things.  Consider a Suite-RSA "for the rest of us":

     Secret:     AES-128, RSA-3072, SHA256
     TopSecret:  AES-256, RSA-8192, SHA512

But this might be better off being left for V5?  Dunno.

iang

[1] This is not a new mistake.  Kherdkoffs wrote about it in 
1883.

---

From: Jon Callas <[email-masked]>
Date: Tue, 15 Apr 2008 14:01:07 -0700

> some information you *could* use, but really it's up to you.

Exactly. The two things are there and it's by intent. You say what  
your preferences are in order, and I take them under advisement.

> guidelines to the implementers about what they should

I disagree only in that I'd change "should" to "must." :-) Should is  
opinion, must is fact. There's always someone who has to deviate from  
the best path for reasons we cannot fathom.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Tue, 15 Apr 2008 14:08:29 -0700

On Apr 15, 2008, at 5:25 AM, Ian G wrote:
>
> A high level / managerial perspective.  Apologies in advance for  
> where it drifts from actual specifications.
>
>
>
> It is worth standing back and thinking about this because when V5  
> keys are looked it, it is possible that we could solve this.
>
> PGP was designed in the early 90s when algorithms were thought to be  
> all there was to crypto.  Now, we know that's wrong [1].  Now, we  
> know it is all about applications and users, and they want  
> communication before security, and security before crypto.  From a  
> crypto standpoint, profiles are the only way forward, because they  
> remove interoperability issues, which improves communications.
>
> But, still, today, OpenPGP prefers to indicate algorithms not  
> profiles, so what to do?

 From here, nothing. This is layering. At the bottom layer, there's  
the algorithms, as you note. A layer up from that you get profiles.  
The profiles can either be implicit in the implementation, or they can  
be explicit in some standard.

I would actually say that there's the raw algorithm (like AES), the  
extended algorithm (like CFB), and the protocol (like OpenPGP). Above  
that, as you note are the profiles. This isn't even a Kerchoff issue,  
it's a systems engineering and design issue. If you don't give the  
implementers liberty, they can't do cool things no one else thought  
of. If you give them too much liberty, they write crap. Between those  
two problems is wisdom.

I have no personal interest in making profile documents. I support  
other people who have such interest. The profiles do exist, however.  
They're just implicit in the application.

I think it's better for ECC/SuiteB to have them implicit. But if  
someone else wants to do the work, sure.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Thu, 17 Apr 2008 09:01:58 +0200

> it would work well, it's simple, and elegant. End of story.

I support this.  

However the preference should not reference another document but
explicitly list the restriction.  There may be an explanatory note
indicating that this is identical to Suite-B.

Please recall that OpenPGP is not a national standard.  If more
provisions for an US standard go into OpenPGP other countries may want
to see their own rules in there too.  To avoid such attempts I believe
it is better to have a more neutral language.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

---

From: Jon Callas <[email-masked]>
Date: Thu, 17 Apr 2008 11:10:39 -0700

> it is better to have a more neutral language.

Hear, hear!

This is one reason why I believe in options. If someone wants to do  
SuiteB ECC but with Camellia and Whirlpool, we should not be  
restricting that at the standards level.

NIST deserves kudos in the way they did AES, and the way that SuiteB  
navigates the rocks of an effective ECC suite. But I agree with  
Werner, we are a transnational organization.

	Jon

---

From: "David Crick" <[email-masked]>
Date: Thu, 17 Apr 2008 19:29:01 +0100

>  restricting that at the standards level.

there is no such thing as "SuiteB ECC but with Camellia and Whirlpool"

Suite B *is*:
384-ecc, sha384, aes256 - cleared for up to TOP SECRET use
256-ecc, sha256, aes128 - cleared for up to SECRET use

with both also being suitable for non-classified (sensitive) use.

What you *could* have is "_OpenPGP ECC_ with Camellia and
Whirlpool _at equivelent strength to the SuiteB cipher suites_"

---

From: Derek Atkins <[email-masked]>
Date: Fri, 18 Apr 2008 20:16:36 -0400

Hi David,

> there is no such thing as "SuiteB ECC but with Camellia and Whirlpool"

True...  However...

> Whirlpool _at equivelent strength to the SuiteB cipher suites_"

I think the point is that at the protocol level there doesn't need to
be a major difference.  At the APPLICATION you can say "we support
suite B" and when you create keys you say "sha384/aes256" with an
ECC-384 key and "sha256/aes128" with an ECC-256 key...  But someone
else could say "camellia/whirlpool" with an ECC-384 key.  

In other words the OpenPGP protocol (and packet formats) should remain
agnostic about the semantics of the ciphersuites being allowed or
proposed in the notation on a key.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant