patrickfav/armadillo

A shared preference implementation for confidential data in Android. Per default uses AES-GCM, BCrypt and HKDF as cryptographic primitives. Uses the concept of device fingerprinting combined with optional user provided passwords and strong password hashes.

Armadillo - Encrypted Shared Preference

A shared preference implementation for secret data providing confidentiality, integrity and authenticity. Per default uses AES-GCM, BCrypt and HKDF as cryptographic primitives.

Important Notice: If you migrate to v0.6.0 and use a user password and default key stretching function migration is needed due to a security issue. See migration guide in the changelog for v0.6.0

Features

• No-Nonse State-of-the-Art Crypto: Authenticated Encryption with AES-GCM, key derivation functions Bcrypt and HKDF
• Flexible: Tons of nobs and switches while having sane defaults
• Modular: use your own implementation of symmetric cipher, key stretching, data obfuscation, etc.
• Lightweight: No massive dependencies required like BouncyCastle or Facebook Conceal

Security Summary

• Using it with a user provided password (and strong password hash, like the default BCrypt): your data is strongly encrypted
• Using it without a user provided password: your data is obfuscated and cannot be easily altered or read by an attacker with access to the device
• By using fingerprinting, it is not easily possible to just copy data over to another device and use it there
• Encryption is non-deterministic, which means even if you encrypt the same data it appears to be different
• All encrypted data is protected against modification by an outside attacker, so long as the encryption itself is not circumvented
• The Android Keystore System is not used, since it proved to be unreliable and hard to handle in production due to device fragmentation and poor driver support (read more below). This implementation is a good fallback solution for a system that uses the aforementioned.

Quick Start

Add the following to your dependencies (add jcenter to your repositories if you haven't)

compile 'at.favre.lib:armadillo:x.y.z'

A very minimal example

SharedPreferences preferences = Armadillo.create(context, "myPrefs")
    .encryptionFingerprint(context)
    .build();

preferences.edit().putString("key1", "stringValue").commit();
String s = preferences.getString("key1", null);

Advanced Example

The following example shows some of the configurations available to the developer:

String userId = ...
SharedPreferences preferences = Armadillo.create(context, "myCustomPreferences")
        .password("mySuperSecretPassword".toCharArray()) //use user provided password
        .securityProvider(Security.getProvider("BC")) //use bouncy-castle security provider
        .keyStretchingFunction(new PBKDF2KeyStretcher()) //use PBKDF2 as user password kdf
        .contentKeyDigest(Bytes.from(getAndroidId(context)).array()) //use custom content key digest salt
        .secureRandom(new SecureRandom()) //provide your own secure random for salt/iv generation
        .encryptionFingerprint(context, userId.getBytes(StandardCharsets.UTF_8)) //add the user id to fingerprint
        .supportVerifyPassword(true) //enables optional password validation support `.isValidPassword()`
        .enableKitKatSupport(true) //enable optional kitkat support
        .enableDerivedPasswordCache(true) //enable caching for derived password making consecutive getters faster
        .build();

A xml file named like f1a4e61ffb59c6e6a3d6ceae9a20cb5726aade06.xml will be created with the resulting data looking something like that after the first put operation:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <!-- storage random salt -->
    <string name="585d6f0f415682ace841fb50d5980d60ed23a2ef">riIPjrL2WRfoh8QJXu7fWk4GGeAKlQoJl9ofABHZKlc=</string>
    <!-- 'key1':'stringValue' -->
    <string name="152b866fd2d63899678c21f247bb6df0d2e38072">AAAAABD/8an1zfovjJB/2MFOT9ncAAAAJaf+Z9xgzwXzp1BqTsVMnRZxR/HfRcO8lEhyKpL17QmZ5amwAYQ=</string>
</map>

KitKat Support

Unfortunately Android SDK 19 (KITKAT) does not fully support AES GCM mode. Therefore a backwards compatible implementation of AES using CBC with Encrypt-then-MAC can be used to support this library on older devices. This should provide the same security strength as the GCM version, however the support must be enabled manually:

SharedPreferences preferences = Armadillo.create(context, "myCustomPreferences")
        .enableKitKatSupport(true)
        ...
        .build();

In this mode, if on a KitKat device the backwards-compatible implementation is used, the default AES-GCM version otherwise. Upgrading to a newer OS version the content should still be decryptable, while newer content will then be encrypted with the AES-GCM version.

Description

Design Choices

• AES + GCM block mode: To make sure that the data is not only kept confidential, but it's integrity also preserved, the authenticated encryption AES+GCM is used. GCM can be implemented efficiently and fast and is the usually alternative to encrypt then mac with AES+CBC and HMAC. The authentication tag is appended to the message and is 16 byte long in this implementation. A downside of GCM is the requirement to never reuse a IV with the same key, which is avoided in this lib.
• Every put operation creates a different cipher text: Every put operation generates new salts, iv so the the resulting cipher text will be unrecognizably different even with the same underlying data. This makes it harder to check if the data actually has changed.
• KDFs with Key Stretching features for user passwords: Add brute-force protection to possibly weak user provided passwords (e.g. BCrypt).
• Minimum SDK 19 (Android 4.4): A way to increase security is to cap older implementation. SDK 19 seems to be a good compromise where most of the older security hack fixes are not necessary anymore, but still targeting most devices.
• Use of JCA as Provider for cryptographic primitives: Various security frameworks exists in Java: BouncyCastle, Conscrypt, Facebook Conceal. The problem is that these libraries are usually huge and require manual updates to have all the latest security fixes. This library however depends on the default JCA provider (although the developer may choose a different one). This puts trust in the device and it's implementation, while expecting frequent security patches. Usually the default provider since KitKat is AndroidOpenSSL provider which is fast (probably hardware accelerated for e.g. AES) and heavily used by e.g. TLS implementation.
• Android Keystore System is not used: In my humble opinion, the Android Keystore is the best possible way to secure data on an Android device. Unfortunately, due to the massive fragmentation in the ecosystem properly handling and using the Android Keystore System is not easy and has some major drawbacks. Due to working in a security relevant field I have a lot of experience with this technology, therefore the decision was made to not support it for this implementation i.e. to keep it simple.
• Use of data obfuscation: To disguise the actual data format and appear as a pseudo random byte array, obfuscation is used. This deliberately uses non standard ways to make it a bit harder to reverse engineer.

User provided Passwords

A high entropy value not known to any system but the user is a good and strong base for a cryptographic key. Unfortunately user-based passwords are often weak (low-entropy). To mitigate that fact and help preventing easy brute-forcing key derivation functions with key stretching properties are used. These functions calculate pseudo-random data from it's source material which requires mandatory work.

The following implementations are available:

• BCrypt: based on blowfish, has a variable cpu cost parameter and a fixed memory cost parameter (default)
• PBKDF2: applies a pseudorandom function, such as hash-based message authentication code (HMAC), to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key; no memory hardness

It is possible to provide any KDF implementation to the storage with providing a custom KeyStretchingFunction implementation.

Note, if you use key stretching put/get operations will get very slow (depeding on the work factor of course), so consider accessing the store in a background thread.

Encryption Fingerprint

This store bases part of it's security on so called fingerprinting. That basically means, during runtime entropy from e.g. the device, system or other parts are used to create a cryptographic key with which the data is encrypted. It basically is encryption with a semi-secret key.

This has the following benefits:

• Binding the data to the executing runtime (ie. making it harder to lift the data and trying to read it in a different environment)
• Strongly obfuscating the data bordering actual encryption when the used fingerprint is infeasible to guess
• Be able to scope the data to a specific environment (e.g. when using the Android OS image build number, every update invalidates the data)

This store has a default implementation of EncryptionFingerprint which can only use generic data. In detail the following properties are incorporated:

• Fingerprint of the APK signature
• Android ID : a 64-bit number (expressed as a hexadecimal string) byte random value; on SDK 26 and higher, unique to each combination of app-signing key, user, and device - on SDK 25 lower only unique to user and device
• Application package name, brand, model and name of the device
• 32 byte hardcoded static random value

Enhancing the Strength of the Encryption Fingerprint

The security of this mechanism increases considerably if the user adds it's own data. Here are some suggestions:

• Random values hardcoded, locally generated or provided by a remote service
• Unique user-id (if the application has the concept of login)
• Device Serial (requires dangerous permission SDK > 25)
• Sim-ID/ICCID (if changing the sim should/can invalidate the data)
• Android OS image build fingerprint (if you want to invalidate the data after OS update)

Key Derivation Process

The cryptographic key used to encrypt the data is composed of the following parts:

• User password (optional): provided by the caller and stretched with e.g. Bcrypt
• Encryption Fingerprint (see section above)
• Entry Key: the hashed version of the key passed by the caller; this will bind the data to that specific entry key
• Entry Salt: a random 16 byte value unique to that specific entry that will be created on every put operation (will also be used for the key stretching function)
• Storage Salt: a random 32 byte value unique to that specific storage, created on first creation of the storage

The concatenated key material will be derived and stretched to the desired length with HKDF derivation function.

Persistence Profile

Key

The key is hashed with HKDF (which uses Hmac with Sha512 internally) expanded to a 20 byte hash which will be encoded with base16 (hex). The key generation is salted by the encryption fingerprint, so different shared preferences will generate different hashes for the same keys.

Content

The diagram below illustrates the used data format. To disguise the format a little bit it will be obfuscated by a simple xor cipher.

The resulting data will be encoded with base64 and looks like this in the shared preferences xml:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
    <string name="39e3e4f83dda81c44f8a9063196b28b3d5091fca">hwbchXlqDAQcig6q3UWxdbOb2wouDGGwjUGNIzREiy0=</string>
    <string name="62ef41ac992322bdd669e96799c12a66a2cce111">AAAAABAAajtOaVCq5yqu1TPxgLu2AAAAqUTxgPcAM6lyNTGgy7ZAoCjqcCdtxT6T</string>
</map>

Digital Signatures

Signed Commits

All tags and commits by me are signed with git with my private key:

GPG key ID: 4FDF85343912A3AB
Fingerprint: 2FB392FB05158589B767960C4FDF85343912A3AB

Build

Assemble the lib with the following command

./gradlew :armadillo:assemble

The .aar files can then be found in /armadillo/build/outputs/aar folder

Libraries & Credits

• BCrypt
• HKDF Standalone
• Bytes
• Awesome logo made by @iqbalhood

Similar Projects:

• Google's Android Jetpack EncryptedSharedPreferences using Android Keystore System
• secure-preferences using AES-CBC by @scottyab (not maintained)
• secure-preferences supporting Android Keystore System by @ophio
• secure-preferences using FB Conceal framework by @phamquyhai
• secure-preferences supporting Android Keystore System by @adorsys
• secure-preferences supporting Android Keystore System by @iamMehedi
• secure-preferences using AES-CBC by @PDDStudio

Further Reading

• Security Best Practices: Symmetric Encryption with AES-GCM in Java and Android
• Security Best Practices: Symmetric Encryption with AES-CBC in Java and Android
• Stack Overflow: Security with SharedPreferences - A Discussion

License

Copyright 2017 Patrick Favre-Bulle

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

armadillo's Issues

Add derived password cache to speed up consecutive .get() calls

To make get calls faster, a cache, which caches the derived password should be implemented. This will not speed up put* operations since every time a new salt will be created making it impossible to cache.

The disadvantage is that the derived password stays in cache, therefor in memory for way longer, making it easier to read when the device is used with instrumentation tool like FRIDA (this is a more specific attack, since when the attacker has full access to the device, there is not much you can do).

Please migrate to androidX

Hi, Thanks for this Library.

Please migrate to this code to androidx

Make CI Config Pull Request friendly

Currently the CI job fails because a PR does not have the secret env vars to decrypt the release keystore (which is good :)).

Create a config that only runs on PR CI jobs which only builds debug.

Use Android's Log instead of Timber

This issue is just a proposal.

Depending on Timber has some drawbacks:

1. if an app doesn't use Timber, lint raises a warning for each Android's Log call by default since Timber implemented the lint check LogNotTimber
2. it increases the APK size

The first issue is way more important than the second one.
Also because, if someone enables isWarningsAsErrors in the lintOptions, every Log's call is marked as an error.

Is it possible to depend on Android's Log instead of Timber?

aar doesnt pull in required dependencies

armadillo depends on bytes and hkdf libraries. It would be nice if there were specified as transitive dependencies in the pom and pulled in automatically.

  implementation "at.favre.lib:bytes:0.4.6"
  implementation "at.favre.lib:hkdf:1.0.0"

Cheers

Use AndroidKeyStore for store encryption key

NegativeArraySizeException when getting value with parallel access

Any idea what could cause this exception to be raised?

Caused by java.lang.NegativeArraySizeException: -16
       at at.favre.lib.armadillo.AesGcmEncryption.decrypt(SourceFile:99)
       at at.favre.lib.armadillo.DefaultEncryptionProtocol.decrypt(SourceFile:152)
       at at.favre.lib.armadillo.SecureSharedPreferences.decrypt(SourceFile:518)
       at at.favre.lib.armadillo.SecureSharedPreferences.getString(SourceFile:149)

