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
Received on 2012-04-06 08:06:44 CEST