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.

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 Security Considerations #131

Open
ioggstream opened this issue Sep 8, 2020 · 5 comments
Open

Add Security Considerations #131

ioggstream opened this issue Sep 8, 2020 · 5 comments

Comments

@ioggstream
Copy link

I expect

to have Security Considerations

@rvagg
Copy link
Member

rvagg commented Sep 9, 2020

perhaps you could start a pull request if you have some in mind that are worth listing?

@ioggstream
Copy link
Author

@rvagg not a crypto expert, but a starting point could be to evaluate every single threat in https://www.rfc-editor.org/rfc/rfc8725.html and check if that's applicable.

I'm trying to get some feedback via twitter https://twitter.com/EnricoBassetti/status/1303390299662811141 too...

@rvagg
Copy link
Member

rvagg commented Sep 9, 2020

So, multihash isn't a prescription for how to hash, what to hash or even what to do with a hash, other than how to present one in a portable way. Hashing algorithms themselves are well beyond the scope of this project, there are plenty of flawed ones and multihash doesn't assert opinions on those itself, it's simply a means of presenting a digest in a portable way so that you can transmit and store them and retain information about the hashing function used and the length of the digest, that's it.

It's possible that there are interesting security considerations related to that narrow purpose that might be worth mentioning, but we need to be clear on the limitations of this project and the scope of what it's trying to achieve. It's certainly not trying to do anything so broad as JWT, and the burden of responsible and safe use of hash functions isn't something that belongs here.

@ioggstream
Copy link
Author

ioggstream commented Sep 9, 2020

it's simply a means of presenting a digest in a portable way ...
the burden of responsible and safe use of hash functions isn't something that belongs here ...

Those statements can be a basis for the Security Considerations, like your FAQ on md5 and sha-1.

My understanding is that SC can even contain the rationale of design choices that make multihash more secure respect to other specs (Eg. we decided to encode parameters inside the hash to avoid parameter-substitution attacks .... )

About varints, some considerations should detail something like (eg. https://datatracker.ietf.org/doc/html/draft-multiformats-multihash-01#section-2.1.1)

Another could investigate better about the usage of length to address truncation algorithms: I don't claim it's bad, just that those points should be explained to a reader which want to use multihash but want to some more discussion respect to the ones contained in the FAQ.

Another consideration can be about the encoding:

Multihash and all other multiformats endeavor to be as compact as possible, which means a binary packed representation will help save a lot of space

it is not clear to me whether the multihash is a binary representation or an hex-ascii-string representation.

I think somebody with a bit of knowledge in this fields should help us in filing some questions and provide answers :)

@mikeal
Copy link

mikeal commented Sep 25, 2020

it is not clear to me whether the multihash is a binary representation or an hex-ascii-string representation.

Always binary. String representations are produced using multibase, so anything that isn’t multibase is talking about the binary representation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants