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

x/crypto: add new package siphash #19659

Closed
aead opened this issue Mar 22, 2017 · 6 comments
Closed

x/crypto: add new package siphash #19659

aead opened this issue Mar 22, 2017 · 6 comments

Comments

@aead
Copy link
Contributor

aead commented Mar 22, 2017

This is a proposal for implementing the pseudo-random function SipHash.
SipHash was designed to defend hash-flooding DoS attacks, but it can be used in many use cases.

I've seen some projects using SipHash to solve different problems and use custom implementations. So it's probably a good idea to provide a "official" golang implementation.

@gopherbot
Copy link

CL https://golang.org/cl/38362 mentions this issue.

@odeke-em odeke-em changed the title x/crypto add new package siphash proposal: x/crypto: add new package siphash Mar 22, 2017
@odeke-em odeke-em added this to the Proposal milestone Mar 22, 2017
@odeke-em
Copy link
Member

/cc @agl and other crypto folks.

@agl
Copy link
Contributor

agl commented Mar 24, 2017

I believe that siphash meets the bar for x/crypto.

@bradfitz bradfitz changed the title proposal: x/crypto: add new package siphash x/crypto: add new package siphash Mar 24, 2017
@bradfitz bradfitz modified the milestones: Unreleased, Proposal Mar 24, 2017
@dgryski
Copy link
Contributor

dgryski commented Oct 23, 2018

Ping. Seems like @aead was fine to abandon the CL, but @agl seemed in favour. I'm in favour of closing.

@aead
Copy link
Contributor Author

aead commented Oct 24, 2018

I think there is no obvious use case for SipHash (anymore). Esp. since a reasonable fast implementation probably needs assembler code (See #28126). Further there is a "successor" (https://github.com/google/highwayhash). We can consider adding SipHash again if it is requested by (other) users?!

@FiloSottile
Copy link
Contributor

I agree with @aead for a few reasons:

  • I don't like the idea of having a fast MAC which is not a secure hash but is called Hash in x/crypto
  • x/crypto already has too many optimized implementations which we don't have a solid maintenance story for
  • there are two main implementations in the ecosystem, so it's not too fragmented https://godoc.org/?q=siphash
  • HighwayHash exists now and since SipHash uses are mostly internal, and not protocol-exposed, I'm not sure why one would use SipHash

@golang golang locked and limited conversation to collaborators Jan 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants