Task #3664
handle PBKDF2WithHmacSHA1 changes in 4.4
| Status: | New | Start date: | 08/22/2014 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | 0.2 | |||
| Component: |
Description
Before PBKDF2WithHmacSHA1 only used the first 8 bits of each unicode character, as of 4.4 it now uses the whole value:
Related issues
History
#1 Updated by hans over 3 years ago
- Target version changed from 0.2 to 0.1
#2 Updated by hans over 3 years ago
This could be more painful than I initially thought. We need to handle a couple scenarios where a user creates a cacheword setup:
- on <=18 then upgrades to 19+
- on <=18 and is still on <=18
- on 19+ and is still on 19+
Maybe the best way to handle this is to have an automatic second KDF attempt on 4.4+ if the first one fails. That way, 4.4+ will use the fixed PBKDF2WithHmacSHA1 as much as possible, and <4.4 will use the old PBKDF2WithHmacSHA1.
#3 Updated by hans over 3 years ago
Upon thinking about this more, I think the best approach would be to make a SerializedSecretsV2 and include a byte that describes which format the password needs to be in:
- unicode (only supported on 19+, maybe use PBKDF2WithHmacSHA1AndUTF8 to force it)
- 8-bit forced (supported on 19+ with PBKDF2WithHmacSHA1And8bit and on <=18 using PBKDF2WithHmacSHA1)
- unknown (first try PBKDF2WithHmacSHA1 then try PBKDF2WithHmacSHA1And8bit)
more info here:
https://code.google.com/p/android/issues/detail?id=40578
This app handles it in a low-level way:
https://github.com/nelenkov/android-backup-extractor/blob/91f7b9210672922e11de3d576add12e051c3c2ad/src/org/nick/abe/AndroidBackup.java#L424
#4 Updated by hans over 3 years ago
- Target version changed from 0.1 to 0.2
#5 Updated by hans over 3 years ago
Here is some work-in-progress code for this:
https://github.com/eighthave/cacheword/tree/PBKDF2WithHmacSHA1