- brings Java KeysetManager functions to Go: Add, Enable, Disable, Delete, Destroy and SetPrimary
- updates Rotate docs to 'Deprecated' point to Add & SetPrimary
- mostly copies same Java tests/assertions

Coming from Tink 1.3.0 stable to Tink 1.4 RC2 (on Android), I noticed that the AesGcmKeyFormat has a possible problem with proguard/R8. We haven't added anything in our proguard-rules.pro file for Tink and am getting a stack trace like this

java.lang.NoClassDefFoundError: com.google.crypto.tink.aead.AeadKeyTemplates
	... 13 more
Caused by: java.lang.NoClassDefFoundError: com.google.crypto.tink.aead.AeadKeyTemplates
	at slack.commons.security.AeadPrimitiveFactoryImpl.getAeadPrimitive(AeadPrimitiveFactory.kt:4)
	... 12 more
Caused by: java.lang.ExceptionInInitializerError
	at androidx.security.crypto.EncryptedSharedPreferences$PrefValueEncryptionScheme.
<clinit>(EncryptedSharedPreferences.java:1)
        ... 11 more
Caused by: java.lang.RuntimeException: Field version_ for com.google.crypto.tink.proto.AesGcmKeyFormat not found. Known fields are [public int com.google.crypto.tink.proto.AesGcmKeyFormat.keySize_, public static final com.google.crypto.tink.proto.AesGcmKeyFormat com.google.crypto.tink.proto.AesGcmKeyFormat.DEFAULT_INSTANCE, public static volatile com.google.crypto.tink.shaded.protobuf.Parser com.google.crypto.tink.proto.AesGcmKeyFormat.PARSER]
	at com.google.crypto.tink.shaded.protobuf.MessageSchema.reflectField(MessageSchema.java:7)
	at com.google.crypto.tink.shaded.protobuf.MessageSchema.newSchemaForRawMessageInfo(MessageSchema.java:53)
	at com.google.crypto.tink.shaded.protobuf.MessageSchema.newSchema(MessageSchema.java:2)
	at com.google.crypto.tink.shaded.protobuf.Protobuf.schemaFor(Protobuf.java:30)
	at com.google.crypto.tink.shaded.protobuf.Protobuf.schemaFor(Protobuf.java:48)
	at com.google.crypto.tink.shaded.protobuf.GeneratedMessageLite$Builder.buildPartial(GeneratedMessageLite.java:5)
	at com.google.crypto.tink.shaded.protobuf.GeneratedMessageLite$Builder.build(GeneratedMessageLite.java:1)
	at com.google.crypto.tink.aead.AeadKeyTemplates.createAesGcmKeyTemplate(AeadKeyTemplates.java:5)
	at com.google.crypto.tink.aead.AeadKeyTemplates.<clinit>(AeadKeyTemplates.java:1)

In the Android studio looking at the generated AesGcmKeyFormat, it has the _version

package com.google.crypto.tink.proto;

import ...;

public final class AesGcmKeyFormat extends GeneratedMessageLite<AesGcmKeyFormat, AesGcmKeyFormat.Builder> implements AesGcmKeyFormatOrBuilder {
    public static final int KEY_SIZE_FIELD_NUMBER = 2;
    private int keySize_;
    public static final int VERSION_FIELD_NUMBER = 3;
    private int version_;
    private static final AesGcmKeyFormat DEFAULT_INSTANCE;
    private static volatile Parser<AesGcmKeyFormat> PARSER;

...
}

But when looking at the build APK with proguard/R8 running through it, seems like version_ was removed

Seems like the AesSivKeyFormat has a similar problem as well.

I'm going to also check if this problem might have existed in the 1.3 release of the library. But I haven't seen this stack trace before.

We stricly use protobuf 3.12.0

+--- com.google.protobuf:protobuf-java:{strictly 3.12.0} -> 3.12.0 (c)

...

|    |    \--- com.google.protobuf:protobuf-javalite:3.12.0

...

|    |    +--- com.google.android.apps.common.testing.accessibility.framework:accessibility-test-framework:2.1
|    |    |    +--- org.hamcrest:hamcrest-core:1.3 -> org.hamcrest:hamcrest:2.2
|    |    |    \--- com.google.protobuf:protobuf-java:2.6.1 -> 3.12.0

I intend to follow this up with a pull request.

Would the Tink team be interested in a PHP implementation of the same API? Obtensibly it would wrap both the openssl and sodium extensions.

