Re: [jose] HPKE Single Shot for Compact JWE

[Orie Steele <[e-mail]>]

Sorry for 2 messages, I hit send early on the last one.

I was just adding the comment about validated enc, see
https://datatracker.ietf.org/doc/html/rfc8725#name-validate-cryptographic-inpu

> The JWS/JWE library itself must validate these inputs before using them,
or it must use underlying cryptographic libraries that do so (or both!).

It could be cool to trust the HPKE implementation to validate the "enc"
value, or you might validate it before even invoking a single shot API.

I like the design of transported "encapsulated keys" in protected headers
when possible.

Even if it's redundant to the internals of HPKE, as the JWT BCP notes,
redundant security checks are ok.

Regards,

OS


On Sun, Feb 11, 2024 at 7:58 AM Orie Steele <[e-mail]>
wrote:

> Section 5 defines -
> https://datatracker.ietf.org/doc/html/rfc9180#section-5.1 :
>
> def SetupBaseS(pkR, info):
>   shared_secret, enc = Encap(pkR)
>   return enc, KeyScheduleS(mode_base, shared_secret, info,
>                            default_psk, default_psk_id)
>
> def SetupBaseR(enc, skR, info):
>   shared_secret = Decap(enc, skR)
>   return KeyScheduleR(mode_base, shared_secret, info,
>                       default_psk, default_psk_id)
>
> Section 6 of defines "Single-Shot" APIs for HPKE -
> https://datatracker.ietf.org/doc/html/rfc9180#name-single-shot-apis :
>
> def Seal<MODE>(pkR, info, aad, pt, ...):
>   enc, ctx = Setup<MODE>S(pkR, info, ...)
>   ct = ctx.Seal(aad, pt)
>   return enc, ct
>
> def Open<MODE>(enc, skR, info, aad, ct, ...):
>   ctx = Setup<MODE>R(enc, skR, info, ...)
>   return ctx.Open(aad, ct)
>
> With "Single-Shot", you cannot place the "encapsulated key (enc)" in JWE
> Protected Headers.
>
> Given the original design of JWE in
> https://datatracker.ietf.org/doc/html/rfc7516#section-3.1
>
> Compact:
>
>       BASE64URL(UTF8(JWE Protected Header)) || '.' ||
>       BASE64URL(JWE Encrypted Key) || '.' ||
>       BASE64URL(JWE Initialization Vector) || '.' ||
>       BASE64URL(JWE Ciphertext) || '.' ||
>       BASE64URL(JWE Authentication Tag)
>
> JSON:
>
>      "protected", with the value BASE64URL(UTF8(JWE Protected Header))
>       "unprotected", with the value JWE Shared Unprotected Header
>       "header", with the value JWE Per-Recipient Unprotected Header
>       "encrypted_key", with the value BASE64URL(JWE Encrypted Key)
>       "iv", with the value BASE64URL(JWE Initialization Vector)
>       "ciphertext", with the value BASE64URL(JWE Ciphertext)
>       "tag", with the value BASE64URL(JWE Authentication Tag)
>       "aad", with the value BASE64URL(JWE AAD)
>
> In https://mailarchive.ietf.org/arch/msg/jose/0ODZ_2TTjrOOwv1JwvYuv0OuZ0s/
>
> Ilari proposed, concatenating "HPKE enc" with "HPKE ct", and calling the
> result "JWE Ciphertext".
>
> This would enable "HPKE Single Shot", but at a cost of needing to slice
> the "JWE Ciphertext" string to recover enc (which will change in size with
> use of different kems).
>
> In draft-rha-jose-hpke-encrypt current design for single recipient JWE
> messages, we defined a new JWA approach called "Integrated Encryption",
> which leverages HPKE to encrypt a plaintext message to a single recipient,
> without the need to include: JWE Encrypted Key, JWE Initialization Vector,
> JWE Authentication Tag.
>
> For example:
> eyJhbGciOiJIUEtFLUJhc2UtUDI1Ni1TSEEyNTYtQUVTMTI4R0NNIiwiZXBrIjp7Imt0eSI6IkVLIiwiZWsiOiJCQ0lrQ2Nka1hHS2VhaEhpMFdFRnFMbm9VREFtdnpJd0t2SVF3TFNXWjVpTHc3ZDFSMXdDRTRpVUVyV1NKZnlueGwtTmltQVdhSkNfWFVjY2lwOEhZeTAifX0
> ...
> vtwAfUY4SP2loyqJDht2r824r1a0tTi-0Cr_u0GunXCMxvKbZQaZFFjEMBTffJRf6FBaJMao2Trm5QZBxLr_w7f75ZPA99VdY7YMwRNkfftRW97BPEn0x0SM3inNaESQGuPqNZM
> .
>
> It does this, by using the "epk" parameter of the JWE Protected Header to
> transport the "HPKE enc".
>
> This means that in order for a recipient to decrypt a message, they must
> pass the JWE Protected Header to HPKE Open as aad.
>
> I have adjusted the pythonish examples from HPKE to make this clearer to
> readers:
>
> def Seal<MODE>(pkR, info, aad="JWE Protected Header", pt, ...):
>   enc, ctx = Setup<MODE>S(pkR, info, ...)
>   ct = ctx.Seal(aad, pt)
>   return enc, ct
>
> // desirable, but not possible because "enc" was not in "JWE Protected
> Header".
> /// enc = decode(decode("JWE Protected Header").epk.ek)
>
> [enc, ct] = slice("JWE Ciphertext")
>
> validate_enc(enc) // because in DHKems enc is a public key made of points
> on a curve
>
> def Open<MODE>(enc=enc, skR, info, aad="JWE Protected Header", ct=ct, ...):
>   ctx = Setup<MODE>R(enc, skR, info, ...)
>   return ctx.Open(aad, ct)
>
> I see no reason to comment on Single Shot APIs directly in
> "draft-rha-jose-hpke-encrypt".
>
> These HPKE internals are implementation details, similar to how JWE does
> not comment on deriveBits / deriveSecretKey, and yet implementations of JWE
> might use those APIs from web crypto internally.
>
>
>
>
>
>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>