yandextaxitech/binaryprefs

🐞Bug with encryption

Fi5t opened this issue · 3 comments

Fi5t commented

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?

Fi5t commented

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