[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 6 Apr 2012 10:13:01 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.