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

Experimental implementation of CTX #324

Merged
merged 17 commits into from
Mar 11, 2023
Merged

Experimental implementation of CTX #324

merged 17 commits into from
Mar 11, 2023

Conversation

brycx
Copy link
Member

@brycx brycx commented Mar 4, 2023

see #317

  • Adds new crate feature experimental
  • Adds new module hazardous::cae
  • Adds experimental implementation of CTX construction built on (X)ChaCha20-Poly1305-BLAKE2b

TODO:

  • Add tests using Wycheproof that both CTX constructions still produce the same ciphertext as the underlying AE
  • Add documentation and example of partitioning oracle attack as use-case

@brycx brycx marked this pull request as draft March 4, 2023 10:35
@vlmutolo
Copy link
Contributor

vlmutolo commented Mar 7, 2023

Looks good to me at a glance. One thing to consider would be adding an example of what problem this solves compared to non-committing AEAD. I'm not sure if that's helpful or not for theoretical consumers of the library.

If we wanted to add an example, I thought the partitioning oracle attack was relatively straightforward.

If we ever want to change over the high-level API to a committing AEAD, I don't think that kind of note would be helpful in the high-level docs since users aren't expected to really understand cryptography. But in the hazardous API, maybe it's good for people scrolling through the different options to have an understanding of the kinds of attacks this can prevent.

@brycx
Copy link
Member Author

brycx commented Mar 7, 2023

If we wanted to add an example, I thought the partitioning oracle attack was relatively straightforward.

If you mean add it in description and provide the link, then yes, completely agree! Though if you were thinking of an actual code example, I don't know if this would be too big/complex to have as an example.

If we ever want to change over the high-level API to a committing AEAD, I don't think that kind of note would be helpful in the high-level docs since users aren't expected to really understand cryptography. But in the hazardous API, maybe it's good for people scrolling through the different options to have an understanding of the kinds of attacks this can prevent.

Indeed. We should add this, but still mention in high-level that it is fully-committing (I mean, just they keyword, users can ignore it). Though, if somebody searches hazardous for this, they probably know what they are looking for.

@brycx
Copy link
Member Author

brycx commented Mar 7, 2023

@vlmutolo was this the kind of documentation addition you were thinking of?

@brycx brycx marked this pull request as ready for review March 10, 2023 10:01
@brycx brycx added this to the 0.17.5 milestone Mar 11, 2023
@brycx brycx merged commit 9e3b0d7 into master Mar 11, 2023
@brycx brycx deleted the key-commitment branch March 11, 2023 10:19
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