Skip to content

Security considerations regarding checksum choice #13

@chris-ha458

Description

@chris-ha458

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions