Fwd: Help, batch mode not working for --edit-key option ?

[Hugo Almeida]

Hi,

I want to add many subkeys under a primary key,
now I can use `gpg --edit-key ` and
type addkey command blah blah... to do it manually,
then repeat these steps again and again,
until enough subkeys for current key I have.

But before it,
I use batch mode to auto-create (unattended) new primary key,
its so cool for bash script,
but batch mode seems not work for --edit-key option,
I want a unattended way to add subkeys.

I've read FAQ, man page of gpg,
source tree of doc/DETAILS,
and do so many google,
but cant help myself,
then I am here.

Thanks a lot.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[Robert J. Hansen]

> Many write-ups of atomic/sub-atomic level phenomena seem to me to
> involve considerable deviations from our commonsense notions of
> reality. (-;

Nonsense.  What, you don't find quantum mechanics to be common-sense and
wholly intuitive?  ;)




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: one key/pair for multiple email accounts

[Micha Rosenbaum]

On 07.07.2014 23:49, eMyListsDDg wrote:
> in practice, do users of gnupg find that having multiple email account id's 
> added to one key/pair using that key/pair to sign and/or encrypt emails & 
> files more efficient to manage?
>
> curious how other uses in this situation manage their gnupg?

I'm using one key pair for multiple email addresses. But I think it
depends on the usage of your email addresses. If you use one for
business and don't want your partners to see your private email address
(maybe something like bunny...@example.com), then I'd prefer two key
pairs ;).

But I'm not using gnupg for long now and I'm curious what other say,
too. Maybe there are best practises about this topic?

