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
Hi!
is anyone interested in a BoF at FOSDEM on February 1 or 2? Anything
special to put on the agenda? How long should we plan 30, 45 or 60
minutes?
I plan to arrive on Saturday by noon which might be a bit too late to
sign up for a slot. Thus if there is interest in holding a BoF, I would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/23/2014 05:27 PM, Werner Koch wrote:
Hi!
Hi Werner,
is anyone interested in a BoF at FOSDEM on February 1 or 2?
Anything special to put on the agenda? How long should we plan 30,
45 or 60 minutes?
I'd be interested in a BoF at the
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, 23 Jan 2014 21:25, ekl...@gmail.com said:
PS: Please, do not tell me one might have forgotten his passphrase. In this
case
there is no harm in shredding the secret key and waiting for the expiration
Experience has shown that this is the most common reason why there are
so many secret
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 10:26:33PM +0100, Werner Koch wrote:
On Thu, 23 Jan 2014 21:25, ekl...@gmail.com said:
PS: Please, do not tell me one might have forgotten his passphrase. In this
case
there is no harm in shredding the secret key and waiting for the expiration
Experience has
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
I've been thinking about UIDs in keys, rfc4880 section 5.1 says that by
convention a UID is an rfc2822 email address but this is not a requirement[1].
Gnupg does enforce that restriction unless you explicitly disable it. It would
seem to make sense to include other strings that can identify a
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
On Thu, 23 Jan 2014 23:15, ekl...@gmail.com said:
Oh? I thought the most common reason was test keys, and tutorials which
explain
step-by-step how to make a keypair and push it on a keyserver, without telling
Obviously, I don't have no hard evidence for the claim that forgotten
passpharses
20 matches
Mail list logo