Library crashing in devices running KitKat

According to the Readme:

Minimum SDK 19 (Android 4.4): A way to increase security is to cap older implementation. SDK 19 seems to be a good compromise where most of the older security hack fixes are not necessary anymore, but still targeting most devices.

But if you look into the build.gradle file, it declares:

minSdkVersion = 21

Are the docs not up to date? Or it is still safe to use the library with minSdkVersion = 19?

Thanks.

Bcrypt Key Stretcher used incorrectly

armadillo/armadillo/src/main/java/at/favre/lib/armadillo/BcryptKeyStretcher.java

Line 63 in 1761d0f

return Bytes.from(BCrypt.hashpw(String.valueOf(password) + Bytes.wrap(salt).encodeHex(), generateSalt(salt, logRounds))).array();

Unfortunately the jBcrypt API was used totally incorrectly (to be fair, the API does not have any fail safes to warn the user):

1. The password is encoded with hex and the salt is appended:
   String.valueOf(password) + Bytes.wrap(salt).encodeHex()
   First of all, I dont't know why I appended the salt. Second, bcrypt only supports 72 bytes of PW by encoding the UTF-8 byte array as hex the PW length was additionally shortened and maybe results in premature truncated passwords. So the actually maximum length is 72/2 = 36 bytes (which is probably long enough for most practically used PW, but still bad)
2. The salt was generated like this:
   saltBuilder.append(Bytes.wrap(HKDF.fromHmacSha256().expand(salt, "bcrypt".getBytes(), 16)).encodeHex());
   Due to the 'creative' way the jBcrypt API generates a salt, I implemented my own salt method to be able to pass a custom salt, but did it incorrectly. The salt SHOULD be 16 bytes encoded as Bcrypt Radix64 (= 22 bytes), but the 16 bytes where encoded to 32 characters hex. The jBcrypt impl then cuts 10 of those characters cutting 5 bytes of entropy making it a 11 byte hash

All this was discovered while trying to update the bcrypt impl with mine https://github.com/patrickfav/bcrypt.

Going forward:

• I will replace the current Bcrypt stretcher with the new, correctly implemented one, that means that old encrypted preferences cannot be read anymore
• The old bcrypt impl will still be in the code base, but deprecated, the data is still accessible
• I will change the "change password" feature to also accept a new Keystrecht impl, so this issue can be migrated

Check password during initialisation

Currently, if you are using a user-provided password you don't know if the password is correct until you try to decrypt some value and you get an exception. It would be nice to know it when you are getting the Armadillo instance.

We could store some dummy value and try to decrypt it during the initialisation to check that the password is correct. What do you think?

Password is not being used for derivating encryption key

The user provided password is supposed to be used to derivate the encryption key. However, it seems that currently is not being used.

How to reproduce:

1. Instantiate Armadillo with password A.
2. Save some data
3. Instantiate Armadillo with password B (without deleting data).
4. Try to retrieved data stored with password A.
   -> You are able to retrieve the plain data

Avoid keeping cleartext password char[] in memory

Currently the sharedPreference implementation keeps the char[] array of the user password in memory until its closed. This makes it quite easy to read the cleartext password when instrumenting the device and reading the current memory (e.g. with Frida). There is a datastructure which obfuscates the content of a field, so it can be used until it is actually used.

It WOULD be way better to derive a byte array directly when passing the password (using a hash function or similar), then use this byte array when deriving the main key (so the clear pw is never in memory again), but that would entail making non-backwards compatible changes.

Java 8 / Springboot version

Is there a version of this project for Java 8 and/or springboot?

Really good project and would love to use it in a server/side project I'm working on.