Is there any update on the release date for a version of Tink that supports Python? The roadmap states August 2019 as the intended date and that has come and gone...!

It'd be good to have access to a release with Python support before January 2020 so old Python2 projects with Keyczar in can be migrated over to Python3 projects with Tink.

Alternatively, if anybody has a suggestion for a suitable Python3 library to replace Keyczar in Python2 , that would be greatly appreciated!

Regards,

Jordan

we use Tink-Android to generate keyPair and sign our information. it work well in common case. but there is a crash in Android device M1 E when we use

Ed25519Sign(private_key)

and we find the throwable is

   // This check is to protect against flaws, i.e. if there is a computation error through a
    // faulty CPU or if the implementation contains a bug.
    XYZ result = new XYZ(ret);
    if (!result.isOnCurve()) {
      throw new IllegalStateException("arithmetic error in scalar multiplication");
    }

https://github.com/google/tink/blob/09fc71c45dc7c4ecc7fb0df3414b0fb3a9ca52c3/java/src/main/java/com/google/crypto/tink/subtle/Ed25519.java#L626

Android version: 7.0 cpu: Helio P10 gpu: ARM Mali-T860 Tink-Android Version: 1.2.2

Is there anyone can help me ? thanks !

Hello,

I'd like to report the follow exceptions happening with Android; we are using 1.3.0-rc3. I am not able to reproduce these issues; however they have been seen in the wild.

OS Issue observed : Android 6,7,8,9 Devices : Samsung Galaxy S6, S7 edge. LG g4, g5, g6

KeyStoreException (Invalid Key Blob) with stack trace :

android.security.KeyStore.getKeyStoreException (KeyStore.java:708) android.security.keystore.AndroidKeyStoreProvider.loadAndroidKeyStoreSecretKeyFromKeystore (AndroidKeyStoreProvider.java:283) android.security.keystore.AndroidKeyStoreSpi.engineGetKey (AndroidKeyStoreSpi.java:98) java.security.KeyStore.getKey (KeyStore.java:1062) com.google.crypto.tink.integration.android.AndroidKeystoreAesGcm. (AndroidKeystoreAesGcm.java:48) com.google.crypto.tink.integration.android.AndroidKeystoreKmsClient.getAead (AndroidKeystoreKmsClient.java:111) com.google.crypto.tink.integration.android.AndroidKeystoreKmsClient.getOrGenerateNewAeadKey (AndroidKeystoreKmsClient.java:130) com.google.crypto.tink.integration.android.AndroidKeysetManager. (AndroidKeysetManager.java:118) com.google.crypto.tink.integration.android.AndroidKeysetManager. (AndroidKeysetManager.java:88) com.google.crypto.tink.integration.android.AndroidKeysetManager$Builder.build (AndroidKeysetManager.java:185) com.loblaw.pcoptimum.android.app.utils.Crypto$AEAD.getAndroidKeysetManager (Crypto.java:204)

KeyStoreException (Unknown error) with stack trace :

android.security.KeyStore.getKeyStoreException (KeyStore.java:1107) android.security.keystore.AndroidKeyStoreProvider.loadAndroidKeyStoreSecretKeyFromKeystore (AndroidKeyStoreProvider.java:283) android.security.keystore.AndroidKeyStoreSpi.engineGetKey (AndroidKeyStoreSpi.java:98) java.security.KeyStore.getKey (KeyStore.java:825) com.google.crypto.tink.integration.android.AndroidKeystoreAesGcm. (AndroidKeystoreAesGcm.java:48) com.google.crypto.tink.integration.android.AndroidKeystoreKmsClient.getAead (AndroidKeystoreKmsClient.java:111) com.google.crypto.tink.integration.android.AndroidKeystoreKmsClient.getOrGenerateNewAeadKey (AndroidKeystoreKmsClient.java:130) com.google.crypto.tink.integration.android.AndroidKeysetManager. (AndroidKeysetManager.java:118) com.google.crypto.tink.integration.android.AndroidKeysetManager. (AndroidKeysetManager.java:88) com.google.crypto.tink.integration.android.AndroidKeysetManager$Builder.build (AndroidKeysetManager.java:185)

UnrecoverableKeyException (-49) with stack trace :

