This topic is not yet solved for me, sorry for the long inactivity...
I tried the following approach which is inspired by the debian hints [1][2].
[1] http://keyring.debian.org/creating-key.html
[2] http://wiki.debian.org/subkeys
# preparing clean environment for testing
$ mkdir
On 07/07/13 18:50, Hauke Laging wrote:
If you want to be sure you may create the mainkey without the flag for
encryption (--expert --gen-key).
The keys GnuPG creates by default have signature and certification capabilities
on the primary key and encryption on a subkey.
With an offline main
On 07.07.2013, Hauke Laging wrote:
Even with the default settings a 19-digits passphrase (upper and lower case
ASCII letters and digits) is as hard as AES (without flaws).
When you take all printable ASCII-chars as headroom, with
B = entropy in bits
L = length of the passphrase
P =
On 07/07/2013 03:42 AM, Heinz Diehl wrote:
will calculate your passwords entropy in bits. Your 19-chars password
accounts for 124 bits of entropy, which is nearly half of AES-256's
strength (there are P^L different passwords).
Not hardly. Theoretically speaking [*], AES-256 will fall to brute
Thanks for the replies,
On 7/6/13, Hauke Laging mailinglis...@hauke-laging.de wrote:
That's a strange argument for several reasons. The most important being: Why
should just one key be compromised if they are used on the same system?
Wouldn't it make more sense to put the saved effort for
On 07.07.2013, Robert J. Hansen wrote:
A keyspace of 2^124 is nowhere near half of
2^255; it's not even particularly close to the square root of 2^255.
Thanks for clarifying, you are (of course) right. Didn't think for a
second before posting :-(
However, I wanted to demonstrate the
Am So 07.07.2013, 09:42:59 schrieb Heinz Diehl:
will calculate your passwords entropy in bits. Your 19-chars password
accounts for 124 bits of entropy, which is nearly half of AES-256's
strength (there are P^L different passwords).
You're missing several important points:
1) AES is
On 07/07/2013 08:03 AM, Heinz Diehl wrote:
Or the other way 'round: why use (waste?) a lot of bits on
cryptography when it's much easier to bruteforce the
password itself?
Nobody with two brain cells to rub together is going to try
brute-forcing either the crypto or your passphrase. Nobody.
Am So 07.07.2013, 10:18:46 schrieb atair:
So, following your suggestions, I (c|sh)ould do:
1.1. create one master key for signing on a save environment e.g. live
CD, USB flash disk.
The mainkey is primary for certification (this refers to key components), not
really for signing (which refers
On 07.07.2013, Robert J. Hansen wrote:
Nobody with two brain cells to rub together is going to try
brute-forcing either the crypto or your passphrase.
This very much depends on how important the encrypted information is
considered to be. However, I agree that most probably no one is
On 07/07/2013 01:02 PM, Heinz Diehl wrote:
This very much depends on how important the encrypted information is
considered to be.
Find me some verifiable instance of OpenPGP passphrases being
brute-forced and I'll take this seriously. Until then, I will continue
to treat brute-forcing as the
On Sun, 07 Jul 2013 17:19:02 -0400
Robert J. Hansen articulated:
On 07/07/2013 01:02 PM, Heinz Diehl wrote:
This very much depends on how important the encrypted information is
considered to be.
Find me some verifiable instance of OpenPGP passphrases being
brute-forced and I'll take this
Hi all,
I want to introduce encryption to my email accounts and hesitate
already for almost a year to set up the keys/infrastructure because I
see some severe problems. Maybe you can tell me your experiences/ideas
about the concerns I have...
Situation:
I want so set up a GnuPG infrastructure
On 06.07.2013, atair wrote:
I want so set up a GnuPG infrastructure for my (lets say) 20 email accounts.
Keep it simple: You create *one* keypair and add all email-accounts to
it.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
Am Sa 06.07.2013, 19:00:47 schrieb atair:
(1) I create one key pair for each email account. In case one key gets
compromised the possible damage is limited to one email account.
That's a strange argument for several reasons. The most important being: Why
should just one key be compromised if
On 2013-07-06 21:52, Hauke Laging wrote:
[snip a whole bunch of helpful stuff]
My recommendation:
Separate keys by email address type:
a) private (one group)
b) each business separate
c) each organization separate
[snip a whole bunch more useful stuff]
This was an amazingly helpful email.
Am Sa 06.07.2013, 19:53:16 schrieb Tim Chase:
This was an amazingly helpful email. I've seen a lot of posts (both
blog and here on the mailing list) that are full of technical
explanations, but very few that go over best practices for managing
multiple identities.
I often help people create
17 matches
Mail list logo
