ovotech / mantle Goto Github PK

...so users can get a new ciphertext, without worrying about the plaintext at all

We should probably remove any command help snippets as they're like to be modified or have new additions at some point.

Also worth adding a section about how to contribute.

..so it can be used in other programs without anything being written to file.

...remove panic'ing, just return errors instead

aes-256-gcm-kms.exe encrypt "projects//locations//keyRings//cryptoKeys//cryptoKeyVersions/"

..it's being called with the chunk of encrypted bytes that's already been pulled out of the full ciphertext (which is the purpose of the PlainText() func):

https://github.com/ovotech/mantle/blob/8a507d829d669c53e8ec6b447847f14bf9047d27/crypt/decrypt.go#L50:L51

	plaintext, err := PlainText(x.Filepath)
	checkCipherTextLength(plaintext)

this is causing the panic: 'CipherText was shorter than the smallest possible generated CipherText' when the chunk of encrypted bytes happens to be shorter than 124 bytes (completely valid if the plaintext happens to be small).

checkCipherTextLength() needs to be called on the full ciphertext, instead.

I think more information on the IV (such as how + how often it's created) would be good for some users who're concerned with that.

Include Apache headers on every source file

At the moment, encrypt/decrypt is done by passing in a filepath string

Refactoring will allow code to be used as a dependency as opposed to just as a binary.

..as main packages can't be imported by users of the tool as a dependency.

This will make decrypting in Kubernetes init-containers simpler, as there'll be 3 x volumes involved otherwise; one that has the ciphertext (and is RO), one intermediary for the plain.txt that comes out, and a third for the emptyDir that's shared across the init-container and the app-container

..it'd make decrypting/encrypting multiple things at once possible

is this worth it?

This looks like a very interesting tool. Although I don't know Go I'm looking forward to investigating and using it. There is no rationale or motivation for why this tool exists in README.md, although of course there must be a good reason for its existence. What is this, and could we add it to the front page?

Validate ciphertexts before deleting plaintext. If validation fails, then bail out with an error.

This should help to avoid a flake where the user is left with no plaintext and a ciphertext that doesn't decrypt

Given a lot of files in a git repo (or any directory on a filesystem, for that matter) could be encrypted, it could be difficult to search through a dir for occurrences of a search string.

Currently users would have to script something themselves to decrypt everything, and then search through that.

Need to make sure it's definitely worth doing in this encryption tool, and be mindful of load on the KMS service (there'll be a call to Google KMS for each file decrypted)

https://github.com/nouney/helm-gcs/blob/master/.travis.yml contains some decent details of tools that could be used.

124 is the length of the encrypted DEK (always) + nonce, therefore the ciphertext should be longer than 124, and we could fail quickly with a good error msg when this is not the case.

Sometime between June 5th & July 8th, GCP must have updated Google KMS in some way, causing the 32 byte array (representing the DEK) we pass to them to be encrypted into a 114 char string. Prior to their change, it was returned as 113 chars.

Given that the chars received back from Google KMS are appended to the end of Mantle's ciphertexts, it then broke all decryption with 400 errors back from the Google api.

A kludge was put in place in Mantle to handle ciphertexts with both 113 and 114 char encrypted DEKs.

This exposed the fact that the decryption process is dependent on the length of the Google KMS ciphertexts, which is really bad.

We need to remove this dependency. Right now, the only solution I can come up with is to include the length of the Google KMS ciphertext in Mantle's ciphertext (would have to be in plaintext, as Google KMS decrypt is the first step). I don't think this would any impact on security.

Back compat would be needed for any Mantle ciphertexts that didn't have this DEK size included.

It'd be great to be able to verify whether an encrypted string is correct.

This should be possible just by running decrypt

It might be useful if multiple status codes are returned, e.g.:

• 0: successful lint
• 1: failed lint
• 2: other error (prevented lint)

key name, all one string, can be provided, making it easier for the user (since the key name can be obtained from gcloud/console) and easier for aes-256-gcm-kms as it won't have to rebuild it using various strings.

e.g.

gcloud kms keys list --location europe-west2 --keyring <removed>

NAME                                                          PURPOSE          LABELS  PRIMARY_ID  PRIMARY_STATE
projects/<removed>/locations/europe-west2/keyRings/<removed>/cryptoKeys/<removed>  ENCRYPT_DECRYPT          2           ENABLED

key name string would be:

projects/<removed>/locations/europe-west2/keyRings/<removed>/cryptoKeys/<removed>