AES GCM SIV is not working properly on android API version 29 and older. #18
Assignees
Comments
copybara-service bot
pushed a commit
that referenced
this issue
Nov 21, 2023
…21 - 29. Also, add a test that show issue #18. PiperOrigin-RevId: 584281559 Change-Id: I582216e461b90c4a15618641f26050ba9931da40
copybara-service bot
pushed a commit
that referenced
this issue
Nov 22, 2023
Also, add a test that show issue #18. PiperOrigin-RevId: 584671638 Change-Id: If4e6ac36f624717f0cebafedcb360aaa54a9563d
copybara-service bot
pushed a commit
that referenced
this issue
Nov 27, 2023
This resolved the issue: #18. #tinkApiChange Encryption and decryption with AES GCM SIV on Android API versions 29 and older will now fail, instead of using the wrong algorithm. For each thread this primitive is used with, a decryption will be run to validate the cipher. We don't expect this to be a big performance penalty, as creating and starting a thread will be more costly than this additional check. This check could also be done on initialization of the class, or on creation of the object. But I'm worried that this might cause problems in rare cases when initialization is done before AES GCM SIV is registered. So I prefer not to do this. This could be solved in a completely different way, by checking the state of the system (for example, which android version is used, or which provides are available). But I think such an approach would be more brittle than this solution here. PiperOrigin-RevId: 585546163 Change-Id: I457ea40b21cf702688c9b29e4a9e286428bf0a39
tholenst
pushed a commit
to tink-crypto/tink
that referenced
this issue
Dec 4, 2023
…21 - 29. Also, add a test that show issue tink-crypto/tink-java#18. PiperOrigin-RevId: 584281559
tholenst
pushed a commit
to tink-crypto/tink
that referenced
this issue
Dec 4, 2023
Also, add a test that show issue tink-crypto/tink-java#18. PiperOrigin-RevId: 584671638
tholenst
pushed a commit
to tink-crypto/tink
that referenced
this issue
Dec 4, 2023
This resolved the issue: tink-crypto/tink-java#18. #tinkApiChange Encryption and decryption with AES GCM SIV on Android API versions 29 and older will now fail, instead of using the wrong algorithm. For each thread this primitive is used with, a decryption will be run to validate the cipher. We don't expect this to be a big performance penalty, as creating and starting a thread will be more costly than this additional check. This check could also be done on initialization of the class, or on creation of the object. But I'm worried that this might cause problems in rare cases when initialization is done before AES GCM SIV is registered. So I prefer not to do this. This could be solved in a completely different way, by checking the state of the system (for example, which android version is used, or which provides are available). But I think such an approach would be more brittle than this solution here. PiperOrigin-RevId: 585546163
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using AES GCM SIV keys under android using the API version 29 or older, then primitive returned by Tink doesn't use AES GCM SIV, but uses AES GCM.
This is due to a bug in Android that was fixed here:
https://android.googlesource.com/platform/external/bouncycastle/+/14ceec126e49f2f4748f0d540be820515cc725a6.
We will fix this by adding a check and returning an error if AES GCM SIV is used on android 29 or older.
If this causes an issue for you, let us know.
The text was updated successfully, but these errors were encountered: