Mailing List Archive

Comparison of RSA vs elliptical keys
I'm trying to understand the differences in strength between an RSA key
and an elliptical one such ed25519 with cv25519. I know with RSA it is
pretty easy to "gauge" the strength 1024 vs 2048 vs 4096. 

I could not really find anything to say how strong these elliptical keys
are and how they compare to RSA ones. 


Thanks


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On Mon, May 11, 2020, at 5:15 PM, Mark wrote:
> I'm trying to understand the differences in strength between an RSA key
> and an elliptical one such ed25519 with cv25519. I know with RSA it is
> pretty easy to "gauge" the strength 1024 vs 2048 vs 4096. 
>
> I could not really find anything to say how strong these elliptical keys
> are and how they compare to RSA ones. 

Good question! Broadly, and with several assumptions, elliptic curves have the same security level as symmetric (e.g., AES) keys that are half the elliptic key's length. See https://en.m.wikipedia.org/wiki/Key_size and the references therein as a starting point.

For example, a 256 bit elliptic curve key has a similar strength to a symmetric key of 128 bits.

Due to various reasons, not all ECC keys are powers of 2 in length. For example, NIST P-521 is 521 bits long rather than 512 bits, and has equivalent security to a 256 bit symmetric key.

Cheers!
-Pete

--
Pete Stephenson

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On 12-05-2020 3:46, Pete Stephenson via Gnupg-users wrote:

> For example, a 256 bit elliptic curve key has a similar strength to a symmetric key of 128 bits.

Until, of course, a working quantum computer with more than a few qubits
is constructed. Then ECC is much more vulnerable than RSA or ElGamal due
to its smaler keysize (of course once a 256 bit quantum computer gets
constructed I would also worry about 8192 bit RSA being vulnerable too
in the very near future).

--
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: Comparison of RSA vs elliptical keys [ In reply to ]
Le 12.05.20 à 11:24, Johan Wevers a écrit :
> On 12-05-2020 3:46, Pete Stephenson via Gnupg-users wrote:
>
>> For example, a 256 bit elliptic curve key has a similar strength to a symmetric key of 128 bits.
>
> Until, of course, a working quantum computer with more than a few qubits
> is constructed. Then ECC is much more vulnerable than RSA or ElGamal due
> to its smaler keysize (of course once a 256 bit quantum computer gets
> constructed I would also worry about 8192 bit RSA being vulnerable too
> in the very near future).
>

Hi,

In the FAQ, it is written:
> Will GnuPG ever support RSA-3072 or RSA-4096 by default?
> Probably not. The future is elliptical-curve cryptography, which will bring a level of safety comparable to RSA-16384. Every minute we spend arguing about whether we should change the defaults to RSA-3072 or more is one minute the shift to ECC is delayed. Frankly, we think ECC is a really good idea and we’d like to see it deployed as soon as humanly possible.
(https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048)

So, I guess the key size is not the only criteria to evaluate the
strength of a cipher and ECC still provides better results despite
shorter keys.

However, I would be interested to know which ECC cipher would you
recommend to replace RSA. I am not a cryptographer and I don't find any
information (or more honestly: information that I can understand) about
Curve 25519, NIST P-256 (and greater), Brainpool, or secp256k1.

Thanks for the feedback,
Best,

Sylvain

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Sylvain Besençon via Gnupg-users wrote:

> Le 12.05.20 à 11:24, Johan Wevers a écrit :
> > On 12-05-2020 3:46, Pete Stephenson via Gnupg-users wrote:
> >
> >> For example, a 256 bit elliptic curve key has a similar strength
> >> to a symmetric key of 128 bits.
> >
> > Until, of course, a working quantum computer with more than a few
> > qubits is constructed. Then ECC is much more vulnerable than RSA or
> > ElGamal due to its smaler keysize (of course once a 256 bit quantum
> > computer gets constructed I would also worry about 8192 bit RSA
> > being vulnerable too in the very near future).
> >
>
> Hi,
>
> In the FAQ, it is written:
> > Will GnuPG ever support RSA-3072 or RSA-4096 by default?
> > Probably not. The future is elliptical-curve cryptography, which
> > will bring a level of safety comparable to RSA-16384. Every minute
> > we spend arguing about whether we should change the defaults to
> > RSA-3072 or more is one minute the shift to ECC is delayed.
> > Frankly, we think ECC is a really good idea and we’d like to see it
> > deployed as soon as humanly possible.
> (https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048)
>
> So, I guess the key size is not the only criteria to evaluate the
> strength of a cipher and ECC still provides better results despite
> shorter keys.
>
> However, I would be interested to know which ECC cipher would you
> recommend to replace RSA. I am not a cryptographer and I don't find
> any information (or more honestly: information that I can understand)
> about Curve 25519, NIST P-256 (and greater), Brainpool, or secp256k1.

I am no cryptographer either, but what I have observed is that most
apps nowadays use djb's Curve 25519. secp256k1 could be interesting
if you have a Bitcoin Wallet or use Bitmessage and want to use those
GnuPG subkeys also for Bitcoin transactions[1], or for Bitmessage.

[1] I once send Niibe-san (GnuPG dev.) some Satoshi to his Bitcoin
address, which he has as GnuPG sec256k1 subkey.

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On Tue, May 12, 2020 at 11:24:57AM +0200, Johan Wevers wrote:
> > For example, a 256 bit elliptic curve key has a similar strength to
> > a symmetric key of 128 bits.
>
> Until, of course, a working quantum computer with more than a few qubits
> is constructed.

Don't worry, there's literally trillions of dollars worth of bitcoins
riding on the premise that this will never happen. ;)

