Bake key lengths into protocol buffer logic.

[cjpatton]

keys.go defines three constants:

const aesKeySize = 32 // 256-bit AES
const deriverSecretSize = 32
const hmacKeySize = 32 // SHA-256

These values need to be conveyed by the protocol buffers so that programs outside of the Go codebase can generate keys correctly. The algorithm used depends on this value. For example aesKeySize=32 entails AES256-CTR mode encryption. In this case I think the blockcipher (AES128 or AES256) should be specified in the protocol buffer in some way. In particular change enum CryptoCipherMode to CryptoEncryptionMode and make a new enum CryptoBlockcipher with values AES128 and AES256.

Similarly for HMAC we should specify the hash function. Make a new enum CryptoHash with values SHA256 and SHA1 (although I don't think we use SHA1 anywhere, do we?).

[tmroeder]

I agree with the sentiment about adding cipher-suite information to the protocol buffers. It's there in some places and not in others: e.g., PBEData does contain a more complete specification of the algorithm types.

However, following the lead of other crypto implementations (like TLS), I think the cipher suites in CryptoAlgorithm should each be a single entity, like AES256_CTR_HMAC_SHA256. This allows us to support only a small number of algorithms that we think are reasonable.

There is some inconsistency in keys.proto around this: for example, CryptoCipherMode has CTR mode as its only option, but the message that contains it is already specific to CTR mode (AES_CTR_HMAC_SHA_CryptingKey_v1). So, I think there's some work to do to normalize all of this and add the extra information.

BTW, it looks like the initial issue text was cut off. What is the proposal for proto/keys.proto?

[cjpatton]

Sounds good to me.