Add guidance for using Setup and Context auxiliary info parameters. #231
Conversation
There was a problem hiding this comment.
This works for me, though our implementation doesn't expose the single-shot APIs in the first place, so I'm not the best judge. I guess it may be less performant if you've got a lot of AAD bits, where info=label and aad=whatever might be more efficient. But this is probably not worth the fuss.
| operations, i.e., with the `aad` parameter for `Open()` and `Seal()`, and the `info` parameter | ||
| for `Export()`. Application information applicable to multiple operations on a single Context | ||
| should use the Setup `info` parameter. This avoids redundantly processing this information for | ||
| each Context operation. In contrast, application information that varies on a per-message basis |
There was a problem hiding this comment.
In addition to redundancy, domain separation is a bit clearer. In ECH, we only include "tls ech" in the info parameter. aad is a plain ClientHelloOuterAAD. If another protocol decided to put the label in the other fields, injectivity is a little trickier.
There was a problem hiding this comment.
Yeah, I don't really have a better way to say "domain separation via the key schedule" is preferred without just making this text less clear.
Co-authored-by: David Benjamin <davidben@google.com>
I figure it's not worth the fuss since both seem to have the same basic security properties. |
Guidance from latest HPKE draft clarifies that single-shot APIs should not allow users to set both per-context and per-message auxiliary authenticated application information. cfrg/draft-irtf-cfrg-hpke#231 PiperOrigin-RevId: 383494777
I hesitate to add any more detail about what might be "per-context" and "per-message," but I'm open to suggestions if folks think this can be stated more clearly.
Closes #226.
cc @davidben, @cjpatton, @martinthomson, @blipp, @franziskuskiefer