-K

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
W dniu 12.05.2020 o 17:04, Sylvain Besençon via Gnupg-users pisze:
> In the FAQ, it is written:
>> Will GnuPG ever support RSA-3072 or RSA-4096 by default?
>> Probably not. The future is elliptical-curve cryptography, which will bring a level of safety comparable to RSA-16384. Every minute we spend arguing about whether we should change the defaults to RSA-3072 or more is one minute the shift to ECC is delayed. Frankly, we think ECC is a really good idea and we’d like to see it deployed as soon as humanly possible.
> (https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048)
>
> So, I guess the key size is not the only criteria to evaluate the strength of a cipher and ECC still provides better results despite shorter keys.
>
> However, I would be interested to know which ECC cipher would you recommend to replace RSA. I am not a cryptographer and I don't find any information (or more honestly: information that I can understand) about Curve 25519, NIST P-256 (and greater), Brainpool, or secp256k1.

Disclaimer: I am not a cryptographer either, let's just say I am an advisor. So, anybody, please correct me, if needed.

1. In terms of key size Curve 25519 and P-256 should have same strength: ~128 bits (== comparing with good symmetric cipher, like AES). Generally decent ECC strength = ~0.5 * key_length_in_bits.
2. Curve 25519 is very easy to implement in such a way that the implementation is fast. Implementations of other curves are usually slower.
3. Curve 25519 is generally easier to implement and easier to implement in such a way that avoids many common security pitfalls, like vulnerability to timing attacks.
4. The design of Curve 25519 is public, (is believed to be) software patent free and all constants in it are derived in an easily explainable ways. There are no "magic numbers" out of nowhere that may be just random or maybe were chosen by designers to make some kind of backdoor - but you can never prove that they are innocent since obviously you can't prove that random number was indeed chosen truly randomly.
5. Curve 25519 was designed by DJB, an (mostly) independent security expert while others were designed/standardized by big organizations that (given indirect evidence and rumors) may not be that trustworthy.
6. This is why many new (and not only, see SSH) protocols tend to choose Curve 25519. But in PGP you should be careful because many implementations (and/or older versions) don't support it. So if you want portability/interoperability you may want some other curve or RSA, especially for the main and signing key.
7. If you want something stronger than Curve 25519 that (is believed to) share similar benefits try Curve 448 (~224 bits of security). But I am not sure if PGP implements it (yet?).

--
Grzegorz Kulewski

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On 12-05-2020 17:04, Sylvain Besençon via Gnupg-users wrote:

>> Probably not. The future is elliptical-curve cryptography, which will
>> bring a level of safety comparable to RSA-16384.

Yes, if attacked by classical computers.

> However, I would be interested to know which ECC cipher would you
> recommend to replace RSA.

None at all. I'd say probably one of these:
https://en.wikipedia.org/wiki/Post-quantum_cryptography but I am no expert.

--
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: Comparison of RSA vs elliptical keys [ In reply to ]
> However, I would be interested to know which ECC cipher would you
> recommend to replace RSA.

"Yes". :)

Back when we got these questions -- Elgamal? RSA? DSA? Help? -- we
used to tell people what mattered far, far more than which algorithm
they used was how much care they gave to their system. Keep your system
malware-free. Don't sign things willy-nilly without reading them first.
Be careful who you share your system with. Etcetera.

I have never ever heard of a cryptographic break against OpenPGP. I've
seen people be careless many times. I'm far more worried about that
than I am which algorithm you use.
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Le 12.05.20 à 19:27, Grzegorz Kulewski a écrit :
> Disclaimer: I am not a cryptographer either, let's just say I am an advisor. So, anybody, please correct me, if needed.
>
> 1. In terms of key size Curve 25519 and P-256 should have same strength: ~128 bits (== comparing with good symmetric cipher, like AES). Generally decent ECC strength = ~0.5 * key_length_in_bits.
> 2. Curve 25519 is very easy to implement in such a way that the implementation is fast. Implementations of other curves are usually slower.
> 3. Curve 25519 is generally easier to implement and easier to implement in such a way that avoids many common security pitfalls, like vulnerability to timing attacks.
> 4. The design of Curve 25519 is public, (is believed to be) software patent free and all constants in it are derived in an easily explainable ways. There are no "magic numbers" out of nowhere that may be just random or maybe were chosen by designers to make some kind of backdoor - but you can never prove that they are innocent since obviously you can't prove that random number was indeed chosen truly randomly.
> 5. Curve 25519 was designed by DJB, an (mostly) independent security expert while others were designed/standardized by big organizations that (given indirect evidence and rumors) may not be that trustworthy.
> 6. This is why many new (and not only, see SSH) protocols tend to choose Curve 25519. But in PGP you should be careful because many implementations (and/or older versions) don't support it. So if you want portability/interoperability you may want some other curve or RSA, especially for the main and signing key.
> 7. If you want something stronger than Curve 25519 that (is believed to) share similar benefits try Curve 448 (~224 bits of security). But I am not sure if PGP implements it (yet?).
>

Hello,

Thank you all for your quick answers, it is very useful!

RJH's answer sounds like a good piece of advice, but still, at the end,
we HAVE to to choose which algorithm to use when creating new key pairs.
This doesn't prevent me to (try to) be cautious about the general health
of my system.
Grzegorz's points convince me to give a try to Curve 25519. I have
another though:
> But in PGP you should be careful because many implementations (and/or older versions) don't support it. So if you want portability/interoperability you may want some other curve or RSA, especially for the main and signing key.

I am not sure to fully grasp the consequences of this... Does that mean
that, if I use Curve 25519, some people won't be able to use my public
key to encrypt stuff? Or does that mean that some people won't be able
to read or verify stuff that I encrypt and signs?
Would it be because they use older versions or because some software
programs don't implement Curve 25519?

