You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
Add filesize information into the checksum.sha256 when it was hashed. This way atleast that length extension attacks become difficult if not impossible.
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.
The text was updated successfully, but these errors were encountered:
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)
sha384
orsha512/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.
The text was updated successfully, but these errors were encountered: