Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

idpf: Use XofTurboShake128 for the leaves #1158

Merged
merged 1 commit into from
Dec 13, 2024

Conversation

cjpatton
Copy link
Collaborator

@cjpatton cjpatton commented Dec 9, 2024

Partially addresses #1122.

As required by the latest draft, modify IDPF by using XofTurboShake128 for extension/conversion at the leaves of the tree. To accomplish this, encapsulate in the fixed AES key -- now use only for inner nodes -- with a type that has the content appropriate for the level of the tree. For the leaf nodes, this is the context string and nonce.

While at it, rename "binder" to "nonce", as has been done in the latest draft.

As required by the latest draft, modify IDPF by using XofTurboShake128
for extension/conversion at the leaves of the tree. To accomplish this,
encapsulate in the fixed AES key -- now use only for inner nodes -- with
a type that has the content appropriate for the level of the tree. For
the leaf nodes, this is the context string and nonce.

While at it, rename "binder" to "nonce", as has been done in the latest
draft.
Copy link
Collaborator Author

@cjpatton cjpatton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatives considered:

  1. My first thought was to overload ValueParameter to indicate the level of the tree being generated. That would require a bound on the type of ValueParameter in order to invoke convert() or extend(), which would mean we could only use idpf for Poplar1. In practice, this doesn't seem to matter, as Mastic, and hopefully future DPF constructions, won't have the special field constraint that Poplar1 has.

  2. I also thought about just plumbing in an is_leaf flag to convert() and extend(). However, we also need the context string and nonce. And since the fixed keys are only used for inner nodes, it made sense to unify all of this configuration into a single type,XofMode.

Comment on lines +251 to +253
let mut dst = Vec::with_capacity(EXTEND_DOMAIN_SEP.len() + ctx.len());
dst.extend(EXTEND_DOMAIN_SEP);
dst.extend(*ctx);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should modify the Xof::init() so that the domain separation tag can be provided in parts, just like the constructor for XofFixedAes128Key. I didn't do this in the current PR, since I figured this is relevant to #1147. (@divergentdave I can implement this next if you like.)

@cjpatton cjpatton marked this pull request as ready for review December 10, 2024 00:01
@cjpatton cjpatton requested a review from a team as a code owner December 10, 2024 00:01
@divergentdave divergentdave merged commit e119a37 into main Dec 13, 2024
6 checks passed
@divergentdave divergentdave deleted the cjpatton/1122-idpf-two-xofs branch December 13, 2024 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants