Re: time delay unlock private key.

2014-01-26 Thread Werner Koch 
On Sat, 25 Jan 2014 13:33, shm...@riseup.net said:

>>> $ gpg-connect-agent 'getinfo s2k_count' /bye
>>> ERR 280 not implemented
>> 
>> You are using GnuPG version < 2.0.15.
>
> $ gpg2 --version
> gpg (GnuPG) 2.0.22

Gnome-keyring or Seahorse gpg-agent connection hijacking active?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-25 Thread shm...@riseup.net 


Werner Koch:
> On Sat, 25 Jan 2014 10:31, shm...@riseup.net said:
> 
>> $ gpg-connect-agent 'getinfo s2k_count' /bye
>> ERR 280 not implemented
> 
> You are using GnuPG version < 2.0.15.

$ gpg2 --version
gpg (GnuPG) 2.0.22
libgcrypt 1.6.0
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECC, ?
Cypher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

hmmm ...

> 
> 
> Shalom-Salam,
> 
>Werner
> 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-25 Thread Werner Koch 
On Sat, 25 Jan 2014 10:31, shm...@riseup.net said:

> $ gpg-connect-agent 'getinfo s2k_count' /bye
> ERR 280 not implemented

You are using GnuPG version < 2.0.15.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-25 Thread shm...@riseup.net 


Werner Koch:
> On Thu, 23 Jan 2014 19:20, r...@sixdemonbag.org said:
> 
>> Not really, although DKG gave you a good heads-up about the number of
>> iterations in s2k.
> 
> FWIW: With GnuPG 2.x the default iteration count is calibrated to an
> iteration time of 100ms.  That is of course machine dependent.  To view
> that count you may run gpg-connect-agent as in this example:
> 
>   $ gpg-connect-agent 'getinfo s2k_count' /bye
>   D 16777216
>   OK

$ gpg-connect-agent 'getinfo s2k_count' /bye
ERR 280 not implemented

hmmm ?

> 
> 
> Shalom-Salam,
> 
>Werner
> 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-23 Thread Werner Koch 
On Thu, 23 Jan 2014 19:20, r...@sixdemonbag.org said:

> Not really, although DKG gave you a good heads-up about the number of
> iterations in s2k.

FWIW: With GnuPG 2.x the default iteration count is calibrated to an
iteration time of 100ms.  That is of course machine dependent.  To view
that count you may run gpg-connect-agent as in this example:

  $ gpg-connect-agent 'getinfo s2k_count' /bye
  D 16777216
  OK


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-23 Thread Robert J. Hansen 

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


GnuPG doesn't make a brute force attack possible.

You make a brute-force attack possible by choosing a weak passphrase.   
Choose a strong one.  It's really that simple.



Could a time delay be implemented similar to the one I just mentioned?


Not really, although DKG gave you a good heads-up about the number of  
iterations in s2k.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-23 Thread nb.linux 
Hi Uwe,

Johannes Zarl:
> So in short:
>  - a delay won't help you
>  - protect your private key so this won't happen
>  - always use a strong passphrase
and in addition: if you fear (or know) that your secret key was copied
from your system, revoke it!
To me, this is a very important feature of OpenPGP: _you_ can actually
do something to reduce (not more, but also not less!) harm for yourself
and others.
And, you can be prepared for such an event (i.e. having created the
revocation certificates in advance, stored them in a save but accessible
place, printed out on paper,...).

Cheers,
-- nb.linux

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-23 Thread Werner Koch 
On Thu, 23 Jan 2014 15:34, o...@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
first.

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


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-23 Thread Daniel Kahn Gillmor 
On 01/23/2014 09:34 AM, Uwe Brauer wrote:
> Hello
> 
> A Long time ago, IBM's proprietary  OS, called CMS had a particular
> feature for the login:
> 
> 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.
> 
> My private pgp and smime keys are secured by a password, but there is no
> time delay, which makes a brute force attack possible.
> 
> Could a time delay be implemented similar to the one I just mentioned?

Nope; the IBM system was an active system; the GnuPG private keyring is
an on-disk data format.  If the gnupg executable (which is an active
system) were to implement its own timeout/falloff, anyone who wanted to
crack the file in question would just recompile their own gnupg without
that timeout/falloff, so it wouldn't be an effective countermeasure
against an attacker.

However, you can make each single attempt significantly more expensive
by playing with the s2k-count argument (assuming a reasonable choice for
s2k-mode and s2k-digest-algo and s2k-cipher-algo).

See the manual page notes about those options for more details, and the
specification's string-to-key section for a description of what those
arguments do to the underlying data:

 https://tools.ietf.org/html/rfc4880#section-3.7

Regards,

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: time delay unlock private key.

2014-01-23 Thread Johannes Zarl 
On Thursday 23 January 2014 15:34:17 Uwe Brauer wrote:
> A Long time ago, IBM's proprietary  OS, called CMS had a particular
> feature for the login:
> 
> 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.

The same feature is implemented in some form in many/most contemporary login 
systems as well, and it makes great sense for a login system.

The main reason this makes sense is that as a regular user you can't just 
bypass the login screen and get direct access to the hashed password value.

> My private pgp and smime keys are secured by a password, but there is no
> time delay, which makes a brute force attack possible.
> 
> Could a time delay be implemented similar to the one I just mentioned?

In contrast to the login screen example, a delay implemented by gnupg won't 
help you in this case. Once an attacker has access to your private key, he or 
she can try a brute-force attack against the passphrase using a patched 
version of gnupg that does not implement the delay.

So in short:
 - a delay won't help you
 - protect your private key so this won't happen
 - always use a strong passphrase

Cheers,
  Johannes

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users