On 06.04.2012 00:38, C. Michael Pilato wrote: > I've been also frustrated when considering the situation that occurs when a > user changes his/her master password, forcing a re-encryption of all cached > credentials using the new password.
You could do what whole-disk encryption systems do: only the encyprtion key is encrypted by the master passphrase, actual data are encrypted by that key. This allows different users with different passphrases to decrypt the same data, since they only decrypt a wrapped copy of the same encryption key. In other words, changing the master passphrase only requires decrypting and re-encrypting one 256-bit encryption key, not the whole credentials store. > So. Wow. > > Is there anyone who is game for helping me tackle a new design for our > client-side authn cache using SQLite? This makes me wonder if we couldn't perhaps keep the whole thing as an in-memory-not-disk-backed SQLite database, then encrypt and dump the whole SQLite memory snapshot to disk. The real trouble with that approach is that debugging the database using the SQLite command-line tools would be impossible, everything would have to happen through the SVN API. (The point here is that, in this way, we could "easily" atomically re-encrypt everything with a new master passphrase, as opposed to doing it transactionally within an ordinary SQLite database -- because we don't have control over what SQLite does with the free space in the file, and it'd be really, really bad if snippets of data that had been encrypted by the old, presumably compromised, passphrase ended up sitting around on disk.) -- Brane