[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
Alistair Crooks <agc%pkgsrc.org@localhost> writes:
>> What's the threat model this is protecting against? Presumably, if a
>> user can execute the program, and the program can read his keys, the
>> uesr can already read his own keys, so having a core dump doesn't give
>> the user information he didn't already have.
> Heh, yeah, it's not really to do with keys, much more the passphrase,
> which is dynamically allocated in a number of places in the library,
> and I haven't finished auditing all of the places just yet. I've
> added code to zero out that memory after use when I can - some more
> are still needed.
Fair enough -- the passphrase (and the unencrypted private key for that
matter) is never supposed to hit the disk, so you've identified a threat
this addresses. I'd suggest having a flag that stops the behavior,
though, to make debugging less irritating.
> The threat that I'm protecting against here is that of information
> disclosure coming from committing the passphrase to disk in a core
By that token, it would be of use for NetBSD to port over the encrypted
swap features other OSes have (it should be essentially no performance
hit), and I think it would also be nice if NetBSD could zeroize or
randomize RAM on voluntary shutdowns. Neither, of course, is a
> I'd really recommend source-changes-full for reviewing the changes
> that are made - the setrlimit(2) call is only made in the driver
> program, not the library.
That I got already.
Perry E. Metzger perry%piermont.com@localhost
Main Index |
Thread Index |