android.security.KeyStore.getKeyStoreException (KeyStore.java:839) android.security.keystore.AndroidKeyStoreProvider.getKeyCharacteristics (AndroidKeyStoreProvider.java:236) android.security.keystore.AndroidKeyStoreProvider.loadAndroidKeyStoreKeyFromKeystore (AndroidKeyStoreProvider.java:356) android.security.keystore.AndroidKeyStoreSpi.engineGetKey (AndroidKeyStoreSpi.java:101) java.security.KeyStore.getKey (KeyStore.java:1062) com.google.crypto.tink.integration.android.AndroidKeystoreAesGcm. (AndroidKeystoreAesGcm.java:48) com.google.crypto.tink.integration.android.AndroidKeystoreKmsClient.getAead (AndroidKeystoreKmsClient.java:111) com.google.crypto.tink.integration.android.AndroidKeystoreKmsClient.getOrGenerateNewAeadKey (AndroidKeystoreKmsClient.java:130) com.google.crypto.tink.integration.android.AndroidKeysetManager. (AndroidKeysetManager.java:118) com.google.crypto.tink.integration.android.AndroidKeysetManager. (AndroidKeysetManager.java:88) com.google.crypto.tink.integration.android.AndroidKeysetManager$Builder.build (AndroidKeysetManager.java:185)

GeneralSecurityException: decryption failed
  File "AeadWrapper.java", line 82, in decrypt
  File "TinkHelper.kt", line 33, in decrypt

This error occurs with version 1.3.0-rc1 on an Android device running 9.0 but is fixed in versino 1.3.0-rc4. We can't upgrade to 1.3.0-rc4 because of https://github.com/google/tink/issues/301.

Will the 1.3.0 release contain the fix for the decryption error but not the issue with firebase?

I am trying to integrate Tink to my Flutter app which also uses Firebase. With 1.3.0-rc3 I get this build errors in Android:

Execution failed for task ':app:checkDevelopmentDebugDuplicateClasses'.
> 1 exception was raised by workers:
  java.lang.RuntimeException: java.lang.RuntimeException: Duplicate class com.google.protobuf.AbstractMessageLite found in modules protobuf-javalite-3.10.0.jar (com.google.protobuf:protobuf-javalite:3.10.0) and protobuf-lite-3.0.1.jar (com.google.protobuf:protobuf-lite:3.0.1)
  Duplicate class com.google.protobuf.AbstractMessageLite$Builder found in modules protobuf-javalite-3.10.0.jar (com.google.protobuf:protobuf-javalite:3.10.0) and protobuf-lite-3.0.1.jar (com.google.protobuf:protobuf-lite:3.0.1)
  Duplicate class com.google.protobuf.AbstractMessageLite$Builder$LimitedInputStream found in modules protobuf-javalite-3.10.0.jar (com.google.protobuf:protobuf-javalite:3.10.0) and protobuf-lite-3.0.1.jar (com.google.protobuf:protobuf-lite:3.0.1)
  Duplicate class com.google.protobuf.AbstractParser found in modules protobuf-javalite-3.10.0.jar (com.google.protobuf:protobuf-javalite:3.10.0) and protobuf-lite-3.0.1.jar (com.google.protobuf:protobuf-lite:3.0.1)
  Duplicate class com.google.protobuf.AbstractProtobufList found in modules protobuf-javalite-3.10.0.jar (com.google.protobuf:protobuf-javalite:3.10.0) and protobuf-lite-3.0.1.jar (com.google.protobuf:protobuf-lite:3.0.1)
  Duplicate class com.google.protobuf.Any found in modules classes.jar (com.google.firebase:protolite-well-known-types:17.0.0) and protobuf-javalite-3.10.0.jar (com.google.protobuf:protobuf-javalite:3.10.0)
.
.
.

I have tried various suggestions mentioned in other protobuf related issues here but no solution found so far.

Issue disappears if I downgrade Tink to version 1.3.0-rc1, so I am using it as a workaround for now.

The go/keyset API is not present in the latest release, which causes problems when trying to use go modules:

GO111MODULE=on go get github.com/google/tink/go/keyset
go: finding github.com/google/tink/go/keyset latest
go: finding github.com/google/tink/go latest
go get github.com/google/tink/go/keyset: no matching versions for query "latest"

Hi,

Edit: we are using Tink 1.2.2.

We have been getting crash reports with the exception GeneralSecurityException: decryption failed with the stack trace pointing to AeadFactory::decrypt as the source of the exception, and we are lost on when that happens.

We are not sharing the keys or the cipher text, so, the same device and algorithm that encrypts it, is the same one that is decrypting it.

