subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Michael Pilato" <>
Subject Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
Date Fri, 06 Apr 2012 14:13:01 GMT
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
> (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?

C. Michael Pilato <>
CollabNet   <>   <>   Distributed Development On Demand

View raw message