Bug #2254
provide byte[] and SecretKey methods for passwords/keys
| Status: | Closed | Start date: | 10/28/2013 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | hans | % Done: | 0% | |
| Category: | - | |||
| Target version: | 0.2 - reliability and cacheword interop | |||
| Component: |
Description
IOCipher should use char[] for handling the passwords and also wipe them when done.
Associated revisions
add tests for new byte[] raw key methods
expose new raw key API in Java, to work better with CacheWord
CacheWord generates the raw key based on a dynamic number of iterations of the
KDF, so that it doesn't take ridiculously long on old devices, but on new
devices has a reasonable number of KDF iterations. The exposes that API into
IOCipher's Java interface for easy integration with CacheWord.
Also, using byte[] for storing passwords means that Java code can zero out the
memory after the password/key is no longer in use. Strings are immutable in
Java, so the memory cannot be zeroed out. byte[] are very mutable, so they can
easily be zeroed out after use. Therefore only accept the database key as a
byte[] to encourage people to wipe the key from memory when they are done with
it.
fixes #1713 https://dev.guardianproject.info/issues/1713
fixes #2254 https://dev.guardianproject.info/issues/2254
refs #3174 https://dev.guardianproject.info/issues/3174
History
#1 Updated by hans almost 4 years ago
- Target version set to 0.2 - reliability and cacheword interop
#2 Updated by hans over 3 years ago
- Subject changed from iocipher uses String objects insecurely to use char[] instead of String for passwords/keys
- Assignee changed from abeluck to hans
char[] can be wiped, String is immutable so cannot.
#3 Updated by hans over 3 years ago
- Subject changed from use char[] instead of String for passwords/keys to provide byte[] and SecretKey methods for passwords/keys
char[] in Java provides UTF-16 characters, and there is no easy conversion method from UTF-16 short to UTF-8 byte. I'm thinking now that this should follow CacheWord's lead and use a SecretKey instance, which stores the key as byte[]. Then treat the byte[] as base64 ASCII chars that encode the full 256-bits of the AES key. SQLCipher has the raw key data mode in sqlite3_key(), so the byte[] can be passed directly to SQLCipher.
#4 Updated by Anonymous over 3 years ago
- Status changed from New to Resolved
Applied in changeset iocipher|commit:18de12e3900306d67c349f22505d048157428946.
#5 Updated by hans over 3 years ago
- Status changed from Resolved to Closed