We are also using the AndroidKeysetManager.

The error seems to happen exclusively on Android 8 e 9 so far.

Any idea on what may be causing this exception being thrown? Thank you :)

Check our full implementation: https://gist.github.com/AllanHasegawa/85431b6f7c53074511527655712c9872

In my Android app, I see this exception happening on one device: Protocol message contained an invalid tag (zero)., com.google.crypto.tink.shaded.protobuf.InvalidProtocolBufferException

Related code where the exception happens (Kotlin code from my Flutter plugin):

.
.
.
"encryptString" -> {
    uiScope.launch {
        try {
            var encryptedDataBase64String: String? = null
            withContext(Dispatchers.IO) {
                initializeTink()

                val applicationId = call.argument<String>("applicationId")
                        ?: throw IllegalArgumentException("applicationId")
                val keySetName = call.argument<String>("keySetName")
                        ?: throw IllegalArgumentException("keySetName")
                val dataString = call.argument<String>("data")
                        ?: throw IllegalArgumentException("data")
                val passwordString = call.argument<String>("password")

                val data = dataString.toByteArray(Charsets.UTF_8)

                val password = passwordString!!.toByteArray(Charsets.UTF_8)

                val keySetHandle = getOrGenerateNewKeysetHandle(applicationContext!!, applicationId, keySetName)
                val aead = keySetHandle.getPrimitive(Aead::class.java)

                val encryptedData = aead.encrypt(data, password)

                encryptedDataBase64String = Base64.encodeToString(encryptedData, Base64.DEFAULT)
            }
            result.success(encryptedDataBase64String)
        } catch (e: Exception) {
            Log.e(LOG_TAG, "Exception", e)
            result.error(
                    "Exception",
                    e.localizedMessage ?: e.message ?: "$e", "$e")
        }
    }
}

Tink 1.4.0 Device: Huawei P20 / Android 10

This is an user device so I cannot reproduce it myself (I see this from Crashlytics).

Is your feature request related to a problem?

No

What sort of feature would you like to see?

I have a general question about using Tink and EnvelopeEncryption.

I tried the example GOLANG-HOWTO.md#envelope-encryption, it works great.

I wonder if it is possible, or if it is a roadmap feature to allow configuring reusing DEK for a set number of Encrypt() instead of creating a new DEK (and encrypted with remote KMS) for each Encrypt()

I understand the best practices is to use a new DEK for each message to encrypt. However past a certain volume, I am considering balancing cost and security. Each DEK are encrypted with remote KMS, for high volume message, the KMS cost becomes significant.

This feature would be very similar as the data key caching documented by AWS Encryption SDK DataKey Caching, ie allow configuring threshold to drive whether to re-use the DEK or not.

Have you considered any alternative solutions?

If this feature is not planned, i would really value pointers how best to customize tink to allow envelope encryption data key caching.

I am wondering if the best place to extend tink is creating a new Key Manager similar than kms_envelope_aead_key_manager.go and add some sort of cache around in a newer version of KMSEnvelopeAEAD where before we generate a new DEK we get one from a cache if the reuse threshold is acceptable.

Thanks! -seb

At first I tried bazel, but it seems its broken with the VS toolchain ( at least in versions 2017+ ).

So cmake it is. For a saner build environment, I use msys2.

msys2 includes a package manager 'pacman' for installing the dev tools and libraries required for building. Ensure you select the mingw variants of golang, gcc, and cmake, or you'll encounter build errors.

You can get a list of packages with: pacman -Ss <package_name>

For the most part, the build went well. It is missing unistd.h's 'pread' , and cc/util/util_test.cc makes use of file permissions not supported by Windows (specifically 'group' and 'other'). Those were the only two issues blocking compilation for me.

I was able to get the aead_cli example working. Here is the CMakeLists.txt I used to build my exe.

cmake_minimum_required(VERSION 3.5)
project(aead_cli CXX)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_STANDARD 14)

add_subdirectory(third_party/tink)
add_subdirectory(util)

add_executable(aead_cli aead_cli.cc)
set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static")
target_link_libraries(aead_cli tink::static absl::flags_parse util) 

There is an issue with it trying to link in librt on my setup, which doesn't fly for Windows. For the time being, I just delete the -lrt in build.ninja file after running cmake -DCMAKE_GENERATOR=ninja

I created a pull request #660 in case there's any interest by the tink devs.

