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.
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.
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?
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.
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].
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!).
As natedub indicates, to turn a password into a key you need to use a password-based key-derivation function; PBKDF2 is standardised, sane and reasonably quick; scrypt and bcrypt get more love these days, but I think any of them would be sufficient.
A cryptographic key (unlike a password) needs to be exactly a certain length, and ideally be completely random (if not, at least indistinguishable from random): a password might be exactly that length, but it will _not_ be completely random (heck, if you can type it then certain bit patterns simply won't occur …).
The fact that '012345789ABCDEF012345789ABCDEF' and unhex('cd8fa5ecf22379c429f56fdaae511144f9b7704247a244859b943299eb57fb1d') have the same length in bytes is coincidental; they really are two very different types.
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 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, 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.
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.
35 comments
[ 4.7 ms ] story [ 93.7 ms ] threadhttps://nacl.cr.yp.to/index.html
Out of curiosity, how do people determine 12 is the right work factor? When should/will this go to 13?
https://en.wikipedia.org/wiki/Bcrypt
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.
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
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?
[1] https://github.com/golang/go/blob/master/src/crypto/elliptic...
[2] https://github.com/golang/go/blob/master/src/crypto/elliptic...
Is use this one:
edit: deleted in case some is so crazy to use it :)
> 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!).
Furthermore, use a KDF to stretch your password into a key suitable for encryption.
See https://en.wikipedia.org/wiki/PBKDF2
A cryptographic key (unlike a password) needs to be exactly a certain length, and ideally be completely random (if not, at least indistinguishable from random): a password might be exactly that length, but it will _not_ be completely random (heck, if you can type it then certain bit patterns simply won't occur …).
The fact that '012345789ABCDEF012345789ABCDEF' and unhex('cd8fa5ecf22379c429f56fdaae511144f9b7704247a244859b943299eb57fb1d') have the same length in bytes is coincidental; they really are two very different types.
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.
scrypt, with an output length that suits your use-case? (as Filippo points out)
Note: I wrote 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.
You can pass your own params, or modify the defaults to get a different key length depending on your use-case.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.
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!
https://godoc.org/golang.org/x/crypto/nacl/secretbox