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

Selecting algorithm names #115

Open
bleichenbacher-daniel opened this issue Apr 15, 2024 · 0 comments
Open

Selecting algorithm names #115

bleichenbacher-daniel opened this issue Apr 15, 2024 · 0 comments

Comments

@bleichenbacher-daniel
Copy link

I'd like to ask for opinions on algorithm names. While it is not completely necessary to have consistent naming for algorithms (and also file names) it would be helpful to have at least some rule of thumbs to avoid too much confusion. There are some inconsistencies in the current test vector files, so maybe these can be removed. The main issues are as follows:

  • sizes: most libraries use sizes in bits. So this should probably be the default. There are currently some exceptions, such as tag sizes an output sizes. Maybe these should be changed to achieve consistency.
  • distinction between initialisms and abbreviations: Wycheproof currently follows one of the Google style guides which says not to distinguish between these. This is somewhat uncommon since many libraries do distinguish. I.e. instead of name like AESCtrHMACBlake2s and AESCBCHMACSHA3_256 the names would always use PascalCase or camelCase: AesCtrHmacBlake2s and AesCbcHmacSha3_256. (The names above don't include key size and tag size, but that is a separate issue)
  • There are some proposed algorithm names in RFCs. I'm not sure if these should be used. The result would feel somewhat inconsistent.
  • Anything else: there are probably a lot of inconsistencies in the current version that are annoying.
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

1 participant