add compatibility note on sha3 as alias for sha3-512 #22
Conversation
| @@ -83,6 +83,9 @@ code name | |||
| # 0x14 formerly had the name "sha3", now deprecated | |||
| ``` | |||
|
|
|||
| ## Compatibility note | |||
|
|
|||
| Implementations should make sure keep the string code `sha3` as an alias for `sha3-512` so that `encode('sha3', digest) == encode('sha3-512', digest)`. | |||
There was a problem hiding this comment.
I think this is right. can someone else comment on this? cc @lgierth @whyrusleeping
There was a problem hiding this comment.
Should be: "...should make sure to keep the..."
Content sounds right, if 512 is the default bit-size of the digest. But I'm not sure where that assumption is coming from, as there are 3 other SHA-3 hashing functions, and two more if you count the XOFs.
There was a problem hiding this comment.
@RichardLitt the comment here is that there are multiple variants of the hash function, not the output size. similar to how sha2-256 and sha2-512 are different functions. (the default output size matches the classification)
There was a problem hiding this comment.
Unless I misread the spec correctly, they differ mainly in the size of the digest. What I'm not sure about is whether or not sha3 should by default mean sha3-512, as opposed to one of the other five (like sha3-256).
There was a problem hiding this comment.
See https://en.m.wikipedia.org/wiki/SHA-3 sections: instances (show
different postfixes) and examples (show totally different hash values for
same input, not just a truncation of same value)
On Wed, Aug 3, 2016 at 16:57 Richard Littauer [email protected]
wrote:
In README.md
#22 (comment):@@ -83,6 +83,9 @@ code name
0x14 formerly had the name "sha3", now deprecated
+## Compatibility note + +Implementations should make sure keep the string code `sha3` as an alias for `sha3-512` so that `encode('sha3', digest) == encode('sha3-512', digest)`.Unless I misread the spec correctly, they differ mainly in the size of the
digest. What I'm not sure about is whether or not sha3 should by default
mean sha3-512, as opposed to one of the other five (like sha3-256).—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/multiformats/multihash/pull/22/files/0638385dd25a1f5b186819b50c9999a4621117b2#r73419387,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcoc4EDpDrw_azWOSUeeTT6sg51rL3ks5qcQC4gaJpZM4HLQD1
.
There was a problem hiding this comment.
Yes, the digest is different; you're right. It is not simply a matter of length.
However, I still am not sure - why is this PR suggesting we use sha3 as an alias for sha3-512, and not some other one of the sha3 functions?
There was a problem hiding this comment.
I believe because that's what was used by an implementation.
There was a problem hiding this comment.
@candeira Can you back up this decision?
There was a problem hiding this comment.
This multihash repo defines a spec, not an API, so the proposed wording that references a "string code" feels weird to me (many implementations will not use a string to specify the hash type). What about something like this instead:
Implementations should be aware that a previous version of this spec used the label
SHA3for the SHA3-512 hash (code0x14). If your implementation allows hash types to be specified as a string, you should consider makingSHA3andSHA3-512aliases, or disallow the labelSHA3entirely.
|
sorry for the months delay on review |
|
this should probably modify the table? see #12 |
|
This PR is out of date and should be closed. |
No description provided.