
Copy and paste-friendly Go crypto - FiloSottile
https://github.com/gtank/cryptopasta
======
Etzos
I was actually at this talk (excellent way to go over this kind of topic!) and
I have just a small thing to add.

You'll notice the "Asymmetric Signature" section mentions using ESDSA on P-256
because "the Go implementation of P-256 is constant time to protect against
side-channel attacks." However, someone mentioned that this may not be on all
platforms because it is hand-coded assembly. After a quick check of the Go
source code, this is indeed true. In fact, the constant time guarantee
assembly version is _only_ available on amd64 compatible systems[1]. Just
something to take note of.

[1]
[https://golang.org/src/crypto/elliptic/](https://golang.org/src/crypto/elliptic/)

Edit: Formatting and grammar and spelling, oh my.

~~~
gtank
Author here, glad you enjoyed the talk!

Looking into it more I noticed that there's a Go implementation[1] that is
noted to be constant-time with a !amd64 build tag. So it isn't just the
assembly one.

[1]
[https://golang.org/src/crypto/elliptic/p256.go](https://golang.org/src/crypto/elliptic/p256.go)

~~~
Etzos
Wow, I completely missed that (largely because I assumed a Go implementation
could not guarantee constant time), sorry about that and thanks for looking
deeper than I did.

On that note, how much of a guarantee is there in the Go implementation? I
assume in most cases it's going to be constant time, but isn't that a little
harder to guarantee when compared to the asm version? And if not why not just
use the Go implementation everywhere for consistency?

~~~
wbl
The asm version is much more performant. The Go version is a port of the
version in NSS, but the compiler is free to screw it up in various ways.
Furthermore correctness is always a concern: cleverness in unsaturated
arithmetic code can be hard.

------
niftich
Your recommendations and defaults are sane, and the code looks solid, thanks
for publishing.

I just don't know why you call this 'copy and paste-friendly'. This is
essentially a minimalistic library, not a bunch of code examples (ie.
"usage").

Stackoverflow (as awful as roll-your-own-crypto is,) is great for seeing code
examples in context of a domain problem, rather than a crypographic primitive.

This is a decent wrapper for goland stdlib's crypto, but doesn't particularly
help a person who's trying to understand how to apply crypto to their
particular usecase, and would therefore be most susceptible to googling it.

~~~
baby
1\. How do I protect my password, umm, I heard I have to hash it.

2\. Goes to
[https://github.com/gtank/cryptopasta/blob/master/hash.go#L41](https://github.com/gtank/cryptopasta/blob/master/hash.go#L41)

3\. This `HashPassword()` and `CheckPasswordHash()` functions look interesting

4\. Copy/Pasted into the project, it just works!

------
ashitlerferad
Don't copy and paste code! Instead, use a well maintained library.

~~~
Bromskloss
I'm not sure, but isn't this post about showing how to use such libraries?

~~~
ashitlerferad
No: "Copy and paste-friendly Go crypto"

------
Royalaid
This is a really great idea! I would like to see it for other langs too.

~~~
Titanous
NaCl is basically this, but as a library instead of copy/paste. It's available
in most languages if you look around.

[https://nacl.cr.yp.to/index.html](https://nacl.cr.yp.to/index.html)

~~~
nathan7
[https://golang.org/x/crypto/nacl](https://golang.org/x/crypto/nacl) for the
Gophers among us (it provides only box/secret_box, though)

------
saynsedit
P-256 is not a safe curve!
[http://safecurves.cr.yp.to](http://safecurves.cr.yp.to)

------
kevinburke
> You should not go below work factor 12.

Out of curiosity, how do people determine 12 is the right work factor? When
should/will this go to 13?

~~~
psiclops
It is relative to cpu performance.

[https://en.wikipedia.org/wiki/Bcrypt](https://en.wikipedia.org/wiki/Bcrypt)

~~~
tmd83
What is the current recommendation for iteration count for pbkdf2?

~~~
Natanael_L
What your slowest hardware can handle in a reasonable timeframe

------
dawkins
In the encrypt examples I always wonder why they assume that you have a fixed
32 bit key (password). Shouldn't they include a padding function?

Is use this one:

edit: deleted in case some is so crazy to use it :)

~~~
FiloSottile
Wait. Stop. You are writing your own crypto.

AES keys are 256 (or 128) bit, fixed size, and should be random-looking data.
The code here uses [32]byte intentionally so you won't use anything else.

If you have a _password_ instead, that is NOT suitable for use as a key
directly, whichever the length, because it has low entropy by definition. So
you want to stretch it (and whiten it) with something like scrypt. It's a bit
of the same argument as password hashing.

Also, you don't want to discover what happens if you have strong patterns like
padding in your key (it should be fine, but it's the kind of attacks that come
before a full break). And you don't want to cut short a password longer than
32 characters.

This is the issue, btw:
[https://github.com/gtank/cryptopasta/issues/7](https://github.com/gtank/cryptopasta/issues/7)

Don't copy-paste crypto from HN.

~~~
dawkins
I know! That's why I am asking. I have found surprisingly difficult to find a
package that does this.

~~~
elithrar
> I know! That's why I am asking. I have found surprisingly difficult to find
> a package that does this.

scrypt, with an output length that suits your use-case? (as Filippo points
out)

Note: I wrote [https://github.com/elithrar/simple-
scrypt](https://github.com/elithrar/simple-scrypt), which wraps Go's scrypt
package and gives it a friendlier API (mimicking the bcrypt one). Handles salt
generation for you and has sane default parameters, outputting a 32-byte
derived key by default. e.g.

    
    
        func deriveKey(key []byte) ([]byte, error) {
            return scrypt.GenerateFromPassword([]byte("plaintext"), scrypt.DefaultParams)
        }
    

You can pass your own params, or modify the defaults to get a different key
length depending on your use-case.

~~~
dawkins
yes, that is what I was looking for. Thank you!

