concourse
--encryption-key and --old-encryption-key flags are interpreted as RAW bytes, limiting available entropy
Bug Report
(I apologize ahead if this should be better classified as a feature request, since this would requiring breaking compatibility or adding a new feature)
When parsing --encryption-key and --old-encryption-key, the provided string is just converted to raw bytes, instead of being parsed as base64 or hex as is usually the case with encryption keys. This means that some byte values (e.g. the NUL byte) can't be easily supplied, and other byte values (1-31, 127-255) are hard to supply in a consistent way. With only 95 safe character values per byte, we lose 1.5 bits of entropy on the byte, so a nominally 128-bit key will only have 104 bits of entropy available and a 256-bit key would have 208 bits of entropy.
Parsing keys as hex-encoded or base64-encoded values will easily solve the issue, but is going to break down backward compatibility quite spectacularly, so Concourse will need to support a new set of arguments, e.g. --encryption-key-hex and --old-encryption-key-hex or --encryption-key-base64 and --old-encryption-key-base64.
Hello from 2021!
Sometimes people like to use a file to store secrets in (e.g. docker secrets) and have an environment variable contain the path to the file instead of the secret itself, because environment variable values can end up being displayed in several places.
Maybe an easy-ish solution here is to provide a --encryption-key-file arg and CONCOURSE_ENCRYPTION_KEY_FILE variable, which if set, reads raw bytes from the file and uses that for the key? Then we don't have to worry about encodings, and we also keep the key value out of env vars/cmdline.
I don't know enough about encryption to comment on this, but it sounds like a reasonable thing that should be done at some point. Anyone is free to make a PR addressing this.