I guess that Curve 25519 is mentioned in the IETF standard, isn't it?

Many thanks,
Best,

Sylvain

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besençon via Gnupg-users wrote:
>RJH's answer sounds like a good piece of advice, but still, at the end,
>we HAVE to to choose which algorithm to use when creating new key
>pairs.

No you don’t.

You can simply use `gpg --gen-key` and let GnuPG create a keypair with
the default algorithm (which is currently RSA 2048). Only if you call
GnuPG with the `--full-gen-key` command will you be asked to explicitly
choose which type of key of want.


>I am not sure to fully grasp the consequences of this... Does that mean
>that, if I use Curve 25519, some people won't be able to use my public
>key to encrypt stuff?

If their software does not support Curve 25519, yes.


>Or does that mean that some people won't be able to read or verify
>stuff that I encrypt and signs?

You encrypt messages to your correspondants with *their* public keys, so
the type of *your* key does not matter for that purpose. But they won’t
be able to verify your signatures.


>Would it be because they use older versions or because some software
>programs don't implement Curve 25519?

Yes. That being said, most modern implementations do seem to support
curve 25519. As far as I know, it is supported at the very least by

* GnuPG (? 2.1)
* OpenPGP.js
* Sequoia-PGP
* RNP

… which should already cover most of the OpenPGP user base. Of note, it
is *not* supported by Symantec PGP, though [1].


>I guess that Curve 25519 is mentioned in the IETF standard, isn't it?

Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are
part of the standard (since RFC 6637). The first mention of Curve 25519
for OpenPGP was in a draft by Werner in 2014 [2]. The draft never made
it to a RFC but the 25519 curve is now part of the draft for RFC4880bis,
the next revision of the OpenPGP standard [3].


- Damien

[1]
https://knowledge.broadcom.com/external/article/175932/encryption-desktop-cannot-import-ecc-pgp.html

[2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00

[3] https://gitlab.com/openpgp-wg/rfc4880bis
Re: Comparison of RSA vs elliptical keys [ In reply to ]
> RJH's answer sounds like a good piece of advice, but still, at the end,
> we HAVE to to choose which algorithm to use when creating new key pairs.

rjh@maggie:~$ gpg --gen-key
gpg: WARNING: using experimental features from RFC4880bis!
Note: Use "gpg --full-generate-key" for a full featured key generation
dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Delete Me
Email address: delete@example.org
You selected this USER-ID:
"Delete Me <delete@example.org>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea...

[snip]

Where in there was I ever asked to choose an algorithm?

"Unless you know what you're doing and why, use the defaults." I've
been saying that for twenty years now. I keep thinking that someday
someone will actually take it seriously...

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Robert J. Hansen wrote:

> > RJH's answer sounds like a good piece of advice, but still, at the
> > end, we HAVE to to choose which algorithm to use when creating new
> > key pairs.
>
> rjh@maggie:~$ gpg --gen-key
> gpg: WARNING: using experimental features from RFC4880bis!
> Note: Use "gpg --full-generate-key" for a full featured key generation
> dialog.
>
> GnuPG needs to construct a user ID to identify your key.
>
> Real name: Delete Me
> Email address: delete@example.org
> You selected this USER-ID:
> "Delete Me <delete@example.org>"
>
> Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
> We need to generate a lot of random bytes. It is a good idea...
>
> [snip]
>
> Where in there was I ever asked to choose an algorithm?

In older versions, like 2.0.x for example, it asked for ...

> "Unless you know what you're doing and why, use the defaults." I've
> been saying that for twenty years now. I keep thinking that someday
> someone will actually take it seriously...

Super modern OpenPGP implementations like the super awesome sequoia pgp
defaults to cv25519... (and does not need to generate a UID for privacy
reasons, simply fantastic!)

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Le 13.05.20 à 12:18, Robert J. Hansen a écrit :

> "Unless you know what you're doing and why, use the defaults." I've
> been saying that for twenty years now. I keep thinking that someday
> someone will actually take it seriously...
>

Thanks for the demonstration!
At least, I will now know what I am doing when I'll use the defaults! :)

Sylvain

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Le 13.05.20 à 11:54, Damien Goutte-Gattat a écrit :
> On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besençon via
> Gnupg-users wrote:
>> RJH's answer sounds like a good piece of advice, but still, at the
>> end, we HAVE to to choose which algorithm to use when creating new key
>> pairs.
>
> No you don’t.
>
> You can simply use `gpg --gen-key` and let GnuPG create a keypair with
> the default algorithm (which is currently RSA 2048). Only if you call
> GnuPG with the `--full-gen-key` command will you be asked to explicitly
> choose which type of key of want.
>
>
>> I am not sure to fully grasp the consequences of this... Does that
>> mean that, if I use Curve 25519, some people won't be able to use my
>> public key to encrypt stuff?
>
> If their software does not support Curve 25519, yes.
>
>
>> Or does that mean that some people won't be able to read or verify
>> stuff that I encrypt and signs?
>
> You encrypt messages to your correspondants with *their* public keys, so
> the type of *your* key does not matter for that purpose. But they won’t
> be able to verify your signatures.
>
>
>> Would it be because they use older versions or because some software
>> programs don't implement Curve 25519?
>
> Yes. That being said, most modern implementations do seem to support
> curve 25519. As far as I know, it is supported at the very least by
>
> * GnuPG (? 2.1)
> * OpenPGP.js
> * Sequoia-PGP
> * RNP
>
> … which should already cover most of the OpenPGP user base. Of note, it
> is *not* supported by Symantec PGP, though [1].
>
>
>> I guess that Curve 25519 is mentioned in the IETF standard, isn't it?
>
> Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are
> part of the standard (since RFC 6637). The first mention of Curve 25519
> for OpenPGP was in a draft by Werner in 2014 [2]. The draft never made
> it to a RFC but the 25519 curve is now part of the draft for RFC4880bis,
> the next revision of the OpenPGP standard [3].
>
>
> - Damien
>
> [1]
> https://knowledge.broadcom.com/external/article/175932/encryption-desktop-cannot-import-ecc-pgp.html
>
>
> [2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00
>
> [3] https://gitlab.com/openpgp-wg/rfc4880bis

Thanks a lot for all these explanations. It's very useful and
instructive. I appreciate your patience towards my dummy questions..! :)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Konstantin Ryabitsev wrote:

> On Tue, May 12, 2020 at 11:24:57AM +0200, Johan Wevers wrote:
> > > For example, a 256 bit elliptic curve key has a similar strength
> > > to a symmetric key of 128 bits.
> >
> > Until, of course, a working quantum computer with more than a few
> > qubits is constructed.
>
> Don't worry, there's literally trillions of dollars worth of bitcoins
> riding on the premise that this will never happen. ;)

