can't create keyset using tinkey and aws-kms in region other than us-east-1 about tink

[thaidn]

Thanks for the report.

@SalusaSecondus, you seem to work for AWS. Do you know what happened here? Thanks!

[SalusaSecondus]

@thaidn Glad to help here. I'm having some trouble navigating this project. Can you point me to where the AWSKMS client is actually constructed? I'll still keep poking, but that would save me some time.

[thaidn]

Thanks SalusaSecondus!

The AWS client is in https://github.com/google/tink/blob/master/java/src/main/java/com/google/crypto/tink/integration/awskms/AwsKmsClient.java.

[SalusaSecondus]

I ended up finding it. Thank you.

That construction will always point to a "default" region and in many cases that will just be "us-east-1". My recommendation is that you look at how we create clients in the KmsMasterKeyProvider in the aws-encryption-sdk-java.

Specific things which are likely to be helpful:

• getStartingRegion
• Our use of the client builder to spin off multiple clients for different regions (or with different credentials)

[thaidn]

Thanks SalusaSecondus.

While this looks easy to fix, and I'll fix it in our code, if the region is encoded in the key arn, why doesn't AWS KMS library automatically choose the right region?

[SalusaSecondus]

Generally the Java clients are relatively thin and are configured to speak with exactly one region. Having one automatically figure out the proper region in general is a hard problem. This is made worse because not every call has an explicit region in it (unlike the encrypt call). How should the client behave then?

For calls without an explicit region, should it go to the configured one at creation or the region specified by the most recently used explicit region? Now when you make a bunch of calls, some might go to different regions, and thus the results won't properly work between the calls. I agree that it causes confusion and can create issues, but we don't (currently) have a better way to handle this. Our regions are very strongly isolated and we do require developers to know which region they are interacting with.

[thaidn]

Thanks for the explanation. For KMS the region is embedded in the key arn, thus I thought that it should be easy for the KMS client to figure out which region it should talk to. But what you said made me realize that this is KMS specific, and might not work for other services.

@kevur fixing this turns out is harder than expected because one of our existing clients is using a quite old version of AWS SDK. I'm upgrading them now, but it might take a few more days. Sorry for the delay!

[k3vur]

@thaidn no problem or pressure whatsoever, I was able to have a hacky workaround for now (I'm on a groovy project, and groovy makes accessing the private AWSKMS client easier than it should be...). But thank you for your quick response and effort! Makes me more confident in having chosen google tink, and I look forward to not having to rely on said hacky hack.

[thaidn]

Thanks for choosing Tink. Just for your information, though Tink started as a personal project of the initial maintainers, we now have a dedicated team working full time on it (and Wycheproof). Our goal is to help everyone use crypto correctly everywhere. So if there's anything we can do, please let us know.

[thaidn]

Just a quick update: we may not be able to fix this post 1.2.0 launch. I still haven't figured out how to upgrade the AWS KMS client library in our internal repository.

I'll keep you posted on my progress.

[thaidn]

Please use https://github.com/google/tink/releases/tag/v1.2.1 which should fix this issue. Sorry again for the long delay.