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>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
