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.
Well, the Go implementation of P-256 is meant to be constant-time, even if we don't get a hard guarantee that the compiler won't screw that up somewhere somehow. On the other hand, the generic implementation of the other curves is almost comically vulnerable to timing attacks---compare [1] to [2].
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.
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.
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.
I'm not sure what you looked at, but the first example I found used a 32 byte key (256 bits = 8 * 32). From the readme :
> 5. Key generation functions will panic if they can't read enough random bytes
to generate the key. Key generation is critical, and if crypto/rand fails at
that stage then you should stop doing cryptography on that machine immediately.
Having less than a full encryption key is a fatal error! Not something to be padded around.
Apologies if there are some examples for key derivation from a password that somehow doesn't use only part of an array initialized to zero (which would be bad, adding random unitialized data to the kdf - good luck decrypting!).
[+] [-] Etzos|9 years ago|reply
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/
Edit: Formatting and grammar and spelling, oh my.
[+] [-] pbsd|9 years ago|reply
[1] https://github.com/golang/go/blob/master/src/crypto/elliptic...
[2] https://github.com/golang/go/blob/master/src/crypto/elliptic...
[+] [-] gtank|9 years ago|reply
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
[+] [-] niftich|9 years ago|reply
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|9 years ago|reply
2. Goes to 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|9 years ago|reply
[+] [-] verroq|9 years ago|reply
https://godoc.org/golang.org/x/crypto/nacl/secretbox
[+] [-] Bromskloss|9 years ago|reply
[+] [-] Royalaid|9 years ago|reply
[+] [-] Titanous|9 years ago|reply
https://nacl.cr.yp.to/index.html
[+] [-] sdrapkin|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] saynsedit|9 years ago|reply
[+] [-] kevinburke|9 years ago|reply
Out of curiosity, how do people determine 12 is the right work factor? When should/will this go to 13?
[+] [-] psiclops|9 years ago|reply
https://en.wikipedia.org/wiki/Bcrypt
[+] [-] dawkins|9 years ago|reply
Is use this one:
edit: deleted in case some is so crazy to use it :)
[+] [-] FiloSottile|9 years ago|reply
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
Don't copy-paste crypto from HN.
[+] [-] e12e|9 years ago|reply
> 5. Key generation functions will panic if they can't read enough random bytes to generate the key. Key generation is critical, and if crypto/rand fails at that stage then you should stop doing cryptography on that machine immediately.
Having less than a full encryption key is a fatal error! Not something to be padded around.
Apologies if there are some examples for key derivation from a password that somehow doesn't use only part of an array initialized to zero (which would be bad, adding random unitialized data to the kdf - good luck decrypting!).