I have a general question around best practices when dealing with multiple KEKs for envelope encryption.

Background We have a centralised security solution that handles encryption for various tenants. Each tenant has 1 GCP KMS Key dedicated to it. The purpose of having separate KMS Keys for each tenant is to ensure secure data isolation and limit risk in events where the key is compromised etc.. etc...

Scenario After securely identifying the tenant during a request, the centralised security solution picks the appropriate KEK (remote GCP KMS key) to process the request (i.e. encrypt the data). Specifically, it picks the right AEAD primitive instance that matches the tenant's KEK.

With the Google Tink Library, the example docs to generate an AEAD primitive is:

kekURI := "gcp-kms://.../.../.../my-cloud-kek-123"
kmsClient, err := gcpkms.NewClient(kekURI)
if err != nil {
...
}

registry.RegisterKMSClient(kmsClient)

dek := aead.AES256GCMKeyTemplate()
keyHandle, err := keyset.Handle(aead.KMSEnvelopeAEADKeyTemplate(kekURI)
if err != nil {
...
}

aeadPrimitive, err := aead.New(keyHandle)
if err != nil {
...
}


// We can finally use the AEAD primitive here for envelope encryption for a single KEK
aead.Encrypt(....)
aead.Decrypt(....)

Now the code example above works fine for a single KEK, however we'd like to support multiple KEKs and be able to dynamically switch KEKs depending on the requests the "centralised security solution" receives for each tenant.

N tenants = N KEK (GCP KMS keys)

Note: The list of tenants can grow over time, its not a static number (N).

The "centralised security solution" can receive concurrent requests (gRPC server) and must be able to handle concurrent requests without issues.

Our initial approach to the problem is shown below:

• we use sync.RWMutex to cache AEAD primitives
• we went with caching AEAD primitives, on the assumption that creating a new primitive every single time from the URI would be wasteful/expensive, even if we used GetKMSClient from the registry to cache atleast the kmsClient bit (i.e. we'd still need to generate the keyHandle and AEAD primitive, even if KMSClient is cached in registry)
• our cache is mostly read heavy (i.e. when the centralised security solution gRPC server boots up one more more instances - behind a load balancer - it would write to the cache once to initialise the AEAD primitive in cache, and then its purely reads from the cache going forward)
• cache key is tenant ID
• since sync.RWMutex supports multiple read locks, it would be ideal for a read heavy scenario

type TenantAEADCache struct {
    mu sync.RWMutex
    
    cache map[string]tink.AEAD
}

func (t *TenantAEADCache) GetAEADPrimitive(tenant string) (tink.AEAD, error) {
    aeadPrimitive, err := t.GetAEADPrimitiveFromCache(tenant)
    if err != nil {
        return t.GenerateAndGetAEADPrimitive(tenant)

    }
    return aeadPrimitive, err
}


func (t *TenantAEADCache) GetAEADPrimitiveFromCache(tenant string) (tink.AEAD, error) {
    // read lock
    t.mu.RLock()
    defer t.mu.RLock()
   
    aeadPrimitive, ok := t.cache[tenant]
    if !ok {
        return nil, errors.New("not cached")
    }
    return aeadPrimitive, nil
}

func (t *TenantAEADCache) GenerateAndGetAEADPrimitive(tenant string) (tink.AEAD, error) {
    // write lock
    t.mu.Lock()
    defer t.mu.Lock()

    t.cache[tenant] = .... // generate an AEADPrimitive in a similar way to the first code example at the top
    
    return t.cache[tenant], nil
}

(please ignore any minor code issues, this was not a copy pasted snippet, just a best effort manually typed example)

I'd like to learn about:

• whether this approach will have any concurrency issues with the Google Tink Library?
• whether the "registry" stuff could be of any help instead of the approach above?
• when using the AEAD primitive, does it perform any mutex locks within the Google Tink Library when calling the Encrypt/Decrypt methods (which could become a bottleneck for the approach mentioned above)

I've read through a bit of the code for KMSEnvelopeAEAD which seems to be the instance/concrete type of tink.AEAD that I'm working with. Would there be any locks or concurrency issues with the code below

https://github.com/google/tink/blob/master/go/aead/kms_envelope_aead.go#L59-L129

Alternatively, please let me know if there's a better approach to solving concurrent multi-tenant (multi KEK) envelope encryption with Google Tink.

Regards

Bumps certifi from 2022.9.24 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.