Re: [jose] [COSE] HPKE PartyU / PartyV

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 01, 2024 at 03:39:11AM +0000, lgl island-resort.com wrote:
> So here’s a possible new Enc_structure Orie suggested. I’m calling
> it Rec_structure. It is just for COSE_Recipients.
> 
> 
> Rec_structure = [
>     context :  “Enc_Recipient” / “Rec_Recipient",
>     protected : empty_or_serialized_map,
>     next_alg : int/tstr
> ]
> 
> - protected is for the protected headers from the COSE_Recpient
> - No external_aad since COSE_Recipient doesn’t have that
> - Pass this as the aad parameter to Seal() as Ilari suggests
> - next_alg is the COSE algorithm ID from the COSE layer below and is
>   mandatory

I would use a single context and add explicit uint depth. Even if I
expect this to always have depth=1 in practice.

The problem with that kind of thing is all the legacy stuff used for
key management that is not AEAD-capable. Even if one redoes all the ECDH
stuff for fully specified algorithms, there is still some other key
management stuff that is fully specified, but can not bind the next
algorithm. And that gets into security relying on optional stuff
territory real fast.


> I've intentionally chose only the algorithm ID, not all the protected
> headers from layer 0.  This is because of implementation complexity
> and memory use. My COSE implementation can handle arbitrarily large
> blocks of header parameters (plus arbitrarily large external_aad)
> without allocating memory through use of incremental hashing. I don’t
> want to have multiple incremental hashes in flight at once, one for
> each recipient, nor do I want to put a cap on the size of header
> parameters or use malloc. Passing only the algorithm ID across layers
> is simpler and cleaner.

And in the COSE library API I showed earlier, one could easily add a
method (TODO: Compile-check and add documentation):

fn get_alg(&self) -> Algorithm<'static> { self.alg }

To get the algorithm. Which is semver minor, so not a breaking change.


And if doing file to file on hardware that has a memory managment unit,
why not memory map the input and output files? :-)



-Ilari