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.

Sign up for GitHub

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

Add md5 & some non-crypto hashes. Close #34 #44

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add md5 & some non-crypto hashes. Close #34 #44

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions hashtable.csv
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,3 +10,14 @@ code, name
0x19, shake-256
0x40, blake2b
0x41, blake2s
0x55, md5
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

md5 is now 0xd5 as of #76

0x60, xxHash32
0x61, xxHash64
0x62, Spooky32
0x63, Spooky64
0x64, Spooky128
0x65, Murmur3A
0x66, Murmur3C
0x67, Murmur3F
0x75, crc32
0x76, crc32-C
Copy link
Member

@jbenet jbenet Aug 15, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we should source more of the "non cryptographic hashes", at least the useful ones. List of more:

and

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there a need for non-cryptographic hashes? I don't really think they have their place in the mutihash spec. I like the description in RFC 6920:

The various formats are designed to support, but not require, a
strong link to the referenced object, such that the referenced object
may be authenticated to the same degree as the reference to it.

Unless there is a use /not/ to reference object such that they can be authenticated by the hash, you could of course add MD5, CRC-32 and so on, but I would stay away from it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pawal we decided to do this some time ago #30 -- unfortunately, most cryptographically secure hash functions turn into hash functions that are not cryptographically secure. So the distinction would only be historical.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be fantastic to have "multihash" being an IETF supported document, but adding hashes to the list like this would make it rather impossible.

The good thing by having the IANA registry is that algorithms in the registry can be clearly marked as being deprecated. This has happened to MD5 in almost all present algorithm registries. See for example here:
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

If going for your own registry, please have one or more extra fields describing these properties to the algorithms, with a possible source reference.

So you can add "status", and "reference" to the csv table.