On 2/29/08, Andrey Jivsov <openpgp(_at_)brainhub(_dot_)org> wrote:
I think that the scope of ECC document is not to define the perfect
combination of symmetric algorithm/hash/public key algorithm. The issue
of relative strength applies equally well to RFC 4880. We should discuss
the relative strength issue and how the ECC fits into this and we can
recommend certain combinations, but should avoid mandating exact
permutations. These combinations are not permanent and subject to
opinions, mostly because of public key component. Balanced today
AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future.
We have guidelines from NIST and NSA on current balanced
strengths. Suite B in particular is very specific (selective).
(Yes, it has its higher cipher size oddity, but thems the rules.)
Let's also not forget about the issue of encoding to multiple
recipients. Remember that the message gets encoded to a single symmetric
key. "Walking up" from this algorithm, which may be other than AES (in
fact, the 3DES is the fallback default), we may legitimately end up with
pairs of symmetric/public tupples that don't match the "perfect"
profile. In other words, if we have two recipient keys:
ECDH public key symm. alg
--------------------------------------------
P-256 AES-128, CAST5
P-521 AES-256, AES-128
RFC 4880 mandates that we use AES-128/P-521 for the second recipient. In
some cases we cannot "insist" on using a particular algorithm.
I think the best way to add longevity to this document is to pick up a
few core permutations and then make its *components* MUST. In
particular, there seem to be consensus on Curve ID 1 as MUST. I also
have curve ID 2 as MUST for OpenPGP, which gives some room to shuffle
the tupple. I also put SHA256 and SHA384 as MUST. I am OK with relaxing
this to Curve ID 2 and SHA384 as SHOULD for OpenPGP profile. It is
SHOULD and not MAY because of multiple recipient issue (if it is MAY to
generate P-384, it is effectively MUST to be able to encode to it).
So far we have erred towards [128-]256-256 as a MUST because
of low spec devices. However, someone on here (I think it was)
was complaining that they couldn't even use AES-128 on a small
Nokia (and so were using RC4) - so there's already examples of
OpenPGP being, um, "adapted" to fit needs.
With DSA in OpenPGP we're making public key and corresponding
hash size restrictions (at least for DSS compliance), so why not
for the cipher with ECC? (which Suite B does).
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.
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.
As has probably been apparent, I'd like to see "OpenPGP-SuiteB";
just two curves, hash sizes, ciphers and public key algorithms,
with AES256 used in the event of both small curve and big curve
recipients. (Maybe if we're also communicating with a non-ECC
key person then we "force" one of the AESes over 3DES. Or just
say we can't communicate if they don't have an AES preference.)
Heck, I'd be all for making this into a "V5 key" thing and getting
rid of SHA1 and 3DES completely and all the other things we've
talked about.
Suite B really is the closest to Ian's "one cipher system" (albeit
with two of everything!). My initial suggestion was to make the
AES256-SHA384-ECC384 as the MUST, since that's the stronger
(and since we already have AES128-SHA256-DSA2_RSA_ElG3K
strength in OpenPGP). If some people can't use AES128 on
small systems *right now* then this doesn't change anything for
them.
David Crick wrote:
> On 2/29/08, Ian G <iang(_at_)systemics(_dot_)com> wrote:
>
>> David Crick wrote:
>>
>> > How hard-coded do we want/need to make the[se] cipher-hash-curve
>> > combinations? For Suite B compatibility/marketability we need
>> > them "fixed" (especially in light of pointing out the higher
>> > relative MAY cipher size) and the hash fixed as SHA2 (as opposed
>> > to, say, a hypothetical Whirlpool; SHA3 could be added later).
>>
>> Me: hardcoded. Nobody ever showed that SHA wasn't good
>> enough for the job and NIST/NSA is happy with it, until 2012.
>>
> ...
>
>> If the Europeans want to propose a EuroSuite, let them.
>> Let's not jump on the bandwagon and make the profile
>> all-things-for-all-humanity.
>>
>
> I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2.
>
> *I* would also be 100% happy fixing the cipher sizes with only AES.
>
> *However*, are we ( <waits for other people to pipe up> ) willing to
> insist that for OpenPGP ECC you *absolutely* MUST use AES *and*
> at these specific sizes for the corresponding algorithm sets below?
>
> MAY implement ECC
> o MUST implement AES128-SHA256-256ECC
> o SHOULD implement AES256-SHA512-521ECC
> o MAY implement AES256-SHA384-384ECC
>
>
> Aside from the side-effect of 4880 (and predecessor's) 3DES MUST,
> this would be the first time that we are mandating specific cipher
> usage. We're not saying "SHOULD" (and WARN the user if they do
> otherwise), we're saying MUST. (A watered-down compromise would
> be to say "for Suite B compliance, AES MUST be used," just as we've
> said for DSS compliance SHA must be used [and at certain sizes]).