IssueTracker

8 months later, this issue has more stars (currently 45) than all other issues for this component, combined. It is currently also the highest priority issue (P2) for component 907884. Would it be possible to get an update here so that developers can better understand the roadmap?

Specifically, the docs state:

If you're currently using SharedPreferences to store data, consider migrating to DataStore instead.

As a developer, I'd like to understand how the DataStore library compares to EncryptedSharedPreferences and which should be the preferred choice, going forward. Using typed objects for key-value storage is nice. Having data encrypted at rest, is ideal--and in my particular case, required by the Security Team. Can we expect DataStore to do both? If so, it would be VERY useful. If not, many developers will have to choose EncryptedSharedPreferences, instead.

If only EncryptedFile was a subclass of File or DataStoreFactory::create had an overload with a produceEncryptedFile parameter... Looking forward to a solution for this. Thanks!

I wrote a quick wrapper that uses EncryptedFile as the storage for data store. Code is based on the FileStorage from the library itself

https://gist.github.com/NicolaVerbeeck/4bb3e29915619a73a4c555291cbf653a

Example usage:

    @Provides
    @Singleton
    fun providePreferencesStorage(@ApplicationContext context: Context): Storage<Preferences> {
        return EncryptedFileStorage(context, FilePreferencesSerializer()) {
            File(context.filesDir, "preferences.pb")
        }
    }

Disregard my comment above, this does not work yet, still debugging

Gist has been updated, seems to work perfectly

You beat me by a moment :)

I've just released the new version of my tiny library adding datastore creation with EncryptedFile - https://github.com/osipxd/encrypted-datastore (to survive until Google will release an official encryption implementation). This library provides extensions DataStoreFactory.createEncrypted and PreferenceDataStoreFactory.createEncrypted.

Usage:

val dataStore = DataStoreFactory.createEncrypted(serializer) {
    EncryptedFile.Builder(
        context.dataStoreFile("filename"),
        context,
        MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC),
        EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
    ).build()
}

Or even simpler, if you use security-crypto-ktx:1.1.0:

val dataStore = DataStoreFactory.createEncrypted(serializer) {
    EncryptedFile(
        context = context,
        file = context.dataStoreFile("filename"),
        masterKey = MasterKey(context)
    )
}

It works with datastore 1.0.0, but I've not tested it with 1.1.0

Thanks to @os...@gmail.com for creating his extensions to use while we wait for this feature to be implemented. Otherwise I'd have to use encryptedsharedpreferences.

+1, please!

For now, I will keep using EncryptedSharedPreferences because it supports encryption and, during my tests, it seems more reliable, but I would like to use DataStore and take advantage of thread and type safety.

An official support of DataStore with encryption would be greatly appreciated :)

This would certainly encourage switching from the EncrypredSharedPreferences

+1

I can see v1.1.0 exposes a "new Storage interface". Will there be an official EncryptedFileStorage (or similar) or are we expected to implement encryption ourselves?

Now that androidx.security:security-crypto – which provides EncryptedSharedPreferences – was silently deprecated, it would be really nice if we get an encrypted DataStore via the Storage interface that comment #40 mentioned 🙂

633 stars, and no response from Google. Status is still at New, no one cares

+1

+1

+1

I am the author of the blog post that was kindly linked in comment #47. I would highly recommend reading the 'Why NOT JetSec Crypto in 2024?' section of that post as it might help in deciding whether this is really a feature that is needed. I would probably argue for 99 cases out of 100, no. It isn't.

Like ShredPreferences, data saved within DataStore is stored on the device within the app’s own sandboxed folder structure which is not accessible by default. Additionally, all devices encrypt user data on the filesystem by default as Android version 10 I believe - so what value would further encrypting your DataStore's values really add? If you are storing data that is 'sensitive' locally on the device, then perhaps you have bigger problems to worry about :-P

While I of course do not claim to represent anyone from Google, I believe this is likely also the same view taken by the JetSec team. Hence the deprecation of EncryptedSharedPreferences and the lack of a DataStore equivalent.

The TL;DR is: I'd say Android is likely plenty secure enough for almost every use-case to not need this feature and, as developers, its far better to just follow general security best practices (i.e. DO NOT store personal data on-device)

Happy new year! 735 stars and counting, and still no response from Google