-- 
PGP: 0x7694EB9B (http://rosetree.de/pgp)
http://www.email-nur-an-dich.de/



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 7 July 2014 at 11:11:36 PM, in
, Robert J. Hansen wrote:


> It's been done a few times but without results, which
> is unsurprising: on an atomic level gravity is
> ridiculously weak.  It's still being researched.  Smart
> money is that antimatter has a gravitic attraction just
> like regular matter: if it doesn't, a whole lot of our
> commonsense notions of reality have to get thrown out.

Many write-ups of atomic/sub-atomic level phenomena seem to me to
involve considerable deviations from our commonsense notions of
reality. (-;



- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

You can't build a reputation on what you are going to do
-BEGIN PGP SIGNATURE-

iPQEAQEKAF4FAlO7jQFXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5pbkAD/0egxRzbgJ4X5Py4JbivMdrhypIW1irh7MQs
kz/f8rwPDsqbY1sacOp0flfefaYOvLobBTg1LFKx2w5fa0DOyFUW295SyQMlgwab
4IMlNnE0X6J676Qh7ZQULOQFgW2flkZ5RCK5D5gIOu1pkfxYEtmauOkR2uZRia/n
VS/MugTe
=3Z60
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Greetings everybody, new user here

[Robert J. Hansen]

> Hi everyone.  I just signed up to this list and thought to introduce
> myself.

Welcome to the community!  We're a pretty friendly bunch here.  Hasn't
been any blood drawn in quite a while, honestly.  :)

With respect to delays in the keyserver network, the major address that
people tend to use (pool.sks-keyservers.net) is not a single box but a
confederation of them.  It's sort of like how when you visit google.com
you're visiting one of thousands of boxes configured to respond to that
address.  If by some chance you and your correspondent happen to hit the
exact same keyserver the propagation delay will be measured in
milliseconds.  Otherwise the certificate has to be propagated from one
machine's database to another.  This process, while normally very quick
(sub-minute), sometimes has problems.

Imagine there's Box A and Box B and then the Big Cloud of Boxes that
represents the keyserver network.  A gets all its updates from B, and B
gets its updates from the Big Cloud of Boxes.  If for some reason the
network link from A to B goes down, A will fall behind B (and the rest
of the Big Cloud of Boxes) in synchronization.

The good news is that most of the time propagation speed is extremely
fast.  Network problems do occur, but generally they're not significant
enough to be a major worry.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Key server long propagation delays?

[Schlacta, Christ]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I was recently setting up my new keys along with some other people,
and I discovered that as soon as one of my cohorts sent their keys and
recieved confirmation, I could retrieve the keys and they showed up.
When I sent stuff to the key servers, however, they couldn't retrieve
them for upwards of several minutes.  Later in the evening, we both
sent each other's signed certificates back to the key servers, and
that propagation delay was several HOURS in duration.  We made sure to
both send to the same key servers, and we tried multiple different
keyservers, but ultimately the only solution was to wait.
Furthermore, I failed in attempts to google this problem, and couldn't
find any documentation on key server change propagation delays.  I
wanted to know if what we've observed is Normal, and if so, if there's
any way we can reduce the time it takes our keys to be visible to each
other.

Thanks in advance!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTu1+fAAoJEFiHuRCpy1pB6CYH/iYgqoJqNwV+nsLdUNX+OT5c
i9fKkkkDcigmHAIOONyed4MCTyyAs2GWwwIoMyNSc3jA4SnSun7qL+jZ/ujsppzL
z9mGwEHbe7DmO2GcWUNfX9cW014tRB1wnBQ1k4Z9jvEiGXHR1vDr/wx4MFitwDr6
hkjIqpizLE1xbh4JuSX70ESMlSyLE3fk+cqs10lD1KOGKizlLEoR1QZ9zs1YmLQR
MxZQGFhJjruO+z3gpT+xnr6GoamkgWXgiORec9b0mnG6du6ioGX+mvRv38pC6PYE
M5qOAolcOFOLN8+K1/ZAR/9uVdJiKpFKO8UCIlCLwbGa9AVRGOuh4NrViWkqbmQ=
=a6pQ
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Greetings everybody, new user here

[Schlacta, Christ]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone.  I just signed up to this list and thought to introduce
myself.  I've been aware of gpg for a long time, but seldom have I had
occasion to actually use it.  Well, now I do, so I'm all signed up and
introducing myself.  As you can probably see, my name is Christ.  I
work in the web development industry and have ties to the security
sector.  Surprising as it is, most people I communicate with simply
don't use GPG, so I've never had occasion to use it beyond the
occasional verification of a package or download.  Well, now I have my
own key, 389B07F6, published to the local keyservers, and I joined the
list.  I have a few minor issues I'll post about separately as
occasion arises.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTu15mAAoJEFiHuRCpy1pBNrIIANJnpETE/AtFGJyzeFEcvvD/
CwBC7clA6Wl2SkqSTU8sV140YwtcmDhWoFDG1qav5hCUjqwOyxX/yprwBoj12T+I
egghupb2pQHPOW2ZzDL83w2hZuk/uQcqQ0+TxUDQAR8dD1jxM7rc2Ew1pc7sje8Z
yEN3TXlvFynL++CeFBy/eVXVhhymDF+NKWnHjsrE8zGBXdg5527fZOyxOegmSzHV
AH6aAXl83USBQyJZafo2+s4TR1ijOWxB6cNVx+Di9RpROJsOeN3gyf1g7lBsgG5i
zrTfjnlEJYZJ7ZB6d08cL/zlx5rv2Tt88/zGX2GyvCLlPYZteDXG0t9eSNsSj4o=
=zVNz
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[Robert J. Hansen]

On 7/7/2014 5:52 PM, Leo Gaspard wrote:
> Wasn't there an experiment running, one or two years ago, about
> trying to make anti-electrons anti-gravitate? I don't remember of
> having read any result, though...

It's been done a few times but without results, which is unsurprising:
on an atomic level gravity is ridiculously weak.  It's still being
researched.  Smart money is that antimatter has a gravitic attraction
just like regular matter: if it doesn't, a whole lot of our commonsense
notions of reality have to get thrown out.

> Weren't you the one who preached to assume the worst?

Yes, but there's a big difference between saying "it is possible that
RSA will be susceptible to quantum computation in the near future, so
let's account for that in our threat model," and saying, "RSA is
susceptible to quantum attacks."

Reality should always be described as accurately as possible.  Threat
models should be constructed under a pessimistic interpretation of that
accurately-stated reality.  :)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[Leo Gaspard]

