Closed MrMarvin closed 3 months ago
It doesn't seem crazy on its face but I kind of wonder if we're solving the problem in the wrong place here, and if caring about this just indicates that we should put more pressure on a move to Hashicorp Vault or something like that.
If we would do this, and unless we're re-encrypt ejson in every repo, it would only apply to new secrets anyway.
I'm not fundamentally against this change, if it's generally seen as the right path forward for now, though I don't feel comfortable asserting that this is a reasonable thing to do security-wise.
Also, not pointing at anything in particular here, but just to remind for future discussion, this repo is public.
Although scrypt is cryptographically strong, it has fundamentally different security properties than a cipher. In particular, it's possible to check whether a given plaintext is the correct one simply by hashing it. This implies that low-entropy values cannot be protected by scrypt (or any other hashing function), since they can be brute-forced. If we add a hash alongside each encrypted secret, then we'd be transforming ejson from a tool that can safely encrypt any secret to one that can only safely encrypt high-entropy secrets. To me that seems like a large sacrifice.
Greetings from the future: this is very stale, has conflicts and never progressed from a draft.
I'm going to close it.
Rationale
With an ever growing collection of ejson documents across multiple repositories, managed by various teams, the burden to manage recurring (i.e. same secret in more than one file) seems to outweigh the benefits of having individual and completely unrelated cipher texts per encryption operation.
Example
Given an existing ejson document
if we would be asked to rotate the
database_password
, because there is the suspicion of it having leaked or due to other policies or requirements, there is currently no way (for anyone without access to the private key) to notice that the very same secret is also used forotherbase_password
. This can get especially tiresome if those two secrets are not within the same file, but in different files across a system landscape.With the proposed new field added to the cipher text wire format, it becomes trivial to check for duplicate secret usage.
Instead of the context dependent and vague "please rotate the
database_password
!", this allows very clear instructions, such asThis opens possibilities for a centralised entity to grep for a known bad identifier across a collection of ejson documents and mass-open change requests to affected users, without having access to the respective private keys.
Notes and assumptions about security implications of this change
The new identity field uses one of the strongest, widely adapted cryptographic hash functions - scrypt. Reasons this was chosen:
2**15
in this applicationStill, it introduces an additional representation of the plain text value, and gives attackers the freedom to chose to either attack the hash sum or the existing NaCl box.
I was unable to find a reasonable comparison of overall cryptographic strength between the two operations - mostly because they serve to very different applications. To my understanding both can be considered state of the art today.
Note
Documentation for scrypt implementations urge the user to chose "a good random salt". For our use case, we cannot add a per-secret salt to the hash, as this would defeat the purpose of having it uniquely identifiable across multiple files.
Implications for existing usages of ejson
The change of the wire format is introduced in a backwards compatible way. Ejson will be able to decrypt both schema version 1 and schema version 2 encrypted documents. It will output schema version 2 documents, including the new field per default.
I'd like to discuss if this an acceptable way forward, or if we should introduce an additional command line argument that can toggle between the old and the new behaviour for example. I do realise that this change might not be favourable to all users, as many will have different requirements for their secrets storage solution. There is some more work to be done within the included documentation that is dependent on the outcome of above discussion.