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
--
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.
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 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+:
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:
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 you've
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
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
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
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
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
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
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
from your
On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard ekl...@gmail.com 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
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
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.
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 data
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 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 threat
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
20 matches
Mail list logo