On Sun, Jul 06, 2014 at 12:21:13PM -0400, Robert J. Hansen wrote:
> On 7/6/2014 3:36 AM, The Fuzzy Whirlpool Thunderstorm wrote:
> > Using GPG encryption is still good, although it's vulnerable to
> > quantum cryptodecryption.
> 
> In point of fact, we don't know this.
> 
> Theoretically, science-fiction level breakthroughs in quantum
> computation would break RSA.  But the problem with theory is some of the
> things that theory permits turn out to be impossible in reality.  For
> instance, there's nothing in the laws of physics that prohibit things
> from having negative mass, but we've never encountered negative-mass
> material anywhere: not in the lab, not in the world, not in deep space,
> not anywhere.

Wasn't there an experiment running, one or two years ago, about trying to make
anti-electrons anti-gravitate? I don't remember of having read any result,
though...

> It's good to be skeptical of quantum computation.  It's interesting to
> read up on, but be immensely skeptical of all predictions.

Weren't you the one who preached to assume the worst? It seems rather reasonable
to assume that somewhere in the future quantum cryptography (or any other kind
or huge advance in science) will break whatever cipher we are currently using...
after all, vigenere-like ciphers are almost ridiculous nowadays, while they were
once state-of-the-art.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

one key/pair for multiple email accounts

[eMyListsDDg]

in practice, do users of gnupg find that having multiple email account id's 
added to one key/pair using that key/pair to sign and/or encrypt emails & files 
more efficient to manage?

i have mulitple email accounts and in the past had generated a key/pair for 
each, each with its own unique passphrase. i'm rethinking that approach.

curious how other uses in this situation manage their gnupg?



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[Johan Wevers]

On 07-07-2014 10:09, The Fuzzy Whirlpool Thunderstorm wrote:

> It depends on how important the data is. Of course, if the data is so
> important, when the expiration time comes, all the data encrypted with
> the old key need to be decrypted and encrypted with the new generated
> key.

However, if your communication lines are bugged the attacker already has
the data encrypted with the old key. This is only valid if cold storage
data is at risk. In such cases an encrypted disk using some symmetric
algorithm that is likely not vulnerable to quantum computers is a safer
option.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[Paul R. Ramer]

On July 6, 2014 4:40:13 PM PDT, MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> 
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Hi
>
>
>On Sunday 6 July 2014 at 3:25:57 PM, in
>, Johan Wevers wrote:
>
>
>
>> Since I don't know when I will consider a key
>> compromised or weak, I don't work with expiry dates but
>> revoke the key in such a case.
>
>I don't know quite what /The Fuzzy Whirlpool Thunderstorm/ had in
>mind, but I would say setting expiry dates can maybe act as a reminder
>to consider such matters from time to time. Of course, it could just
>come around when you are too busy to consider any such thing, so you
>blindly extend the expiry date anyway. Or you set them too short, so
>extending becomes run-of-the-mill.

Uh, yeah. That can happen. I will not say that I did that once upon a time but 
... :-)

Cheers,

-Paul


--
PGP: 3DB6D884

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Encrypt a signed text

[vedaal]

> it is not (afaik) possible to bind that detached signature to the plaintext 
> and have it encrypted as one process. I would need to be zipped together or 
> otherwise connected first.

=

I haven't tried this, so i don't know how it would work,
but you might try to CAT and pipe to gpg encrypt,

i.e.

split the signature from the plaintext
CAT the plaintext and the .sig file into one file
then pipe it into gpg --encrypt