Who knows, maybe in the future it is possible for researchers/companies
etc. to build cheaper and easier to produce alternatives?

https://www.nature.com/articles/d41586-019-02742-x

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On Wed 13/May/2020 11:54:12 +0200 Damien Goutte-Gattat via Gnupg-users wrote:
> On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besençon via Gnupg-users wrote:
>
>> I guess that Curve 25519 is mentioned in the IETF standard, isn't it?
>
> Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are part of
> the standard (since RFC 6637). The first mention of Curve 25519 for OpenPGP was
> in a draft by Werner in 2014 [2]. The draft never made it to a RFC but the
> 25519 curve is now part of the draft for RFC4880bis, the next revision of the
> OpenPGP standard [3].


However, its signing flavor, Ed25519, is described in RFC 8032:

This document describes elliptic curve signature scheme Edwards-curve
Digital Signature Algorithm (EdDSA). The algorithm is instantiated
with recommended parameters for the edwards25519 and edwards448
curves. An example implementation and test vectors are provided.
https://tools.ietf.org/html/rfc8032

Its use is standardized for DKIM signatures by RFC 8463.


Best
Ale
--
>
> [2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00
>
> [3] https://gitlab.com/openpgp-wg/rfc4880bis
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On Wed, 13 May 2020 10:54, Damien Goutte-Gattat said:

> Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are
> part of the standard (since RFC 6637). The first mention of Curve

RFC-6637 allows for arbitrary curves because curves are specified using
an ASN.1 OID. So for example the Brainpool curves can as well be used.

The problem is similar to using RSA (which was optional in the old
OpenPGP specs) or to use large RSA keys or even RSA keys which odd
lengths on which some implementations choke. For a public key algorithm
we unfortunately can't use the preference system. The worst thing which
can happen to a user is that they can't verify a signature or encrypt to
a key. But there are no backward compatibility issues related to data
etc.

> 25519 for OpenPGP was in a draft by Werner in 2014 [2]. The draft
> never made it to a RFC but the 25519 curve is now part of the draft

For Ed25519 we actually added a new algorithm id so that it is indeed
not covered by RFC-6637. Anyway, the two Curve22519 algorithms (ed25519
for signing, and cv25519 for encryption) are available in GnuPG as
"future-default". Given that older GnuPG versions reached end-of-life
2.5 years ago I consider it okay to change the default and create new
keys using ed25519/cv25519. GnuPG master, which will eventually be 2.3,
uses them as default.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Comparison of RSA vs elliptical keys [ In reply to ]
On Wed, 13 May 2020 15:09, Stefan Claas said:

> defaults to cv25519... (and does not need to generate a UID for privacy
> reasons, simply fantastic!)

And willfully violating the the standard. Not requiring a user id was
bug in PGP 2 and fixed more than 25 years about with PGP 2.6.3in.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Werner Koch wrote:

> On Wed, 13 May 2020 15:09, Stefan Claas said:
>
> > defaults to cv25519... (and does not need to generate a UID for
> > privacy reasons, simply fantastic!)
>
> And willfully violating the the standard. Not requiring a user id was
> bug in PGP 2 and fixed more than 25 years about with PGP 2.6.3in.

With all due respect, do you think when Hagrid and even good old SKS
key servers supports this feature that people would not applaud you if
you would consider including it in GnuPG too and reflecting it in the
respective RFC?

At least, the 'P' in OpenPGP and in the name GnuPG stands for privacy.
:-)

Best regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
> With all due respect, do you think when Hagrid and even good old SKS
> key servers supports this feature that people would not applaud you if
> you would consider including it in GnuPG too and reflecting it in the
> respective RFC?

Speaking for myself, I have "rfc4880" in my gpg.conf for damned good
reasons.

I *do not* want GnuPG to generate UID-less certificates in strict
compliance mode, I *do not* want GnuPG to use them in strict compliance
mode.

I have no opinion on "--allow-broken-certificates" and only allowing
them to be generated in expert mode after a clear warning about it being
noncompliant.

I also think this is the wrong place to talk about how the RFC should be
changed. Take it to the WG, please.
Re: Comparison of RSA vs elliptical keys [ In reply to ]
Robert J. Hansen wrote:

> > With all due respect, do you think when Hagrid and even good old SKS
> > key servers supports this feature that people would not applaud you
> > if you would consider including it in GnuPG too and reflecting it
> > in the respective RFC?
>
> Speaking for myself, I have "rfc4880" in my gpg.conf for damned good
> reasons.
>
> I *do not* want GnuPG to generate UID-less certificates in strict
> compliance mode, I *do not* want GnuPG to use them in strict
> compliance mode.
>
> I have no opinion on "--allow-broken-certificates" and only allowing
> them to be generated in expert mode after a clear warning about it
> being noncompliant.

