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 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
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.
_
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 de
On Thu, Jan 23, 2014 at 04:38:19PM -0800, Robert J. Hansen wrote:
> >Well... I don't know how you type
>
> With a nine-volt battery, a paperclip, and a USB cable that has only one end
> -- the other is bare wires. You wouldn't believe how difficult it is to do
> the initial handshake, but once yo
On 24.01.2014, Leo Gaspard wrote:
> Actually, this is something I never understood. Why should people create a
> revocation certificate and store it in a safe place, instead of backing up the
> main key?
Because a backup only makes sense when it's stored in a diffrent place
than the key itself:
Well... I don't know how you type
With a nine-volt battery, a paperclip, and a USB cable that has only
one end -- the other is bare wires. You wouldn't believe how
difficult it is to do the initial handshake, but once you've got it
down you can easily tap out oh, three or four words a min
On Thu, Jan 23, 2014 at 03:08:40PM -0800, Robert J. Hansen wrote:
> >Yet, I agree I would not send my encrypted private key. But having your
> >divorced
> >spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an
> >unreasonable threat to me.
>
> It is. That's why that's not the
Yet, I agree I would not send my encrypted private key. But having
your divorced
spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an
unreasonable threat to me.
It is. That's why that's not the threat being defended against.
The threat is against your spouse seeing you
On Thu, Jan 23, 2014 at 01:27:58PM -0800, Robert J. Hansen wrote:
> [...]
>
> And yes, a strong passphrase is still the strongest bar against these
> backups being misused -- but unless you've got an eye-poppingly strong
> passphrase, your best bet is to rely on denying attackers access to the dat
On Thu, Jan 23, 2014 at 09:59:30PM +0100, Pete Stephenson wrote:
> [...]
>
> They would need to be trustworthy
> enough to not abuse the revocation certificate by revoking your
> certificate, but otherwise would not need to be given absolute trust
> that comes with having a copy of the private key
Actually, this is something I never understood. Why should people create a
revocation certificate and store it in a safe place, instead of
backing up the main key?
A "safe place" for a revocation certificate may be vastly different
from a "safe place" for a backup of your certificate. For i
On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard wrote:
> On Thu, Jan 23, 2014 at 05:53:57PM +, nb.linux wrote:
>> 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,...).
>
On Thu, Jan 23, 2014 at 05:53:57PM +, nb.linux wrote:
> 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
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 coun
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 simpl
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 Op
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
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
> o
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
>
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
21 matches
Mail list logo
