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 :)
Is use this one:
edit: deleted in case some is so crazy to use 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.
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.
func deriveKey(key []byte) ([]byte, error) {
return scrypt.GenerateFromPassword([]byte("plaintext"), scrypt.DefaultParams)
}
> 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!).
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.
Furthermore, use a KDF to stretch your password into a key suitable for encryption.