On 06.04.2012 16:13, C. Michael Pilato wrote:
> 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)?
Yup. You want to generate that with a crypto-grade random generator, of
coruse. Another bit that you do not want to reinvent. OpenSSL can do
that for you, for example; any sane crypto package will have an API that
generates good random bits for symmetric keys.
>>> 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
Vacuum will reorder the pages in the file to fill holes, but will then
truncate the database file without first overwriting it with random
crud. So, no, that's not good enough.
-- Brane
Received on 2012-04-06 17:02:54 CEST