5 ms·

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

by dawkins 10y ago

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 :)

e12e 10y ago
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!).
- dawkins 10y ago
  But what if I want to encrypt "my secret" with "password1234"?. You can't require everybody to memorize exactly 32 bit passwords
  - CiPHPerCoder 10y ago
    Stop saying 32 bit, please. It's 32 byte, or 256 bit. Furthermore, use a KDF to stretch your password into a key suitable for encryption.
    - dawkins 10y ago
      Sorry, of course I mean 32 byte.
  - natedub 10y ago
    Passwords are not keys, but you can generate a key from a password with a Password-Based Key Derivation Function. See https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2
  - wtbob 10y ago
    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.
FiloSottile 10y ago
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 10y ago
  I know! That's why I am asking. I have found surprisingly difficult to find a package that does this.
  - elithrar 10y ago
    > 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 10y ago
      yes, that is what I was looking for. Thank you!

by dawkins 10y ago

e12e 10y ago

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!).

dawkins 10y ago
But what if I want to encrypt "my secret" with "password1234"?. You can't require everybody to memorize exactly 32 bit passwords
- CiPHPerCoder 10y ago
  Stop saying 32 bit, please. It's 32 byte, or 256 bit. Furthermore, use a KDF to stretch your password into a key suitable for encryption.
  - dawkins 10y ago
    Sorry, of course I mean 32 byte.
- natedub 10y ago
  Passwords are not keys, but you can generate a key from a password with a Password-Based Key Derivation Function. See https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2
- wtbob 10y ago
  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.

FiloSottile 10y ago

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 10y ago
I know! That's why I am asking. I have found surprisingly difficult to find a package that does this.
- elithrar 10y ago
  > 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 10y ago
    yes, that is what I was looking for. Thank you!