On 04/06/2012 02:06 AM, Branko Čibej wrote:
> 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.
That's a neat concept. I presume that the encryption key is just some
random data (since the user never needs to know it)?
>> 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.)
*sigh* I hadn't considered stale, compromised data not yet purged or
overwritten. Does SQLite's VACUUM statement help with this problem?
http://sqlite.org/lang_vacuum.html
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-04-06 16:13:37 CEST