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
the
> > resulting hash as the nominal password. That would avoid having the
> > plaintext in memory (and yes, I recognize it is quite possible that
other
> > copies exist; gotta start somewhere, and provide a data flow that
avoids the
> > requirement of plaintext).
>
> To be clear, Greg, you're talking about something a little bit than
Brane's
> "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
critical
> difference?
Correct. Still useful, but even if memory is compromised, the SHA1 is not
reversible. The original MP cannot be recovered for other uses.
Cheers,
-g
Received on 2012-04-06 16:48:30 CEST