On Apr 6, 2012 10:36 AM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
> On 04/06/2012 04:22 AM, Greg Stein wrote:
> > Yeah, I switched the master passphrase param to an svn_string_t on the
> > probable outcome that we would immediately SHA1 the thing, and then use
> > resulting hash as the nominal password. That would avoid having the
> > plaintext in memory (and yes, I recognize it is quite possible that
> > copies exist; gotta start somewhere, and provide a data flow that
> > requirement of plaintext).
> To be clear, Greg, you're talking about something a little bit than
> "whole-disk encryption via encrypted keys" approach, right? IIUC, you're
> saying that we'll simply SHA1 the user-provided password plaintext master
> passphrase for the purpose of not holding that passphrase in memory. It's
> sha1(MP), then, that is the secret in our encryption/decryption steps.
> I'm not quite sure how this helps with the situation Brane has raised --
> we'll still be holding the actual encryption secret in memory, it just now
> looks less like a human-readable passphrase. But maybe that's the
Correct. Still useful, but even if memory is compromised, the SHA1 is not
reversible. The original MP cannot be recovered for other uses.
Received on 2012-04-06 16:48:30 CEST