time delay unlock private key.

Werner Koch wk at gnupg.org
Thu Jan 23 16:00:55 CET 2014

On Thu, 23 Jan 2014 15:34, oub at mat.ucm.es said:

> It gave you three attempts to login in. If you failed there was a time
> delay of 20 min, if you failed again, the time delay was prolonged to
> one hour, and then I think to one day.

IIRC, each CMS users gets his own VM and minidisk.  Thus what you mean
is the regular login protection most OSes provide.  For Unix you
configure this in /etc/login.defs.

However, GnuPG is a user process and the agent as well as the keys are
under the full control of the user.  Thus the OS is not able to handle
this like the login.  After all, why should it.  If you are logged in
you may do anything with your data - why restrict it.

> My private pgp and smime keys are secured by a password, but there is no
> time delay, which makes a brute force attack possible.

What is your threat model?  Users who are able to access gpg/gpg-agent
but are not able to read secring.gpg or private-keys-v1.d?  Well, it is
possible to do this with SELinux and then such a feature might make
sense.  However, there is a plethora of other things you need to secure

In any case if an attacker has access to your machine or at least to
your account, you already reached game over state.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-users mailing list