4 ms·

Fair points :) Do you have any examples of using a KDF that jives with the bitlength requirements of a given cipher?

throwaway_129 8y ago
https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2 Again, I'm not a cryptographer, and PBKDF2 is just an example. I would try to consult someone with a heavier background in the field. I've used PBKDF2 and Scrypt before, Argon2 is the newest, but also therefor least battle-tested. https://godoc.org/golang.org/x/crypto/pbkdf2 https://godoc.org/golang.org/x/crypto/pbkdf2 https://godoc.org/golang.org/x/crypto/argon2 https://godoc.org/golang.org/x/crypto/argon2 https://godoc.org/golang.org/x/crypto/scrypt https://godoc.org/golang.org/x/crypto/scrypt
leetbulb 8y ago
There's an RFC for that: https://tools.ietf.org/html/rfc5869 https://tools.ietf.org/html/rfc5869 Doesn't look like the Go API[1] allows you to specify an output key material length, so you'd just truncate or iterate until you get however much material you need (The HKDF Wiki implementation does this[2]). 1: https://godoc.org/golang.org/x/crypto/hkdf https://godoc.org/golang.org/x/crypto/hkdf 2: https://en.wikipedia.org/wiki/HKDF#Example:_Python_implementation https://en.wikipedia.org/wiki/HKDF#Example:_Python_implement...
- throwaway_129 8y ago
  You don't want to generate key material from a password with hkdf. From the RFC: On the other hand, it is anticipated that some applications will not be able to use HKDF "as-is" due to specific operational requirements, or will be able to use it but without the full benefits of the scheme. One significant example is the derivation of cryptographic keys from a source of low entropy, such as a user's password. The extract step in HKDF can concentrate existing entropy but cannot amplify entropy. In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value,and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. Applications interested in a password-based KDF should consider whether, for example, [PKCS5] meets their needs better than HKDF.
  - leetbulb 8y ago
    Ah, excuse my skimming. I wasn't aware it was being generated from a password. :x
captn3m0 8y ago
I had another question regarding encryption of secrets. The reason you've mentioned is to prevent secrets from remaining in plain-text either during transmission to/from etcd or within etcd at rest. Did you consider using https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-... instead? It has been there for quite some time (1.10 I think) and fixes all your concerns. (We had similar issues with storing secrets in etcd, and went with k8s encryption instead).

https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2 Again, I'm not a cryptographer, and PBKDF2 is just an example. I would try to consult someone with a heavier background in the field. I've used PBKDF2 and Scrypt before, Argon2 is the newest, but also therefor least battle-tested. https://godoc.org/golang.org/x/crypto/pbkdf2 https://godoc.org/golang.org/x/crypto/pbkdf2 https://godoc.org/golang.org/x/crypto/argon2 https://godoc.org/golang.org/x/crypto/argon2 https://godoc.org/golang.org/x/crypto/scrypt https://godoc.org/golang.org/x/crypto/scrypt

leetbulb 8y ago

There's an RFC for that: https://tools.ietf.org/html/rfc5869 https://tools.ietf.org/html/rfc5869 Doesn't look like the Go API[1] allows you to specify an output key material length, so you'd just truncate or iterate until you get however much material you need (The HKDF Wiki implementation does this[2]). 1: https://godoc.org/golang.org/x/crypto/hkdf https://godoc.org/golang.org/x/crypto/hkdf 2: https://en.wikipedia.org/wiki/HKDF#Example:_Python_implementation https://en.wikipedia.org/wiki/HKDF#Example:_Python_implement...

throwaway_129 8y ago
You don't want to generate key material from a password with hkdf. From the RFC: On the other hand, it is anticipated that some applications will not be able to use HKDF "as-is" due to specific operational requirements, or will be able to use it but without the full benefits of the scheme. One significant example is the derivation of cryptographic keys from a source of low entropy, such as a user's password. The extract step in HKDF can concentrate existing entropy but cannot amplify entropy. In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value,and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. Applications interested in a password-based KDF should consider whether, for example, [PKCS5] meets their needs better than HKDF.
- leetbulb 8y ago
  Ah, excuse my skimming. I wasn't aware it was being generated from a password. :x

captn3m0 8y ago

I had another question regarding encryption of secrets. The reason you've mentioned is to prevent secrets from remaining in plain-text either during transmission to/from etcd or within etcd at rest. Did you consider using https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-... instead? It has been there for quite some time (1.10 I think) and fixes all your concerns. (We had similar issues with storing secrets in etcd, and went with k8s encryption instead).