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
>
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 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
ask
-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 th
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
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
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
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, 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,...).
>
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, 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 secr
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
>
> Experien
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
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 us
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
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, 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
21 matches
Mail list logo