Change password feature does not support empty passwords

Currently, it's not possible to change from a "empty" password to a user define password.

Stacktrace password null:

2018-07-18 11:20:21.333 19121-19121/at.favre.lib.securesharedpreferences E/AndroidRuntime: FATAL EXCEPTION: main
    Process: at.favre.lib.securesharedpreferences, PID: 19121
    java.lang.IllegalStateException: Could not execute method for android:onClick
        at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:389)
        at android.view.View.performClick(View.java:6294)
        at android.view.View$PerformClick.run(View.java:24770)
        at android.os.Handler.handleCallback(Handler.java:790)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:164)
        at android.app.ActivityThread.main(ActivityThread.java:6494)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
     Caused by: java.lang.reflect.InvocationTargetException
        at java.lang.reflect.Method.invoke(Native Method)
        at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:384)
        at android.view.View.performClick(View.java:6294) 
        at android.view.View$PerformClick.run(View.java:24770) 
        at android.os.Handler.handleCallback(Handler.java:790) 
        at android.os.Handler.dispatchMessage(Handler.java:99) 
        at android.os.Looper.loop(Looper.java:164) 
        at android.app.ActivityThread.main(ActivityThread.java:6494) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) 
     Caused by: java.lang.NullPointerException: Attempt to get length of null array
        at java.util.Arrays.fill(Arrays.java:2879)
        at at.favre.lib.armadillo.SecureSharedPreferences.changePassword(SecureSharedPreferences.java:252)
        at at.favre.lib.armadillo.SecureSharedPreferences.changePassword(SecureSharedPreferences.java:230)
        at at.favre.lib.securesharedpreferences.ChangePasswordActivity.onChangePasswordClicked(ChangePasswordActivity.java:60)

Stacktrace password empty:

2018-07-18 11:16:52.676 18954-18954/at.favre.lib.securesharedpreferences E/AndroidRuntime: FATAL EXCEPTION: main
    Process: at.favre.lib.securesharedpreferences, PID: 18954
    java.lang.IllegalStateException: Could not execute method for android:onClick
        at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:389)
        at android.view.View.performClick(View.java:6294)
        at android.view.View$PerformClick.run(View.java:24770)
        at android.os.Handler.handleCallback(Handler.java:790)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:164)
        at android.app.ActivityThread.main(ActivityThread.java:6494)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
     Caused by: java.lang.reflect.InvocationTargetException
        at java.lang.reflect.Method.invoke(Native Method)
        at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:384)
        at android.view.View.performClick(View.java:6294) 
        at android.view.View$PerformClick.run(View.java:24770) 
        at android.os.Handler.handleCallback(Handler.java:790) 
        at android.os.Handler.dispatchMessage(Handler.java:99) 
        at android.os.Looper.loop(Looper.java:164) 
        at android.app.ActivityThread.main(ActivityThread.java:6494) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) 
     Caused by: java.lang.IllegalStateException: could not stretch with bcrypt
        at at.favre.lib.armadillo.FixedBcryptKeyStretcher.stretch(FixedBcryptKeyStretcher.java:59)
        at at.favre.lib.armadillo.DefaultEncryptionProtocol.keyDerivationFunction(DefaultEncryptionProtocol.java:178)
        at at.favre.lib.armadillo.DefaultEncryptionProtocol.decrypt(DefaultEncryptionProtocol.java:151)
        at at.favre.lib.armadillo.SecureSharedPreferences.decrypt(SecureSharedPreferences.java:463)
        at at.favre.lib.armadillo.SecureSharedPreferences.reencryptStringType(SecureSharedPreferences.java:273)
        at at.favre.lib.armadillo.SecureSharedPreferences.changePassword(SecureSharedPreferences.java:242)
        at at.favre.lib.armadillo.SecureSharedPreferences.changePassword(SecureSharedPreferences.java:230)
        at at.favre.lib.securesharedpreferences.ChangePasswordActivity.onChangePasswordClicked(ChangePasswordActivity.java:54)
        at java.lang.reflect.Method.invoke(Native Method) 
        at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:384) 
        at android.view.View.performClick(View.java:6294) 
        at android.view.View$PerformClick.run(View.java:24770) 
        at android.os.Handler.handleCallback(Handler.java:790) 
        at android.os.Handler.dispatchMessage(Handler.java:99) 
        at android.os.Looper.loop(Looper.java:164) 
        at android.app.ActivityThread.main(ActivityThread.java:6494) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) 
     Caused by: java.lang.IllegalArgumentException: provided pseudoRandomKey must be at least of size 1 and not null
        at at.favre.lib.crypto.HKDF$Expander.execute(HKDF.java:230)
        at at.favre.lib.crypto.HKDF.expand(HKDF.java:151)
        at at.favre.lib.armadillo.FixedBcryptKeyStretcher.bcrypt(FixedBcryptKeyStretcher.java:78)
        at at.favre.lib.armadillo.FixedBcryptKeyStretcher.stretch(FixedBcryptKeyStretcher.java:57)