if anyone has actually done this, please post,

TIA,


vedaal


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

secret key vs pubblic key

[stakanov]

Hi.
I once encountered the following situation. 

One of my contacts did send his/her private key on the public key server. 
Claiming that this was his/her public key. Funnily enough I did import that key 
and did not get aware it was a secret key. And as far as I remember it worked 
to decrypt her messages. 


First question: was this possible because you can decrypt messages from a 
counterpart also with his/her private key (having it imported from a key 
server) using your private key? Or (I do sincerely not remember) did s(he) send 
me the public key separately maybe and this is why I was able to decrypt) 

Kgpg has a very strange policy in communicating the import of a key. It always 
speaks of "secret key" imported whether this is a public or private key At 
least in opensuse when you do "export your public key" and "export your secret 
key" both will have the same aspect AFAIC (name.asc). Is this intentional and 
could this be changed to make things like this happen less? (Note: more people 
will use encryption so the level of knowledge of the program is to be expected 
to lower not to get higher at least statistically. It is true that in the most 
recent version of kgpg this has changed and a dialogue should make people 
understand they are exporting a private key (at least when exporting to a file, 
however, I do not know if this warning happens also when people export to a 
key-server). 

That brings me to this question: is there a way, once I have to keys let us say 
"Paul.asc" a public one and "Paul.asc" a private one that should not have been 
exported, to understand immediately what kind of key is this. What would be the 
command on the command line?

Last question: 
why a does a key server for public keys accept "private keys" anyway? Isn't 
there a way in the infrastructure to block those errors from the very origin?

Thank, you. 



---
Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! 
http://email.freenet.de/basic/Informationen


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Encrypt a signed text

[vedaal]

On 7/7/2014 at 10:42 AM, "Walter Lange"  wrote:

>I would like to encrypt a signed (with ASCII armor) text. It 
>should take
>two steps, because I want to use two different machines, a local 
>one to
>sign and a remote machine which encrypts. The result should be the 
>same
>as the encrypted and signed one in one step. Is that possible?

=

Not the way you want it.

It will have the same end result, in that the signature can be verified, on the 
same text,
and the decryption will show the text and verify the signature,

But in the case where it is a one step process, the decrypted plaintext will 
not have the signature as part of the text.

The other way is possible.

It is possible to encrypt and sign as one step, and then armor the signature 
and attach it to the decrypted plaintext to make it look like it was first 
clearsigned, or armored signed, and then encrypted.

The problem with doing it the way you want, is that while it is possible to 
remove the signature and save it as a detached signature,
it is not (afaik) possible to bind that detached signature to the plaintext and 
have it encrypted as one process. I would need to be zipped together or 
otherwise connected first.


vedaal


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Encrypt a signed text

[Walter Lange]

Hi mailing list!

I would like to encrypt a signed (with ASCII armor) text. It should take
two steps, because I want to use two different machines, a local one to
sign and a remote machine which encrypts. The result should be the same
as the encrypted and signed one in one step. Is that possible?

Thanks to all experts!

Regards Walter



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ECC and CMS (Re: [Announce] The fifth Beta for GnuPG 2.1 is now available for testing)

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/07/2014 04:01 PM, Bernhard Reiter wrote:
> On Thursday 03 July 2014 at 12:05:07, Werner Koch wrote:
>> I just released the fifth *beta version* of GnuPG 2.1.  It has
>> been released to give you the opportunity to check out new
>> features and to fix the bugs in the last beta.
> 
> Congratulations on the new beta!
> 
> About th ECC support in GnuPG 2.1: Does this work with OpenPGP and
> CMS?

ECC support for OpenPGP is defined in RFC6637[0]

> With the same algorithms?

Only the NIST P-curves are currently defined for OpenPGP although some
serpent and brainpool curves also works using the basic framework of
RFC6637 - these are also included in SKS. See e.g. [1] for discussion
on Ed25519 that is currently implemented in GnuPG 2.1 but does not yet
have an RFC.

References:
[0] http://tools.ietf.org/html/rfc6637
[1] http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html

- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Docendo discimus
We learn by teaching
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTuqnJAAoJEPw7F94F4Tagz3AP/2dlnuXLFFiRe4x88uwQda8n
293pqKs+O+7lu7P+SlQbrckGyDSqydl4r0PMeXj5eImwKFPbIPqmw1pOcmf5TpEs
65W6/dfq4jiXgc+qV+YiH0lJ7ER870uRrxBKJDKc98dmH/kAZWobgRrWHgqx+nNN
LVW7UToosG2Z9hfAjvQlSXM1Ba9bcFgmnWsseYX9gpFFSY8+qATrvWHbv+TYUr3g
wClqd/KbQ4lB25qRhHydA2GxQSG5uhgKAwItIe42IGp6htBKsaXGE0nbegSXa8Ng
m01Xv/H/w3OlIOnRhKl5NwR36CO5QTXkFnix7lzxpWzn9Lx9qandL+n5iWvNKHF9
pF/n7rjuJ8jG8T0WdIUmHGJ4kkm0qI5efOGHLtF+5wzyLLezH0c8Ev7nls9OOp1c
vLXcXW1ttq7+g85+TYAzAHn4e7SU3mhFL7RC5m1mXcbtktWFxP4RBXsOtUxF9m0Z
5d/Q1X6nEeJ34+JYGBytQWt0UYj/C4NAmA6SyLFpfbvFB867dQgH/al50NGVvryI
TgYgNQnspkZ+MbEO0bPQBWulo7QYNVIqy3Vf2jPk4F3r3wN5EEJtBvBC5HVMhKgA
B8n9yE+o4QfvS6CA4E5cC+Ivi0Q6i2WfBQJQSDBIUih0B34LvmTwWSu/vreLUgTY
8zfmZAFg+nAODmUn2gp6
=kAPT
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

ECC and CMS (Re: [Announce] The fifth Beta for GnuPG 2.1 is now available for testing)

[Bernhard Reiter]

On Thursday 03 July 2014 at 12:05:07, Werner Koch wrote:
> I just released the fifth *beta version* of GnuPG 2.1.  It has been
> released to give you the opportunity to check out new features and
> to fix the bugs in the last beta.

Congratulations on the new beta!

About th ECC support in GnuPG 2.1:
Does this work with OpenPGP and CMS? 
With the same algorithms?

Best,
Bernhard

-- 
www.intevation.de/~bernhard (CEO)www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[The Fuzzy Whirlpool Thunderstorm]

Date: Mon, 7 Jul 2014 15:26:36 +0200
From: The Fuzzy Whirlpool Thunderstorm 
To: Peter Lebbing ;, gnupg-users@gnupg.org
Subject: Re: GPG's vulnerability to quantum cryptography
Message-ID: <20140707132636.ga64...@blinkenshell.org>
References: 
 <20140706073605.ga65...@blinkenshell.org>
 <53b95c75.5030...@vulcan.xs4all.nl>
 <53ba6d66.5030...@digitalbrains.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1"
Content-Disposition: inline
In-Reply-To: <53ba6d66.5030...@digitalbrains.com>
User-Agent: Mutt/1.5.23 (2014-03-12)


--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 07, 2014 at 11:50:30AM +0200, Peter Lebbing wrote:
> Could you explain what you mean? I'm really getting the impression we're
> talking about cracking an encryption key, and I don't see how revoking
> such a key would help significantly for that.
>=20
> Peter.
I mean, to prevent private key compromise, it's a good practice to set
an expiration date to your keys. So that, when the keys expire, you can
generate better keys to prevent a probability that the old keys have
been compromised.
I don't say that this is the safest thing to do to prevent old data
being decrypted.
I'm pretty sure, when the quantum systems are publicly available, GPG
will be updated with new algorithm to ensure key safety against such
systems.


pgpZGOWle6h86.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[Peter Lebbing]

On 06/07/14 16:25, Johan Wevers wrote:
> I don't see the relation between these two.

I agree.

This conversation is still a mystery to me.

"The Fuzzy Whirlpool Thunderstorm", it seems to me you advocate revoking
an encryption key, or letting it expire, when you suspect the key could
be cracked by an adversary.

This does not help at all for anything already encrypted to that key, it
only prevents people (who have fetched the revocation) to encrypt any
new data to that key. Any old data can still be decrypted by your
adversary, who has computed your private key.

The method works reasonably well for signature keys, apart from the fact
that your adversary can still fake a signature in the past, when your
signature key was still valid. Also, your correspondents still need to
fetch the revocation before they realise new signatures are invalid.

Could you explain what you mean? I'm really getting the impression we're
talking about cracking an encryption key, and I don't see how revoking
such a key would help significantly for that.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[The Fuzzy Whirlpool Thunderstorm]

On Sun, Jul 06, 2014 at 07:35:05PM +0200, gnupg-users-requ...@gnupg.org wrote:
> On 06-07-2014 9:36, The Fuzzy Whirlpool Thunderstorm wrote:
> 
> > Using GPG encryption is still good, although it's vulnerable to quantum 
> > cryptodecryption.
> > It's a good idea to set an expiration for each of your GPG key.
> > So that, when the expiration time comes, you'll be able to generate a
> > new GPG key to address a possibility of your old keys being cracked.
> 
> I don't see the relation between these two. You don't know when quantum
> computers who can break > 1024 RSA will be a reality so when should you
> set the expiration date? And you can always revoke a key if something
> like this happens, no need for expiration dates there either.
> 
> Since I don't know when I will consider a key compromised or weak, I
> don't work with expiry dates but revoke the key in such a case.
> 
This is also a good practice. Revoking a key which is suspected to be
compromised seems a good gpg practice. Because we don't know when
quantum computing will be ready to use. Maybe 50 years later, or maybe
10 years later? Just find out how Intel is shrinking miroprocessor die
size every year.
Quantum computing is still long way to go. For now, as long as we stick
to good gpg practice, no need to worry of compromised keys.
> > GPG is not perfect. It's just pretty good as the name suggest.
> > At least, it'll be able to protect your secured data for the rest of
> > your life or for the time specified at the expiration date.
> 
> If a key expires data will not be automatically decrypted. Nor will it
> become unusable.
I know that when the expiration time comes, the data will not be
automatically decrypted.


pgpk7c9ZD7fLa.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smart card reader security

[tux . tsndcb]

Hello Christian

>I bought a cyberJack go [1] to use it with my openPGP smart card for
>authentification. Since the firmware of that device is upgradeable and
>is capable of saving atleast 2 GB of data, how can I be sure it is not a
>security threat by saving sensitive data?

May be done an encrypted partition on it.

Best Regards



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GPG's vulnerability to quantum cryptography

[The Fuzzy Whirlpool Thunderstorm]

On Sun, Jul 06, 2014 at 12:53:26PM +0100, MFPA wrote:
> At the same time, would you advocate decrypting all your encrypted
> files and encrypting them to the new key? Or were you just referring
> to encrypted communications?

It depends on how important the data is. Of course, if the data is so
important, when the expiration time comes, all the data encrypted with
the old key need to be decrypted and encrypted with the new generated
key.
Although it's not truly necessary to do this work when the data is no
longer considered as important.
For encrypted communication, it's better to use the new generated key
when the expiration time comes.
I don't enforce my idea to be applied by everyone. This is an advice for
myself to do a good gpg practice.
Someone may refer to a key revocation rather than enforcing an
expiration time. That's also good practice.
I believe everyone of you has a method to prevent quantum
cryptodecryption on your public keys.


pgpPmL4nIesuE.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users