-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws kms decrypt InvalidCiphertextException error #1043
Comments
Just a little background info on what's going on: In 1.6.6, we fixed a regression in which we were not base64 encoding "blob" types that we had previously been encoding. As a result, you now need to specify the raw binary bytes for any parameter marked as a "blob" type, and internally we will automatically base64 encode it for you. This means that to round trip key encryption you'll need to decode the base64 first:
In this example, I'm also using the |
I believe the behavior should remain as is. Given that the behavior in this initial issue relied on a regression in 1.6.5 that was fixed in 1.6.6, we really can't change the pre-existing behavior, as that would be a breaking change for customers. The example snippet above is the expected way to handle binary input/output in the AWS CLI, and except for this recent regression, is the way this behavior has always been. |
Thanks for the update! |
Actually, now I'm getting an error similar to issue #1001
|
@mtougeron What version of the AWS CLI are you using? I just tried again on the latest version of the AWS CLI (1.6.8) and I'm not seeing this issue:
|
@jamesls it works now in 1.6.8. thanks |
@jamesls personally I think this is incredibly bad UI. Not being able to pass the same ciphertext into decrypt that you got from encrypt? If you can't change it because you don't want to break existing customers, at least give them a better error message.
Doesn't even remotely tell me what to do to fix the problem. You could detect that the cipher is probably Base64 and output a better error and point them to a URL or something. |
Or heck why not pass an additional flag to |
For those who come to this later, in order to do this without saving the ciphertext to a file, you can do:
Note: as pointed out by @hauntingEcho below, the |
Re: @thegranddesign's comment, on OS X at least I had to use a capital 'D' for
(Not sure why I get a newline before the |
This worked for me
|
I had a similar issue, but Node helped:
|
another note on @thegranddesign 's solution - |
This is a mindbogglingly dumb bug that really ought to still be open until it is actually fixed. It is a giant anti-pattern to build a tool that performs a symmetric operation that uses one format for output and a completely different (and incompatible) format for input. A symmetric tool that cannot consume its own output as input is BROKEN. I don't care if it is actually working as intended, it is still broken. The tool should either generate raw binary output by default if it is dependent on raw binary input, or else it damn well ought to be able to consume base64 encoded input THAT IT GENERATED without specifying any explicit base64 decode steps or special params that weren't also required in order to generate that output (or an anti-param if it doesn't use the same exact param). It is beyond absurd that I can use aws kms encrypt to generate base64 encoded output of a base64 encoded encryption payload without specifying EITHER of those base64 encodings, but then I have to explicitly base64 decode both the encrypted data AND the decrypted data in order to get it back to the form I provided in the first place. The fact that doing so also requires the use of command line params that aren't even documented at the level of the encrypt and decrypt subcommands makes it that much more difficult to figure out. Users are all but guaranteed to waste hours trying to figure out how to do the single most obvious thing someone might want to do with an encryption/decryption client - encrypt and then decrypt a string specified in a command line param - and entirely because the tool has a broken operating mode where outputs aren't compatible with inputs despite the fact that the two sub-commands are supposed to be symmetric. Closing this without fixing it states that you have absolutely no concern for usability or developer efficiency. |
another path to resolve this (as opposed to new flags, as @thegranddesign mentioned years ago) could be that
Agreed with @sgendler-stem though - this ticket is linked in every project I've worked on which uses KMS, because it's always a problem for someone trying to get on board. |
I have to completely agree with @sgendler-stem - if the code generates an output it should be, at least, able to take that as input. However, there is more to that. If the ecryption is done through the SDK - adding a weird |
Agreed again. This has made things unnecessarily frustrating. |
This is actually closed? Why? I can't believe it's been 4 years since this opened and the only feedback seems to be somebody saying "works as intended". No it fucking doesn't; @sgendler-stem is right on target, this is completely broken. Hope the team responsible feels bad about themselves. |
Face the same exceptions: Used: |
I think this wouldn't be so frustrating if the output of If the flag to |
There's a feature proposal for base64-encoded input to decrypt over here #2063 |
How does kms know which encryption key to use for decryption, since we are not passing key-id as a parameter while decrypting. |
@arpit728 I think that CipherTextBlob returned is particular about the KeyID of a particular CMK. |
Please reopen this ticket until it is resolved! |
played too many hours with this until found this ticket. is there any official documentation which states how exactly things should be coded and transformed between encrypt and decrypt? |
this example returns: An error occurred (InvalidCiphertextException) when calling the Decrypt operation: `aws kms encrypt --key-id arn:aws:kms:eu-west-1werwerwjl:key/xxxyyyy --plaintext "abcd" --query CiphertextBlob --output text | base64 -d > ./encrypted-file echo "Decrypted: $(aws kms decrypt --ciphertext-blob fileb:./encrypted-file --query Plaintext --output text | base64 --decode)" EDIT: got encrypt and decrypt working using tips from this article: https://dev.to/matchilling/pragmatically-storing-security-sensitive-data-using-aws-kms-5e5b |
FYI, the above link doesn't work, but the article seems pretty useful and is available here. |
I upgraded to version 1.6.6 of the awscli today and aws kms decrypt started failing on decryption. It works in 1.6.5.
The text was updated successfully, but these errors were encountered: