Confirmation for cached passphrases useful?

[Robert J. Hansen]

On 10/12/2010 1:54 AM, Daniel Kahn Gillmor wrote:
> yes, of course this isn't going to be able to protect the user from
> someone with full access to their user account or their current session.

These two attack modes (root and user access) cover the overwhelming
majority of instances today, so already this hypothetical attack is an
exotic.  On top of that, your imagined situation seems to involve a
compromised machine communicating with a trusted server over a socket.
If the trusted server sends back a confirmation request, what's to keep
the malware from simply saying, "OK," in response to these requests?

> Conversely, people won't run well-isolated subsystems if the tools we
> provide don't support reasonable separation and control in the first
> place.

Please do not mistake this for snark.  It's not.  I'm using an absurd
position here to try and make my objections clear, not because I'm
trying to denigrate your views.

That said: "People will also not use GnuPG as a personal flotation
device in the event of a water landing if GnuPG does not float."

GnuPG is not a personal flotation device and, unsurprisingly, doesn't
have any features related to that.  This said, if users want GnuPG to
offer pontoon functionality in 2.2 they are certainly welcome to make
their opinions known.  If more than a dozen people say, "yes, I need
GnuPG to serve as a personal flotation device," I will happily get out
of the way and encourage it to be added.

But to talk about how the people need personal flotation support in
GnuPG, without actually hearing from users who genuinely need it... I
might have great respect for the speakers and might even agree with
their opinions: but in the absence of user demand, I wouldn't think we
should do it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5598 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20101012/c79e9538/attachment-0001.bin>