🐞Bug with encryption
Fi5t opened this issue · 3 comments
I faced a strange bug when tried to work with two instances of this shared preferences. I use Tink as an encryption engine with your library and want to show you some unexcepted behavior when they work together.
P.S. Sorry for the Kotlin :D
try {
TinkConfig.register()
} catch (e: GeneralSecurityException) {
throw RuntimeException(e)
}
val keysetHandle = AndroidKeysetManager.Builder()
.withSharedPref(this, KEYSET_NAME, PREFERENCE_FILE)
.withKeyTemplate(AeadKeyTemplates.AES256_GCM)
.withMasterKeyUri(MASTER_KEY_URI)
.build()
.keysetHandle
val aead = AeadFactory.getPrimitive(keysetHandle)
val bpInstance1 = BinaryPreferencesBuilder(this)
.name("main_file")
.valueEncryption(TinkValueEncryption(aead, "good_data".toByteArray()))
.build()
val bpInstance2 = BinaryPreferencesBuilder(this)
.name("main_file")
.valueEncryption(TinkValueEncryption(aead, "bad_data".toByteArray()))
.build()
bpInstance1.edit {
putString("my_key", "bug")
}
val result = bpInstance2.getString("my_key", "no bug")
I expect to see "GeneralSecurityException" or "no_bug" in the result
variable, but I see "bug" there. It's wrong behavior, because I set the different associated data for each instance. Any ideas?
I've prepared a repository to reproduce this bug. Please, check it out and tell me where I was wrong =)
Hey. Thank you for submitting the bug.
This behavior is expected.If you look at the code listing here https://github.com/yandextaxitech/binaryprefs/blob/master/library/src/main/java/com/ironz/binaryprefs/ParametersProvider.java#L17 then you'll see static caching. It's more efficient than using separate cache instances per preference instance.
Why do you think this is bug?
When the second instance can decrypt data of the first instance despite the fact that both of these instances have different additional data is a bug for me.
Got it. Lets discuss about in DM