EncryptionProtocolException: at.favre.lib.armadillo.AuthenticatedEncryptionException: could not encrypt

SharedPreferences preferences = Armadillo.create(context, prefName)
.password(Keys.UserProvidedPassword.toCharArray()) //use user provided password
.securityProvider(Security.getProvider("BC")) //use bouncy-castle security provider
.keyStretchingFunction(new PBKDF2KeyStretcher()) //use PBKDF2 as user password kdf
.contentKeyDigest(Bytes.from(getUniqueDeviceId(context)).array()) //use custom content key digest salt
.secureRandom(new SecureRandom()) //provide your own secure random for salt/iv generation
.encryptionFingerprint(context, (Keys.EncryptionFingerprint).getBytes(StandardCharsets.UTF_8)) //add the user id to fingerprint
.supportVerifyPassword(true) //enables optional password validation support .isValidPassword()
.enableDerivedPasswordCache(true) //enable caching for derived password making consecutive getters faster
.build();

GzipCompressor possible resource leaks

Hey, you are not using the try-catch correctly in the compress and decompress method. You should close the streams in a finally block, so they are closed even if there is an exception raised. The stream null check is not required for the compress method.

Example of a correct decompress method for the GzipCompressor class (the gzipInputStream != null should not happen, but theoretically new byte[2048] can throw an OutOfMemoryException before the gzipInputStream instance is created):

    @Override
    public byte[] decompress(byte[] compressed) {
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        GZIPInputStream gzipInputStream = null;
        try {
            int len;
            byte[] buffer = new byte[2048];
            gzipInputStream = new GZIPInputStream(new ByteArrayInputStream(compressed));

            while ((len = gzipInputStream.read(buffer)) > 0) {
                bos.write(buffer, 0, len);
            }

            return bos.toByteArray();
        } catch (Exception e) {
            throw new IllegalStateException("could not decompress gzip", e);
        } finally {
            try {
                bos.close();
            } catch (IOException ignore) { }

            if (gzipInputStream != null) {
                try {
                    gzipInputStream.close();
                } catch (IOException ignore) { }
            }
        }
    }

I would prefer try-with-resources with auto-close, but to support older Java versions and android, this should do it.

putString() cannot take null as a default value

Got this error:

java.lang.NullPointerException: provided string must not be null
 at java.util.Objects.requireNonNull(Objects.java:228)
 at at.favre.lib.bytes.Bytes.from(Bytes.java:432)
 at at.favre.lib.bytes.Bytes.from(Bytes.java:410)
  at at.favre.lib.armadillo.SecureSharedPreferences$Editor.putString(SecureSharedPreferences.java:241)

java.lang.NullPointerException

It's some problems with private static String getAndroidId(Context context) on some Oreo and Pie devices: ONEPLUS A6010 (9), Pixel 2 XL (10), Mi A1 (9) (from Crashlytics)

java.lang.NullPointerException: provided string must not be null
       at java.util.Objects.requireNonNull + 228(Objects.java:228)
       at at.favre.lib.bytes.Bytes.from + 502(Bytes.java:502)
       at at.favre.lib.bytes.Bytes.from + 480(Bytes.java:480)
       at at.favre.lib.armadillo.EncryptionFingerprintFactory.create + 49(EncryptionFingerprintFactory.java:49)
       at at.favre.lib.armadillo.Armadillo$Builder.encryptionFingerprint + 159(Armadillo.java:159)
       at at.favre.lib.armadillo.Armadillo$Builder.encryptionFingerprint + 111(Armadillo.java:111)

