Releases: patrickfav/armadillo
v1.0.0
- migrate to AndroidX (thx @marukami and special thx @davidmigloz)
- update AGP and Gradle
Breaking Change: Change of transitive dependencies from api
to implementation
If you are using code of any of the following libraries as transitive dependencies through this lib:
at.favre.lib:hkdf
at.favre.lib:bytes
at.favre.lib:bcrypt
com.jakewharton.timber:timber
your build may break and you have to add the dependency manually to your build. The reason is, that
I changed the scope of these to implementation
. See https://docs.gradle.org/current/userguide/java_library_plugin.html#:~:text=The%20api%20configuration%20should%20be,are%20internal%20to%20the%20component.
v0.11.0
- improve AES-GCM decryption logic
v0.10.0
v0.9.0
v0.9.0
- add wiping of pw cache to close() method in SecureSharedPreferences
- increase internal optional password cache to 12 from 8
- add shared preference listener feature which works with unencrypted data #47 (thx @davidgarciaanton)
- update AGP, target SDK to 29 and several internal dependencies
v0.8.0
v0.7.0
v0.7.0
- Improve derive user password memory protection #32
- Add derived password cache to speed up consecutive .get() calls #32
- Improve RecoveryPolicy #35
Breaking Change: RecoveryPolicy Interface
The RecoveryPolicy
interface changed to include a more flexible handle method.
If you used the old one just change:
new RecoveryPolicy.Default(true, false);
to
new SimpleRecoveryPolicy.Default(true, false);
What was RecoveryPolicy
is now SimpleRecoveryPolicy
.
v0.6.0
v0.6.0
- [Security] Fix bcrypt implementation #16, #8
- [Security] Add full Kitkat support #6, #31
- Add change password feature #13, #22
- Add change key stretching feature #16
Breaking Change
In the old bcrypt implementation the following issues were found (#16):
- only uses max 36 bytes entropy of the possible 72 bytes allowed by bcrypt
- only uses 11 byte entropy of the 16 byte possible salt
These issue limit the security strength of the KDF severely
and immediate update is recommended.
The security fix unfortunately introduced some non-backwards compatible
changes. Migration will only be needed if:
- a user password was used previously
- the default keyStretchingFunction() was used (ie. using the default config)
Updating the library will instantly make your data incompatible in this case.
Please follow the migration steps below:
Migration
- Set the old bcrypt key stretching function, renamed to
BrokenBcryptKeyStretcher
,
so the lib will be again able to read the data:
SharedPreferences preferences = Armadillo.create(context, ...)
...
.password(myPassword);
.keyStretchingFunction(new BrokenBcryptKeyStretcher()).build();
- Use the change password feature to set the new fixed implementation. For
this to work the user password is required. If you don't want the password
to change use the same one:
preferences.changePassword(myPassword, new ArmadilloBcryptKeyStretcher());
And that's basically it. From now on you won't need to set the
keyStretchingFunction()
any more. Note, that changing the password, is
a very slow process, because it involves, decrypting and re-encrypting all
values in the preference store (it is transactional).
I recommend setting a migration flag in a non-encrypted SharedPreference
and migrate the next time the user has to enter the password (this process
should be in background task anyway, so it should only take a bit longer
to decrypt for the user)
v0.5.0 (Important Security Fix)
Changes
- [Security] a user provided password was NOT used for the creation of the secret key #11 (thx @davidmigloz)
- various small fixes cleaning memory from security relevant data (internal keys, salts, etc.)
- fix minSdk to be 19 instead of 21
- new logo (thx @iqbalhood)
Known Issues
- currently the AES mode GCM does not work correctly on Kitkat, working on a fix
- currently migration is needed if user password was used (will add a migration guide later)
NOTE: If you are using 0.4.-
of armadillo, the user pw will not encrypt the data. Please update ASAP, but mind that this might make data inaccessible. I will be working on a workaround/migration guide. (see #11)
Special thx to @davidmigloz who is responsible for most of the fixes in this release and for finding the issue.
v0.4.3 (not secure - do not use)
- better exception clean up with resources and some byte wipe
Note: This release has a known security issue relating to the user password not correctly used during encryption (see #11). Do not use this release and migrate to 0.5+ ASAP
v0.4.2 (not secure - do not use)
- supporting
null
in.putString()
and.putStringSet()
; same as callingremove()
as per API spec