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
Right now the spec introduces our two hash algorithms as "SHA1" and "SHA256," which misses that these algorithms aren't exactly SHA1 and SHA256 but are in fact specific variants of them as used by Git. Namely, these they're prefixed with an ASCII string indicating the type of Git object being identified, followed by a null terminator, followed by the bits of the artifact being hashed.
The spec should be modified to include an early description of the hashing algorithms used, either defining them in detail directly, or deferring to a canonical third-party description of the hashing algorithm. We should also be sure whenever they're referenced in the spec, including in annexes, that we're clear that these are not regular SHA1 or SHA256.
There may be prior art in the cryptography ecosystem for how Git's SHA1 and SHA256 variants are identified. Ideally, we'd match what other people are already using when referring to them.
The text was updated successfully, but these errors were encountered:
alilleybrinker
changed the title
More precisely describe / introduce the OmniBOR hash algorithms in the spec
Define the "GitOID construction" scheme used for creating Artifact Identifiers.
Dec 7, 2023
Right now the spec introduces our two hash algorithms as "SHA1" and "SHA256," which misses that these algorithms aren't exactly SHA1 and SHA256 but are in fact specific variants of them as used by Git. Namely, these they're prefixed with an ASCII string indicating the type of Git object being identified, followed by a null terminator, followed by the bits of the artifact being hashed.
The spec should be modified to include an early description of the hashing algorithms used, either defining them in detail directly, or deferring to a canonical third-party description of the hashing algorithm. We should also be sure whenever they're referenced in the spec, including in annexes, that we're clear that these are not regular SHA1 or SHA256.
There may be prior art in the cryptography ecosystem for how Git's SHA1 and SHA256 variants are identified. Ideally, we'd match what other people are already using when referring to them.
The text was updated successfully, but these errors were encountered: