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

Comments

Projects
None yet
8 participants
@aead
Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Mar 22, 2017

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 odeke-em added the Proposal label Mar 22, 2017

@odeke-em

This comment has been minimized.

Copy link
Member

commented Mar 22, 2017

/cc @agl and other crypto folks.

@agl

This comment has been minimized.

Copy link
Contributor

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

@ALTree ALTree added the help wanted label Sep 22, 2018

@dgryski

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Member

commented Jan 22, 2019

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.