Documentation on encryption context in contradiction with the behaviour?

Question

The AWS documentation on encryption context (  ) states that:  
  
_"When an encryption context is provided in an encryption request, it is cryptographically bound to the ciphertext such that the same encryption context is required to decrypt (or decrypt and re-encrypt) the data. If the encryption context provided in the decryption request is not an exact, case-sensitive match, the decrypt request fails."_  
  
In our case we have an SQS queue with encryption enabled and a lambda function triggered by messages arriving to the queue. In CloudTrail events for GenerateDataKey the encryption context contains the key "aws:sqs:arn" as expected:

```
"encryptionContext": {
    "aws:sqs:arn": "arn:aws:sqs:eu-west-1:accountnr:queuename"
},
```

However, Decrypt events in CloudTrail contain a very different encryption context:

```
"encryptionContext": {
    "aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:accountnr:function:functionname"
}
```

So, the contexts do not contain the same key in both cases, even though you would expect so, based on the above quoted sentence from AWS documentation. Also you would expect decrypting to have failed due to differing context but it seems to work just fine.  
  
Presumably I cannot use the same KMS key policy condition for readers and writers in this case to verify that "aws:sqs:arn" contains a specific value since the Decrypt context does not contain such key (?).  
  
Did I misunderstand the documentation sentence or why does it seem to work differently?

Answer

You are right, I should have checked the resource ARNs of the CloudTrail Decrypt events. The KMS key of the decrypt events with an unexpected encryption context is not the KMS key we use for SQS encryption. I was able to find a Decrypt event that has the expected encryption context (refers to our SQS queue) and the resource ARN of the correct KMS key. The majority of the decrypt events are of the wrong kind (i.e. decrypting environment variables), so every event I checked happened to be one of those. Thank you for your help!  
  
Edited by: tsillan on Aug 8, 2019 11:57 PM  
  
Edited by: tsillan on Aug 8, 2019 11:59 PM

Answer

Can you check to see if there is another CloudTrail event at a later time for decrypt using the encryption context you expect? It could be that you are also encrypting lambda environment variables and that is the event you are viewing.   
  
SQS has a data key reuse period - The length of time, in seconds, for which Amazon SQS can reuse a data key to encrypt or decrypt messages before calling AWS KMS again. An integer representing seconds, between 60 seconds (1 minute) and 86,400 seconds (24 hours). The default is 300 (5 minutes).   
  
You won’t see the decrypt from SQS right after the GenerateDataKey, since it still has the key cached locally based on the data key reuse period.

Documentation on encryption context in contradiction with the behaviour?

Relevant content