[PATCH] Make pinentry-qt read and store passphrases in KDE 3.2's wallet

[Martijn Klingens]

(Combinding my replies to the points raised in a single mail)

On Monday 01 December 2003 08:45, Werner Koch wrote:
> Well said.  There is no reason to do this because a passphrase stored
> on disk is useless - if you want that you would be better off to save
> your key without any passphrase.  The thread model against the
> passphrase tries to protect is a compromised secret key - much like a
> PIN protects against lost or stolen smartcard.  If someone is able to
> read a (protected) secret key, he will also be able to read the file
> where KWallet stores the keys.

I'm not sure I understood that right.

Apart from coding issues, what's the semantic difference between storing the 
KWallet passphrase in a GPG encrypted document or storing the GPG passphrase 
in an encrypted wallet?

> Right.  To make use of the pinentry to cache passwords, use the
> gpg-agent and let it do it.  There is a simple mechanism to use it for
> that task (that is what gpg currently uses).

Ehm, pinentry doesn't cache passwords. What my patch does is not showing the 
DIALOG if the wallet already contains the passphrase. Otherwise it shows the 
dialog as it used to do, but it subsequently tries to store the passphrase in 
the wallet for later retrieval without having to show the dialog if the 
wallet is already open.

On Monday 01 December 2003 09:55, Robert Schiele wrote:
> I can't tell exactly how smart encryption (AFAIK Blowfish) and management
> of passwords in KWallet are implemented, so I cannot tell whether it is a
> good idea to use it or not.

To be honest, I don't know either. I trust George Staikos (the author) to 
write decent code, and at least for end user desktops it's by far the most 
tightly integrated solution that can be used for central password management 
without giving up much security, if any at all (apart from typing them every 
time again, but then one shouldn't use the agent in the first place). KWallet 
is also one of the few places that allows storing ssh-agent passphrases as 
well, AFAIK gpg-agent can't be made to fit for that as well, so you'd end up 
with the original situation of having to type tons of passwords for even 
relatively basic operation.

On Monday 01 December 2003 12:18, Werner Koch wrote:
> And thus the clear passwords are floating around in KDE occupied
> memory without much control.  In contrast gpg-agent is designed to
> minimize traces of secrets left on system resources and to keep close
> control over it.
>
> If the goal is to make password entry easier, you should use gpg-agent
> at least for gpgsm passwords and best also for gnupg passwords,
> becuase at some point gpg will delegate all seret key operations to
> gpg-agent.

This argument makes sense indeed. Although I'm a KDE coder I have to admit 
that the way QString works isn't the most secure one. I'm not 100% sure that 
problem applies to KWallet though, the core application is a tiny kded module 
and the code might not be using QString that much. It's guesswork, I'd need 
to look at George's code before I can make any claims.

If you want to minimize the amount of traces in memory the ssh-agent and 
gpg-agent therefore might do a better job, though personally I'd much rather 
go for the encrypted swap that the 2.6 kernel is supposed to have if you 
value security that much.

However, is it possible to use either gpg-agent or ssh-agent as a single 
centralized backend for gpg-agent, ssh-agent, kwallet, and possibly others?

I doubt it. KWallet OTOH can be easily made fit, my patch to the pinentry was 
only 2 hours of work and basically proves it already.

On Monday 01 December 2003 14:34, Werner Koch wrote:
> Okay.  Anyway, pinentry shall not have an extra and specialized
> interface for one application.  Furthermore, all variants of pinentry
> have to have the same interface.

Just to re-iterate what I said above: it's not an interface _for_ kwallet, but 
_from_ kwallet. It's just an extension to the already-existing GUI that 
allows fetching the pass from something else than a dialog. Compare it with a 
pinentry for a braille reader, if one exists.

-- 
Martijn