When you work in compliance mode it should be IHMO possible that people
wishing to communicate with you (from foreign countries) and may have a
different opinion about privacy, GnuPG should accept such public keys,
without using extra parameters and that you can easily add them to your
key ring, with a simple label, thus not revealing the identity of them,
in case your computer or smartphone gets later compromised or is
searched at an airport etc.

Regards
Stefan








--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
> On 14 May 2020, at 23:42, Stefan Claas <sac@300baud.de> wrote:
>
> When you work in compliance mode it should be IHMO possible that people
> wishing to communicate with you (from foreign countries) and may have a
> different opinion about privacy, GnuPG should accept such public keys,
> without using extra parameters and that you can easily add them to your
> key ring, with a simple label, thus not revealing the identity of them,
> in case your computer or smartphone gets later compromised or is
> searched at an airport etc.

So your device is compromised by the feds and you’re worried about your gpg keyring leaking contact information, but not your inbox or your address book? And how does your encryption system work if it doesn’t maintain a mapping between email IDs and keys? I’m not convinced this threat model has been fully thought through.

A
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Thursday 14 May 2020 at 11:41:00 PM, in
<mid:20200515004100.00005d5c.sac@300baud.de>, Stefan Claas wrote:-



> GnuPG should accept
> such public keys,
> without using extra parameters and that you can
> easily add them to your
> key ring, with a simple label, thus not revealing the
> identity of them,
> in case your computer or smartphone gets later
> compromised or is
> searched at an airport etc.

Does that mean the "simple label" doesn't identify whose key it is? Or
have I misunderstood?

- --
Best regards

MFPA <mailto:2017-r3sgs86x8e-lists-groups@riseup.net>

Maybe YOU have nothing to hide;
that still leaves plenty you want to hide from!
-----BEGIN PGP SIGNATURE-----

iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2
MEM4NjI4RDU5MkZGOENERThCQjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF
3poBEACjmnBUOd79vOc6sywdw7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyj
tZ+vOsZSXb44tE2zNCWouNK/wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopg
sQFlDjbYRZ6bPc+ImsEdfaj3DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7es
mT9LmG0AvSSUZhZQqqMo5wvrfz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkK
agR1rexytIgsEU3OYHAl+qYfHqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/L
fWN6qX4NE9IC/QyKFXEQOybP9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/Unjgr
ZAboMoKgBZqYLpawjYIyVMYTdIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJG
oZSz6jHKKiDDKathLQqWEvAbCo6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGO
CavYmwN3mt5TwdNeOd22LFWHLBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBm
FzwnvH9i2xBln+4+YDHyod7clC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTX
jXtO8ss41j7Rg0TS3C4+QWMcmHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFD
RTU2OTcxRDU1NURBQTWJAl4EEwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIG
FQoJCAsDBRYDAgEAFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGFwFCQnQtEIA
CgkQrOVpcdVV2qU6AQ/9EaAae++qSxy9iM2a3Jfbqr5kEV+mJ//r6SIoDJPVANfb
5oHF/KZtF0a+SXR+cPPBMVKsppZ0Qr80FkjAUOH5YuUbTq2B+YvqMo5DLqBa2QiC
ax6x11udSI0IM2CL7I5vMcRuY+Z/P3FZ9RI+C7ALL+EgJ6xtFyYHOcVVYd/a0O/O
TH9KOVwcdtDChrRZBOC46+5hlcFxd3nwMUmXpRD1PE5+20vUbmyz2uKjHn93fOh2
MNMLhoO9qci+kKliawuU7UQ42VTO6FtUSoUpgPh37sVMImezC4jYm/1d3AFPCxpA
jP7mHgKxOwP6fw+hIEWoybv0Ws3BEhM4TInobQUs0wdsWLQ83x5L9IvEcL643mkL
bxCA48Fiw2YTWyuEdhIeSOtLTrM2k5xDVX5kPASGqG7rTP/exBo5Vg2UZWhPJuiE
fYaJR7PAl0i+318yQShIWg0Zt1Ob3K7/3yqvHDFzaAaKOlN9CZR5XVEcyq9G6M2u
u5cOZ0LQJTn/UFHYOK8D9/T33Zfac8tIjiIn916i1YvqYIzS14GKS8oqISy3FkD3
2tQf8ok/8PvnXe1xQPTAtIj3UqpiQf0L8xt96hLJHKphmR/ksKYBDdZFWRD/U0Na
kXjnepP0ek68fR3wO4lbYKG9x94YDM/7pQ1BpfZZMLrp+3xvTBxmgQCtAuUiJem5
Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprq
a15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5
qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuR
hT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmr
XVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4d
v6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/P
PIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrc
f4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgk
txvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDM
KS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O
21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJ
AjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb74QAK
CRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3WvPJwbrFR7L3Jk
x3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou6NLxM4ynxkV8
Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcCtOsjOffWWD1Y
ACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L5jjkFpSDQo+/
jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN9sujxRgXkccI
znci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOkPVTbDadspla8
2oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/wiUBjfJXT3ITo
rl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg30LsQtFWgiwN
tYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1EnBUJi49O0Sfqs
voFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0AbvIetF5qO+pJ
Y/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4GFu/ufjNzrgz
BFmF9HQWCSsGAQQB2kcPAQEHQIvVCKWPutMpY7ED7YDL8qev9tgCb5RSXPkzirJJ
WjDZiQKzBBgBCgAmAhsCFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGK8FCQhD
yzoAgXYgBBkWCAAdFiEElgyGKNWS/4zei7C/4OLe4dbI7voFAlmF9HQACgkQ4OLe
4dbI7vpdcAEA2GBaDiUbWapujHFGfh/a3MH1mXU/7Vrf+6aCBSoqwlABAOlljw5f
6gCnD6b8LjBIsS2W/U5jTtAt1aouzFDvhioICRCs5Wlx1VXapcvPD/0bteHRI4dW
3r4XqFKKVbKsc6gRaQRfUOZq3L0Pcadx0BoJorjnzCRY1KytAqyAjYH2ossd10Fm
MLL5RTkNBvdcWTD6ZKIJQICEu0o2BJcPzKXVB2pJNsHJSMQyhAqbgUKfnePJza+4
p80PL6eBWttufKcNtJwYgkTJhchKoa+Se2h2mt53v6jdIusKwM91dW+0U5E6Jkom
v3CKsSSsWIh8F5OpPJVz7/+2lThO2NOzLth762cV+yqsPGr9Dr9zsCkiIhRfr7hj
2L4AxO0ljYzd6FuR17WSvqHx3x2Sz8D2B5HxNQ0o6wxlnH3AlEti6/zSTtc0+AOx
nOTZwj/CPQrly4MP8fNbhjOVNoLcfyq4u2/HB843/IWv+S7rob6qHF3rJ49Ltl8+
nsUJ2JKBUue9L5RnEPgIHuuFwDXp9XRXoj0+s2W2N0IScpYFj0HRW9/0NV3pn+t3
C2L5aCiCFSX9Ueg42RoPQR8szYyrhpmLVdNkuTSX5l86RLVMNw8ncuhpHvClOoRM
REjLwYgf9g7T3kygf97LzAjlPSVcAw98HkdEV+h5V6AqOJkHNXfRHPiCLglF0S24
ePGprxeIN8ufmOdkdkpH91RhQRybVOtyQdrgIPnpBFBaFMfV0sDb+DcSx7hvYgHW
kJqXDu2iDN2W3ZySYVrR/yLkuuawf9Lpcbg4BFmF99oSCisGAQQBl1UBBQEBB0CC
RNDhUo58xjQ/zW1Kebdb8evrP6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwW
IQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0
D/9JxkCkLkyOYx+rnOUugdwfQ7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGt
FHLI0k6nxCsk6QNz8TIpBGx1oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJd
P3ADM+Dzgwvm4hUuRD2gLEIwC0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o
7oZN5T2Lpi5s86yMuaoUlItj6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFN
A6FUFQpRsgqymPS7MOK6GaQgvctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlIm
DQryAuWV7mWknygKR4uaqem48vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+
27gu3UlE0bz2gNq24IBq6Ew0jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnC
f1S5g36mlWm8HG3XM1OHizdjcB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkx
b1jYpf7rTx6bJbHQuYad879Sts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQIN
YlQItw0yfrM9NUgfePqZumNrrkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md
+aQQEj/YdJgS6uLzteKZBwUEe7jqNmTRtevMZtln9JNjcwAKCRDg4t7h1sju+hI7
AP9qkaDeJL+sLKrNECYHX85Eeyrv5ppLFLc84OZBbEXviQEAgQzCkKlp5/ifZ7MH
fs1i2EZUaf89nRVMAQwuu3PrMwKJFGkEAQEKElMWIQRSX6konxd5jbM7JygTDfUW
ES/A/wUCXr3Zp18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdw
LmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMwREY1
MTYxMTJGQzBGRtEUJgCZAg0EWYXemgEQAKOacFQ53v285zqzLB3Dt3zki1hAN5KH
laFOC5eS3zj7wL6gtdhtZ6VWbKO1n686xlJdvji0TbM0Jai40r/BwTXomaYhXdVW
f0j8SkxMr+IXHd79IaToLnq6imCxAWUONthFnps9z4iawR19qPcPJitYk7d0IQEQ
Q6/j+7tRn+6UEk4RbikImOCTt6yZP0uYbQC9JJRmFlCqoyjnC+t/PTu4NsnowWM9
eAEhOG0k+MpKlNcJpoKzYYllWQpqBHWt7HK0iCwRTc5gcCX6ph8epwWprXFut0SM
LxEMUhTS8lzdoalG58YRWWcPD8t9Y3qpfg0T0gL9DIoVcRA7Js/1QSX22L90ToVR
IdP6D8zjMJ1IvVEUyTP3X9SeOCtkBugygqAFmpgulrCNgjJUxhN0h6sNBiLKYJ0P
4h+SBzcXCBOx9IWcUlfAsvaGokahlLPqMcoqIMMpq2EtCpYS8BsKjoU/lWyoguLZ
O77ohY54unTthfMOIM1Hv/KoMY4Jq9ibA3ea3lPB01453bYsVYcsFywNzmAgHYSQ
mgyl6YbVMmLrQVf0/ZYjwrsgIGYXPCe8f2LbEGWf7j5gMfKh3tyULUjTATYFs7q2
01pRH/pdzObyCPHTPMqy85lkNNeNe07yyzjWPtGDRNLcLj5BYxyYcIkKK7y0PgZL
l279XnHDxMnxABEBAAG0EjB4QUNFNTY5NzFENTU1REFBNYkCXgQTAQoASAIbAQIe
AQIXgAIZAQsLDQkIDAcDCwoEAgYVCgkICwMFFgMCAQAWIQR5EMRfifyMwsvSSrCs
5Wlx1VXapQUCXrAYXAUJCdC0QgAKCRCs5Wlx1VXapToBD/0RoBp776pLHL2IzZrc
l9uqvmQRX6Yn/+vpIigMk9UA19vmgcX8pm0XRr5JdH5w88ExUqymlnRCvzQWSMBQ
4fli5RtOrYH5i+oyjkMuoFrZCIJrHrHXW51IjQgzYIvsjm8xxG5j5n8/cVn1Ej4L
sAsv4SAnrG0XJgc5xVVh39rQ785Mf0o5XBx20MKGtFkE4Ljr7mGVwXF3efAxSZel
EPU8Tn7bS9RubLPa4qMef3d86HYw0wuGg72pyL6QqWJrC5TtRDjZVM7oW1RKhSmA
+HfuxUwiZ7MLiNib/V3cAU8LGkCM/uYeArE7A/p/D6EgRajJu/RazcESEzhMieht
BSzTB2xYtDzfHkv0i8RwvrjeaQtvEIDjwWLDZhNbK4R2Eh5I60tOszaTnENVfmQ8
BIaobutM/97EGjlWDZRlaE8m6IR9holHs8CXSL7fXzJBKEhaDRm3U5vcrv/fKq8c
MXNoBoo6U30JlHldURzKr0boza67lw5nQtAlOf9QUdg4rwP39Pfdl9pzy0iOIif3
XqLVi+pgjNLXgYpLyiohLLcWQPfa1B/yiT/w++dd7XFA9MC0iPdSqmJB/QvzG33q
EskcqmGZH+SwpgEN1kVZEP9TQ1qReOd6k/R6Trx9HfA7iVtgob3H3hgMz/ulDUGl
9lkwuun7fG9MHGaBAK0C5SIl6bkCDQRZheBoARAArGP94En3E7nyvb+5DTBuBVEK
rQcI+bG2SiCKqXNkFUZEKdqAXJomm2oNNMugMLeoSncORSkQRMFlzGjaK84f7S+i
vsP4WL/F5+h1A9AbhZsRe46FC+GBDf1/1gcf+TXjoe8r3WrY3OutFxJmsFqqayaf
z5u6gr66pKHVSNZQD9drFt2c/L4A2OcEUO1VBGJmu/vuz7/yueFZubYU7udkeHJX
2bplLjUxjOjUZaDSeXSYGinBs6UVTQNumIjZrd++QPhj2G5VnsZx4d2/JPDD/r0r
cYZQctiWnlj60o+fK4/GcDcPCQjKKC74eQwqVjynFYBVRGj/xp/hmARQROIajapK
7E7aFEN897NK9X906dRF81W809jycSSka+LFQ93f34oNrnrAO0xmzgyhg5wsTbxm
Hv7Iml/0bwnMDMiOAca8+oNAGWTZ9xmScBq8zRTfoECYMqV1974/7OqL3L9msQ37
dnkEGlio/zEWbbpOYQusiJUZW/W499oz80rsBSnXvF+ba3lnRqF9YU4ZI4MJtO3h
VBhgwV/uRw1WDRM8MITKixNBIyYqpfD81fQ5jjXLU3oKI1aASllJiyHS2e/ITTOH
ljL+TLeCdpiU0ssT+/ygB4c1Xoq/Fb61kBbJaI2sZObSYvGotOkJxxFdqF29UVE2
B4T8emCi7Lxp6Eco4qEAEQEAAYkEcgQYAQoAJgIbAhYhBHkQxF+J/IzCy9JKsKzl
aXHVVdqlBQJesBiuBQkIQ99GAkDBdCAEGQEIAB0WIQRSX6konxd5jbM7JygTDfUW
ES/A/wUCWYXgaAAKCRATDfUWES/A/xgsD/9ilpI8Ku4mWcy8Jus/5yHHfT8V4ieR
ZfvTVykh1NVdVCyAiRaftrjXRkBMpJgowIXsMQetMZIp1mjYOdfNryb4gD0hifl3
TLl9yp1qXRAeVxpzVx+LgS+Q+HjIFmXhq+rQhnJWjjqgVHiQpkVUlZYRYttK0w6l
kToWyY0oRqjsv4UY2NNsI4Ufb9+EXx/W1cvgcf9lBpDll345NH96r6gZBZAZfU8K
51Qdap2oG/FTr11Dc8G4n1riAwM0T+1qpCUgAdmshq/tRMZ90oYICClNUcn44qqv
jtVPmtUURa0yybzki83+RxTRfWxVbIg5m7W6qcXm4K852Mj33VLBrH4ufiZbZnla
Iqz3i9VCLUcG0eCt0HmuX8P0Lv5jT03isOB2JtXyec7puoXMIYA7FiQKzsppbfbr
RC90nsJ5KI4tuba6wHvgLNvnTqP8iURrkxi/Tkcz48bfcOrrKk6CPvB30f5psUBL
e51ItMv2oQcJe85PQtPjClT6qgBZY8mmu0vuzTDVsEXLSEPAObVnVHc+jN1SbVCe
CYQETPi2Ul10w+yWx7D5G6iIH2kKxqZzlix+j10MJ7IVmjhANoQXc2vjflfM891N
omgWlOjyWEB7/0UHBlFNFk+17tyDM5FIDzf4DH6Bu0oBkfcgVCme80x3XgQr5TCB
WLcruxXOwVBDLgkQrOVpcdVV2qXsVw/+MxaSn/excv/noT6F65jXz8ghJhb1DXvF
lVNUNKFYxOwAOL4w89sIFIoZBu8yFO7vxhxfqigY/TCWU+fqNBk1jsPUuD4Tj9Lk
izwmDkdj+oHztoJi0BuS2ld8myqyMan5NxL9Bsqm0F4KYYaOwNGK6S/AGrpejerx
8z6y8tck8QJjlQI0zUWqeBMxW4c/GBFtTSMmKb9+a4lvI6OwbVKwvd1+51sj2Mzh
BY9ne9UTUhXx8FQiCFgJbsIMzs8aR5jjB4vYPohLwBPsXR+cQClIsrc6n8vYNpn/
W1RC8C41VWL8bvLkNCKbWkVSmEXQSAj8p7kHilSsHjDVT6gqCUgoWqSuD+4qflKq
Y3XVQ2TVx++xKEUpCZZFHd8QlX1ixZTnmO5n1zbFsqpMtr0PcbUZtyjmjvIGqF4l
vrp9WXGJatbhE4G805PYa8Eg87jHxJWK7NnCe+8+wnY5D0T0FsJbdfJ7Y+GAgK6j
vBpYGl8CdcWaa0ksYHj7TbgrjGOZQF/Z2n1r0fIhEZMGDwijuH77iiNVXuWMvJ81
RJxUbp1dnYTBnNnIUS+458gBGs3jFgl6mzsEKzVvWf5vS7XK5Beaqu7FQd6WUrkQ
VLH6pyaZu1NVW/Il6LbrRB4co1aReC0Ei5AOcWz2ayJoISXBJ3GRgiiyQ8XG/sfD
h4I3q6mbJ8m5Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWN
Bowuv1INtprqa15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvy
UR1S///MmwI5qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6
NtbH/yeshOuRhT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CU
vz5H+EzGAdmrXVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO
/gYVoWX5Fd4dv6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQ
ibo3JVNTRs/PPIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l
6OrgI8aWQyrcf4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5Qb
kSMeOvqJWzgktxvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr0
4euhFnyMaiDMKS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjm
j9Nkv18qmF8O21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1Ymu
oD8nABEBAAGJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY
4QUJBrb74QAKCRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3Wv
PJwbrFR7L3Jkx3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou
6NLxM4ynxkV8Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcC
tOsjOffWWD1YACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L
5jjkFpSDQo+/jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN
9sujxRgXkccIznci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOk
PVTbDadspla82oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/w
iUBjfJXT3ITorl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg
30LsQtFWgiwNtYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1En
BUJi49O0SfqsvoFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0A
bvIetF5qO+pJY/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4
GFu/ufjNzrg4BFmF99oSCisGAQQBl1UBBQEBB0CCRNDhUo58xjQ/zW1Kebdb8evr
P6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx
1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0D/9JxkCkLkyOYx+rnOUugdwf
Q7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGtFHLI0k6nxCsk6QNz8TIpBGx1
oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJdP3ADM+Dzgwvm4hUuRD2gLEIw
C0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o7oZN5T2Lpi5s86yMuaoUlItj
6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFNA6FUFQpRsgqymPS7MOK6GaQg
vctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlImDQryAuWV7mWknygKR4uaqem4
8vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+27gu3UlE0bz2gNq24IBq6Ew0
jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnCf1S5g36mlWm8HG3XM1OHizdj
cB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkxb1jYpf7rTx6bJbHQuYad879S
ts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQINYlQItw0yfrM9NUgfePqZumNr
rkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md+aQQEj/YdJgS6uLzteKZBwUE
e7jqNmTRtevMZtln9JNjcwAKCRATDfUWES/A/2X2D/0XqTVlrImVggor6ACWDNV4
JQfdkLpQWyaI4jdwW5WXP/Xd09fqA43AiVuNTV+KzI1vhAJkMmEH/cH6IR89Wb1s
3XAgkNvU897me3mg1gLe5kL2agOUwth6tM7Neew7EiydhZBumf8FE2yarmJSvdDx
xZrBcfDPx5Ld8eghsMcV9jzHlRz9OvjeWkvEax7RBr+UvLHDtdUal8Ats4DGJXa1
KFSOvfoC3RGuNxGZyoH2YttG62F1Nokh8j8YWVzy+KXTNex2XZyvhEOOwoh2ynSZ
+fUUaEmrSMwblDPRudnWt25Svae/tHqrptgN1Y9tyuiZt1YLQipnVqYyifq5/Pl3
Biq1ECJdl1ym8fQweJZdhaQ4J5mjuIIL/L0j9X2zsczTjwrl8p5NbaQ808IADtHB
xOyPW3gzrCPX4zQxVJInemBZmMGL4071faLpl/uGCEaS2KLE8iLKIQV2itrGSHj8
h/wvVhjVfqPdrTfR3N1n70KfAHNnrR6N5d6euqJrTaB4DPempI8IR5HGDzdq1J1V
GeH5Vhqq9ihzxXVRTrRP2c9RoAWYNBYF37bxRH5lcjFgYBNyHjzfozZ+AZdE0WcA
RjfdBwsdZJrUrgtu7YTLAf0/v9mZZBAXfvO8CgNySZfWWZ5IP0BvHLgkUXI0r7Qt
kuQMuu7LJiMJFrPQKIL1cQ==
=XcGg
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Comparison of RSA vs elliptical keys [ In reply to ]
MFPA wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi
>
>
> On Thursday 14 May 2020 at 11:41:00 PM, in
> <mid:20200515004100.00005d5c.sac@300baud.de>, Stefan Claas wrote:-
>
>
>
> > GnuPG should accept
> > such public keys,
> > without using extra parameters and that you can
> > easily add them to your
> > key ring, with a simple label, thus not revealing the
> > identity of them,
> > in case your computer or smartphone gets later
> > compromised or is
> > searched at an airport etc.
>
> Does that mean the "simple label" doesn't identify whose key it is? Or
> have I misunderstood?

It simply says that you can assign to such a label whatever you like,
say a nickname or whatever.

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


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

1 2  View All