On Apr 6, 2012 10:36 AM, "C. Michael Pilato" <cmpil...@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
