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

ctr: block size vs counter size naming #172

Closed
tarcieri opened this issue Oct 14, 2020 · 3 comments
Closed

ctr: block size vs counter size naming #172

tarcieri opened this issue Oct 14, 2020 · 3 comments

Comments

@tarcieri
Copy link
Member

There's an open PR to add support for CTR mode with a 128-bit block size and 32-bit counter: #170.

This PR uses the name Ctr32 but this does not reflect the hardcoded 128-bit block size.

Additionally #75 adds support for natively 128-bit counters, versus the 64-bit counter currently used by the Ctr128 type.

How should we handle these discrepancies? Some suggestions:

  1. Make all implementations completely generic over the block size
  2. Introduce some way of incorporating the hardcoded block size into the name, e.g. Ctr128x32
  3. Give up on incorporating the block size into the name and say all implementations assume a 128-bit block size
@tarcieri
Copy link
Member Author

Note: in #170 I was able to use the first approach and make Ctr32BE and Ctr32LE generic over block sizes.

@newpavlov
Copy link
Member

I think this issue has been addressed in #195 by introducing seek_block and current_block methods. So we probably can close it? Ideally those methods would be exposed in a cipher trait, but it's blocked on designing a block-level API for stream ciphers.

@tarcieri
Copy link
Member Author

So yes, I consider this issue addressed, but the reason is:

  • Ctr128 now has a 128-bit counter instead of a 64-bit one
  • There are now Ctr32 and Ctr64 with 32-bit/64-bit counters respectively

All of them are still hardcoded to BlockCipher<BlockSize = U16>, but as long as there's a way to distinguish the counter sizes easily I'm happy.

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

No branches or pull requests

2 participants