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

Security considerations regarding checksum choice #13

Open
chris-ha458 opened this issue Jul 19, 2023 · 0 comments
Open

Security considerations regarding checksum choice #13

chris-ha458 opened this issue Jul 19, 2023 · 0 comments

Comments

@chris-ha458
Copy link
Contributor

This is also an extension of my study into docs/schema/schema-v2.md
and docs/tools/generation-jeanzay.md

The hash function sha256 is used for the checksum. Althoguh sha256 is considered secure, it is not resistant to length extension attack.
There are several ways to address this, (if it is a concern)

  1. Add filesize information into the checksum.sha256 when it was hashed. This way atleast that length extension attacks become difficult if not impossible.
  2. Change the hash into sha384 or sha512/256. Both are similar in speed since they both first build sha512 (which is still vulnerable to length extension) and truncated and the bottleneck is the hashing step. (SHA512, SHA384,SHA512/256 each use different initialization vectors so you shouldnt try to roll your own btw). Compared to the total size of OSCAR releases, the increased size of sha384 is negligible as is the processing cost. If processing is an issue, other secure hashes such as BLAKE3 could be used. I guess further indepth considerations for hashes should be directed towards Ungoliant which i plan to do.

My point is that, atleast such considerations should be made, and it would be helpful for the documentation to communicate that.

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