Re: [openpgp] draft-ietf-openpgp-pqc ECC-based KEMs vs RFC 9180 DHKEM

[Simon Josefsson <[e-mail]>]

Aron Wussler <[e-mail]> writes:

> Hi Simon,
>
> The logic in the draft is similar to the one existing in the
> crypto-refresh [1, 2], just using SHA-3 instead of HKDF.
> We chose plain SHA3 over HKDF with SHA2 because it's shared with the
> key combiner.

Hi Aron.  Understood - so no strong cryptographic problem with
HPKE-DHKEM, but chosen to lower implementation code size at the expense
of a higher specification complexity, if I understand/summarize
correctly.  I can sympatize with a tradeoff like that, it is subjective
what to optimize for.

Would it make sense to describe this ECC KEM in a separate document and
register it as a proper HPKE KEM?  See
<https://www.iana.org/assignments/hpke/hpke.xhtml>.  Doing so would:

1) Make it easier to analyze your ECC-KEM on its own by people who
doesn't (have to) know anything about OpenPGP.  Which may increase
confidence in the construct.

2) Allow for possible re-use in other protocols with similar needs.

3) Shorten the openpgp-pqc document to not have to specify ECC-KEM.

4) Reduce complexity of openpgp-pqc -- when reading this, I was asking
myself if there is something in your ECC-KEM that is strongly
cryptographically related to the rest of OpenPGP-PQC.

5) Reduce the amount of cryptographically sensitive algorithms that are
standardized by each application protocol WG, which seems like a
wortwhile goal on its own.

One disadvantage is that we will then get another KEM in the ecosystem,
which has a cost, but that will happen anyway if this KEM is defined in
openpgp-pqc without being registered and reviewed as a HPKE KEM.

Alternatively, simply use already specified DHKEM from RFC 9180.  That
may lead to slightly larger code size, but if people are using general
purpose crypto libraries to implement openpgp-pqc, I don't see any
general purpose crypto library not including SHA2/HKDF.  Aren't
SHA2/HKDF required by other parts of any OpenPGP implementation?

/Simon

> It's still a provisional choice, and feedback is welcome! I just sent
> on Saturday the thread on Signatures, and will soon follow up with KDF
> and key combination.
>
> Cheers,
> Aron
>
> [1]
> https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-13.html#section-5.1.6
> [2]
> https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-13.html#section-5.1.7
>
>
> --
> Aron Wussler
> Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
>
>
>
> On Saturday, 17 February 2024 at 16:10, Simon Josefsson <simon=[e-mail]> wrote:
>
>> Hi
>>
>> I am reading about OpenPGP's ECC-to-KEM transform here:
>>
>> https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-00.html#name-ecc-based-kems
>>
>> There are similarities to HPKE's DHKEM:
>>
>> https://www.rfc-editor.org/rfc/rfc9180.html#name-dh-based-kem-dhkem
>> https://www.rfc-editor.org/rfc/rfc9180.html#name-algorithm-identifiers
>>
>> Why doesn't draft-ietf-openpgp-pqc use DHKEM?
>>
>> /Simon
>> _______________________________________________
>> openpgp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/openpgp
>
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp
>