Please, fix it, if possible.

AES only supported by Android API 23+

AES only supported by Android API 23+
https://developer.android.com/training/articles/keystore.html

Library could not encrypt error on Android 9.0 with "BC" security provider

When running the following code to encrypt our SharedPreferences:

return Armadillo.create(context, prefsName) .encryptionFingerprint(context) .securityProvider(Security.getProvider("BC")) .keyStretchingFunction(new PBKDF2KeyStretcher()) .enableKitKatSupport(true) .build();

I get the following issues on Android 9.0+

Caused by: java.lang.IllegalStateException: at.favre.lib.armadillo.EncryptionProtocolException: at.favre.lib.armadillo.AuthenticatedEncryptionException: could not encrypt at at.favre.lib.armadillo.SecureSharedPreferences.encryptToBase64(SecureSharedPreferences.java:511) at at.favre.lib.armadillo.SecureSharedPreferences.access$400(SecureSharedPreferences.java:33) at at.favre.lib.armadillo.SecureSharedPreferences$Editor.putString(SecureSharedPreferences.java:412)

I know Android did some changes to cryptography in 9.0, I'm not sure if they are related or I've just missed a setting here:
https://android-developers.googleblog.com/2018/03/cryptography-changes-in-android-p.html

jBCrypt library requires to pass the password as String object

In BcryptKeyStretcher, the Char[] array with the password is converted into a String to call the BCrypt.hashpw() function:

This implies we have no means of clearing the password from memory afterwards, as a String is an immutable value.

https://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords

Add change password feature to sample app

NullPointerException when closing armadillo initialised without user password

If you initialised Armadillo without a user password and then you try to close it a new NullPointerException is thrown.

armadillo/armadillo/src/main/java/at/favre/lib/armadillo/SecureSharedPreferences.java

Line 308 in 9ba55b2

Arrays.fill(password, (char) 0);

Stacktrace:

2018-07-18 11:00:22.260 18226-18226/at.favre.lib.securesharedpreferences E/AndroidRuntime: FATAL EXCEPTION: main
    Process: at.favre.lib.securesharedpreferences, PID: 18226
    java.lang.IllegalStateException: Could not execute method for android:onClick
        at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:389)
        at android.view.View.performClick(View.java:6294)
        at android.view.View$PerformClick.run(View.java:24770)
        at android.os.Handler.handleCallback(Handler.java:790)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:164)
        at android.app.ActivityThread.main(ActivityThread.java:6494)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
     Caused by: java.lang.reflect.InvocationTargetException
        at java.lang.reflect.Method.invoke(Native Method)
        at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:384)
        at android.view.View.performClick(View.java:6294) 
        at android.view.View$PerformClick.run(View.java:24770) 
        at android.os.Handler.handleCallback(Handler.java:790) 
        at android.os.Handler.dispatchMessage(Handler.java:99) 
        at android.os.Looper.loop(Looper.java:164) 
        at android.app.ActivityThread.main(ActivityThread.java:6494) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) 
     Caused by: java.lang.NullPointerException: Attempt to get length of null array
        at java.util.Arrays.fill(Arrays.java:2879)
        at at.favre.lib.armadillo.SecureSharedPreferences.close(SecureSharedPreferences.java:328)
        at at.favre.lib.securesharedpreferences.MainActivity.onCloseArmadilloClicked(MainActivity.java:90)

Improve RecoveryPolicy

When a value cannot be decrypted, the recovery policy currently only lets you delete and/or throw an exception.

The policy should be extended so a developer can, in more fine-grain detail choose what to do. This should not be a full blown migration feature (which is more a part of #31 ). But give the developer full control on what to do (e.g. call a crash reporting tool, etc.)

Proguard rules for this library

Is there any proguard rule for this library ?

Support changing password

It would be nice to be able to change the user-provided password easily.

This means that all the data has to be decrypted with the old password and re-encrypted with the new one.

It can be handy when you want to switch from a default password to a user-provided password. And for later when the user wants to change it.

Logo Proposal For armadillo

Hello Sir. I'm a UI/UX and Graphics Designer.
I want propose a logo for your github project.
Would you mind if I propose logo for your application as my Open Source Contribution?

Thanks before.
Regards,
@iqbalhood