Re: CVS commit: src/crypto/external/bsd/netpgp/dist

["Perry E. Metzger" <perry%piermont.com@localhost>]

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
> dump.

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
NetPGP issue.

> 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
-- 
Perry E. Metzger                perry%piermont.com@localhost