Re: Comparison of RSA vs elliptical keys

[MFPA via Gnupg-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


> For sure the MUA knows your own key.

No. The MUA just passes the email address to GnuPG and GnuPG selects
the key.


- --
Best regards

MFPA  

Eat well, stay fit - Die anyway
-BEGIN PGP SIGNATURE-

iQQLBAEWCgOzFiEE1ZATtM6MlUs0sIeidL1wjXEhZekFAl7b0BpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ1
OTAxM0I0Q0U4Qzk1NEIzNEIwODdBMjc0QkQ3MDhENzEyMTY1RTnCdCYAmDMEXgvh
ABYJKwYBBAHaRw8BAQdArI4Hnf6FTTsybpJYDIMD0+xTrXnsPfC/3Uu2cxa4teW0
EjB4QjkzQjIwRjNDNjUwREFCQ4ifBBMWCgBHAhsBDAsNCQwICwcKAwQBAgcVCgkI
CwMCBRYDAgEAAh4BAheAFiEEqezluzzMIo36IIunuTsg88ZQ2rwFAl4L4QIFCQLP
0wIACgkQuTsg88ZQ2rwoOgEAiWZc9DebbXONXemf/QkWTxhV7OBcg983xmEhV9l1
LwYA/AzZAko/rn0Erv1M4ZjAtsDqeAFt0PNNeUmi4eGUwyIOuDMEXgvhARYJKwYB
BAHaRw8BAQdAi9UIpY+60yljsQPtgMvyp6/22AJvlFJc+TOKsklaMNmJAVYEGBYK
ACYCGwIWIQSp7OW7PMwijfogi6e5OyDzxlDavAUCXgvhAgUJAs/TAQDiwBYgBBkW
CgB9FiEE1ZATtM6MlUs0sIeidL1wjXEhZekFAl4L4QFfFIAALgAoaXNzdWVy
LWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ1OTAxM0I0
Q0U4Qzk1NEIzNEIwODdBMjc0QkQ3MDhENzEyMTY1RTkACgkQdL1wjXEhZem5+AD9
FKjnQrwvWofniFDjLQgiAcTmZWJaLE4AhWBDS5lc6rMBAIst24nbfvXzFmjwtowD
q4GzfSi67WeVp7XFtdF0OAsDCRC5OyDzxlDavEvRAP4vRocpa0PyNtwNKhNPSHIO
9hVI1r9FomgHqZOyo2YFcwD/cMdoU7nLsARyoihiD01sdZ4nNpiPzD/mZBwLwY0K
0wa4OAReC+ECEgorBgEEAZdVAQUBAQdAgkTQ4VKOfMY0P81tSnm3W/Hr6z+kFNu8
bjH6Y9FkUX8DAQgHiH4EGBYKACYCGwwWIQSp7OW7PMwijfogi6e5OyDzxlDavAUC
XgvhAwUJAs/TAQAKCRC5OyDzxlDavJ4WAQCRf2LVenMTVSM7k2BlDJV+Y410xT14
R3eKvpIPDO9iagD+NrZruWKSTD93k6V38dewDa5Tn0LSbHcGidiazqREogMACgkQ
dL1wjXEhZengGgEAtkVJtrhO63gg+8W/vEOtPmlhyicLneItm195ikeQs6YBAK/K
Of9LOL3CXEQzyoLaM1GtWqyjQ+A9d94rXjyZHD8IiQ8RBAEWCg65FiEElgyGKNWS
/4zei7C/4OLe4dbI7voFAl7b0BtfFIAALgAoaXNzdWVyLWZwckBub3RhdGlv
bnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2MEM4NjI4RDU5MkZGOENERThC
QjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF3poBEACjmnBUOd79vOc6sywd
w7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyjtZ+vOsZSXb44tE2zNCWouNK/
wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopgsQFlDjbYRZ6bPc+ImsEdfaj3
DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7esmT9LmG0AvSSUZhZQqqMo5wvr
fz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkKagR1rexytIgsEU3OYHAl+qYf
HqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/LfWN6qX4NE9IC/QyKFXEQOybP
9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/UnjgrZAboMoKgBZqYLpawjYIyVMYT
dIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJGoZSz6jHKKiDDKathLQqWEvAb
Co6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGOCavYmwN3mt5TwdNeOd22LFWH
LBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBmFzwnvH9i2xBln+4+YDHyod7c
lC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTXjXtO8ss41j7Rg0TS3C4+QWMc
mHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFDRTU2OTcxRDU1NURBQTWJAl4E
EwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIGFQoJCAsDBRYDAgEAFiEEeRDE
X4n8jMLL0kqwrOVpcdVV2qUFAl7VLfsFCQWgFTsACgkQrOVpcdVV2qVD5hAAjbEz
bwbyBdscKbawdz3H6rWoeuoMJ1IInK3u5qrFAQwTrlsNmNFj8mDqsZGcgOiTKVlb
Kr+zokLIazna7poly/fMOKFB0ryGO/nJaHdq6z7x359wL77avx0oK+LFZvgAyQHF
kmSKxL1t3yQ2JtjaXzJ30dYuEK9W9CD7XBvKbDUk1AxGYfh1zO7c1jbjstgyXq2e
J+mAJaJYqPzVN7+GGPPb4rV6/hZLsbyp3lrnzSZmB9fVzUQsRcPgBxKlP3zEytRu
fmdmXYShml4PQIuyB4xOuqlhTZZ7//4C9AUMz+cYhrBY0RSNHrjUdbMZLwWukMCk
zc5LeDn73Y3uaRTCwVqxIZt9IPq03sj6tU8ytTqX/ToK4bfyWhPVENwHE3WQq8m+
hXtLiHAD4stFVXby6vBDpyKYgegiiYM5qubrot7smXY5GDCIjwZ7dsORDPry21t2
fh9fkNTXPYklaQXFklCaI9RMskkbooQZWrE68lhUhOd0423J4WE3XlVRbCpj+U9i
tq4iF8ueSCw5KtTs8prkNva/MW+PzbZ/FpHOenAiD6NgXB2Zr3OS5AH+cajsQHrx
Ns4f8KZEB34ZHhYI/yFuczsFRq0/BNQPsdvnnM7Y9Oa39iSwdTSv8Z/Z6I1NjJAy
tm/K1f3qSFzE5WRgXrUEjXIc1A9y082u3QYskvK5Ag0EWYXwgAEQAO+wh3g3SgeB
WkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprqa15yRpaIr8eFlchlVqCiQ2FN
54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5qos0A+Sil3uPsuBQtRezCaNE
ghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuRhT2P3jFK0+kIObyPO26Xsbfd
bocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmrXVYD/VFxMrbIkKjmb7I0Tnl8
RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4dv6EQmvHMfiIvsxP8EBOTNVEt
j/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/PPIlVmPROYLbXaolufgAmi+E8
BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrcf4uW4Jtn98AldJ21PhtN4A0d
5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgktxvULI53Q3jtZvgtmF2dZ5rF
gJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDMKS0XAj978kyCUrtDsssWp83j
1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O21Qe0LzG8Ad9HPTbQd9Rk+GQ
z57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJAjwEGAEKACYCGwwWIQR5EMRf
ifyMwsvSSrCs5Wlx1VXapQUCXtUuawUJBaADdQAKCRCs5Wlx1VXapW7JD/0fKfbj
JLJIKIF5AemDcDN60FMvkM/6K14ScQsdO9z/RnCO2C4riGz3Otw8ZHQGVS1E353l
fGKlyDtv7yJtzLb/6FA+I/2u+sSoK8WYpfShl2m+C0gYPqC9/4Qc5fVvpvw0lMWg
dbGIHIcXx7fOmEl58VMlWWVIkZWPTfyJXDQu+55ZG+sK4CqLL6ffXFqP33pyMg0E
uy6vzH664tbyceiuhF9ga8WQ1vg4ByANBzBkMcZurdMC0BLlSEVIZrRsARUul7gZ
rpDGz0BgOnI0ztOgFrdU/hcnV5pQasF083u5rgZbIKHLosPtFA5T8cQ8XoHqI6jI
UnC8E6Fe12wL0XE/2FDUgUHriXK3acU4MKyW30RzO1l4c7h18zrTfVRLN5JY+KLN
jv3ptD8nT7JqGgNqSWA5qqfP6IpVCsCGQvN7uNm1ywmpQJxiONUiXkJEPtDgW/t9
p7jMoo7cfIPtVdrILB4nxHKTQSU9to39wOeUUHk2qXntT9dqSGYqHooezfktsFtx
yQ+7d9xAi9VRQukMLk5rog/GGH8+67vFxzZJhYTDmKfzBuHTnm2HjcV9k7gqrTiG
5ZuXKavtnxhjnns9Bfuuj6YZkD2eGwpazirWzi8udrsQ+/WvmHUI4XMVjTNwSNtj
PmrHVung/urdu/l+jhw4441y0Pbc5l3Off5/xbgzBFmF9HQWCSsGAQQB

Re: Comparison of RSA vs elliptical keys

[Werner Koch via Gnupg-users]

On Fri, 22 May 2020 15:08, MFPA said:

> How would it be used only with ECC keys? The MUA doesn't know the
> flavour of key/subkey.

For sure the MUA knows your own key.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: 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

[MFPA via Gnupg-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Friday 22 May 2020 at 9:52:35 AM, in
, Werner Koch wrote:-



> No, it is better to let the caller (ee.g. the MUA)
> pass this option

How would it be used only with ECC keys? The MUA doesn't know the
flavour of key/subkey.

- --
Best regards

MFPA  

There is no snooze button for a cat that wants breakfast
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXsfc218UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+u+dAP499g1GlTd1mJXXE6GVhWp4OUGdcspAJ1qpLJDkTV0bwwEA0q53yxehqA1a
jl+5cgVZu3ZpJiEMtzp+6P8If0a9eAo=
=U1MD
-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

[Werner Koch via Gnupg-users]

On Wed, 20 May 2020 18:06, MFPA said:

> Does (or will) --include-key-block have an argument that can be set to
> tell it to only include ECC keyblocks, or to set a maximum keyblock

No, it is better to let the caller (ee.g. the MUA) pass this option than
to have it in a config file.  (I initially used this too in my gpg.conf
with the result that all my Git commits carried my key, which is
useless).



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: 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

[Ryan McGinnis via Gnupg-users]

Interestingly enough, this breaks the Thunderbird/Protonmail integration, so 
your message just shows up as the raw PGP blob that Protonmail is pushing to 
the Protonmail client.  It returns the error 


" Decryption error
Decryption of this message's encrypted content failed.

openpgp: unsupported feature: nested signatures
"


-Ryan McGinnis
http://www.bigstormpicture.com
Sent via ProtonMail

‐‐‐ Original Message ‐‐‐
On Wednesday, May 20, 2020 12:18 PM, MFPA via Gnupg-users 
 wrote:

> Hi
> 

> On Saturday 16 May 2020 at 9:49:55 PM, in
> mid:20200516224955.5826@300baud.de, Stefan Claas wrote:-
> 

> > out of curiosity, you signed the reply with two sub
> > keys,
> 

> The RSA signature is for the benefit of recipients who can't handle
> ECC keys/signatures. Probably not needed anymore.
> 

> > the hash algo
> > used?
> 

> I'm hopefully using SHA512.
> 

> --
> 

> Best regards
> 

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

> Ballerinas are always on their toes. We need taller ballerinas!



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

Re: Comparison of RSA vs elliptical keys

[MFPA via Gnupg-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Saturday 16 May 2020 at 9:49:55 PM, in
, Stefan Claas wrote:-


> out of curiosity, you signed the reply with two sub
> keys,

The RSA signature is for the benefit of recipients who can't handle
ECC keys/signatures. Probably not needed anymore.



> the hash algo
> used?

I'm hopefully using SHA512.

- --
Best regards

MFPA  

Ballerinas are always on their toes.  We need taller ballerinas!
-BEGIN PGP SIGNATURE-

iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl7FZlpfFIAALgAo
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+rnOUugdwfQ7kRuUVkx

Re: Comparison of RSA vs elliptical keys

[MFPA via Gnupg-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Monday 18 May 2020 at 7:33:47 AM, in
, Werner Koch via
Gnupg-users wrote:-


> You are using --include-key-block; this is intended
> to be used by MUAs
> to send the encryption key along with a signature to
> allow for immediate
> encrypted reply.

I forgot I had added that to my gpg.conf file.

If the recipient has --auto-key-import set, they auto-import my key
after signature verification. But my choice to not include my email
address in my UID means they would not easily locate my key to send me
an encrypted reply.


> Or use it only with ECC keys.

Does (or will) --include-key-block have an argument that can be set to
tell it to only include ECC keyblocks, or to set a maximum keyblock
size?


- --
Best regards

MFPA  

Volvo, Video, Velcro. (I came, I saw, I stuck around.)
-BEGIN PGP SIGNATURE-

iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl7FY6hfFIAALgAo
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
C2L5aCiCFSX9Ueg42RoPQR8szYyrh

Re: Comparison of RSA vs elliptical keys

[Werner Koch via Gnupg-users]

On Sun, 17 May 2020 04:33, Ángel said:

> In both cases, most of the signature space is taken by a hashed
> subpacket of type 38. This value is not assigned, but looking at

You are using --include-key-block; this is intended to be used by MUAs
to send the encryption key along with a signature to allow for immediate
encrypted reply.  This is similar to what has been done in S/MIME for
decades and a mitigation to the comedown of the keyservers.

MUAs may decide not to use this on mailing lists - if short mails are
important.  Or use it only with ECC keys.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: 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

[Mark]

Thanks to all the people that chimed in on my question. I was trying to
get an idea how they compared. It was (for me) even more confusing with
the 25519 choices as I didn't know the size of those keys until someone
explained them better.

On 5/11/2020 6:46 PM, Pete Stephenson via Gnupg-users wrote:
> 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
>

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

Re: Comparison of RSA vs elliptical keys

[Stefan Claas]

Ángel wrote:
 
> On 2020-05-16 at 22:49 +0200, Stefan Claas wrote:
> > out of curiosity, you signed the reply with two sub keys, but
> > what makes the signature so large, the hash algo used? I must
> > admit I have never seen such a large signature before.
> 
> It is quite large, indeed. This Radix 64 block of 12375 bytes contains
> two signatures, of 3857 and 5225 bytes respectively. The first one
> EdDSA (22) and the second a normal RSA one.
> 
> In both cases, most of the signature space is taken by a hashed
> subpacket of type 38. This value is not assigned, but looking at
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=common/openpgpdefs.h#l123
> it is used to store the whole key used.

Interesting, thanks for the explanation!

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

[Ángel]

On 2020-05-16 at 22:49 +0200, Stefan Claas wrote:
> out of curiosity, you signed the reply with two sub keys, but
> what makes the signature so large, the hash algo used? I must
> admit I have never seen such a large signature before.

It is quite large, indeed. This Radix 64 block of 12375 bytes contains
two signatures, of 3857 and 5225 bytes respectively. The first one EdDSA
(22) and the second a normal RSA one.

In both cases, most of the signature space is taken by a hashed
subpacket of type 38. This value is not assigned, but looking at
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=common/openpgpdefs.h#l123
it is used to store the whole key used.


Cheers


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

Re: Comparison of RSA vs elliptical keys

[Stefan Claas]

Stefan Claas wrote:
 
> MFPA wrote:
>  
> [...]
> 
> > -BEGIN PGP SIGNATURE-
> > 
> > iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAALgAo
> [...]
> 
> > RjfdBwsdZJrUrgtu7YTLAf0/v9mZZBAXfvO8CgNySZfWWZ5IP0BvHLgkUXI0r7Qt
> > kuQMuu7LJiMJFrPQKIL1cQ==
> > =XcGg
> > -END PGP SIGNATURE-
> 
> Hi,
> 
> out of curiosity, you signed the reply with two sub keys, but
> what makes the signature so large, the hash algo used? I must
> admit I have never seen such a large signature before.
> 
> And slightly OT, when not counting the two last short lines
> in the signature, 378 NaClbox public keys would fit in in
> the signature! :-)

Correction, a NaClbox key is 32 bytes but in an ASCII representation
64 ASCII chars long in the key ring, so it would 'only' be 189 public
keys.

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

[Stefan Claas]

MFPA wrote:
 
[...]

> -BEGIN PGP SIGNATURE-
> 
> iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAALgAo
[...]

> RjfdBwsdZJrUrgtu7YTLAf0/v9mZZBAXfvO8CgNySZfWWZ5IP0BvHLgkUXI0r7Qt
> kuQMuu7LJiMJFrPQKIL1cQ==
> =XcGg
> -END PGP SIGNATURE-

Hi,

out of curiosity, you signed the reply with two sub keys, but
what makes the signature so large, the hash algo used? I must
admit I have never seen such a large signature before.

And slightly OT, when not counting the two last short lines
in the signature, 378 NaClbox public keys would fit in in
the signature! :-)

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

[Robert J. Hansen]

> Certainly there are many reasons to extend the standard, which is not
> set in stone and which is not a politically adopted law, for meaningful
> things.

Yes.  If you want to talk about changing the standard please bring it up
to the proper mailing list.  Here is not the place for it.  If you can
persuade people to change the standard I'll be wildly in favor of GnuPG
implementing the standard.

> Of course, a program author has the right to design his program as he
> sees fit, but please don't be surprised if far-sighted pioneers expand
> this standard to meet the needs of a user base who would also like to
> use this standard.

This is irrelevant.

We're talking about what GnuPG should do if someone specifies strict RFC
conformance.  The answer to that question is simple: it should strictly
conform to the RFC and treat UID-free certificates as the malformed
entities they are.




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

keys require a user-id (was: Comparison of RSA vs elliptical keys)

[Werner Koch via Gnupg-users]

On Thu, 14 May 2020 23:01, Stefan Claas said:

> you would consider including it in GnuPG too and reflecting it in the
> respective RFC?

The User-IDs are an integral part of OpenPGP and at the core of its
design.  All kind of important information is bound to the user ids and
thus a key w/o a user ID is basically useless.

There is one exception for this: Derek Atkins (one of the original PGP
authors) requested certain features to allow the use of a stripped down
OpenPGP key by space and CPU constrained devices.  We integrated this
into the standard because it is better to use even a stripped down
format than to come up with just another format.

Direct key signatures were never intended to replace User-IDs and their
self-signatures.

And no, it is not a privacy issue.  If you don't want to put your name
or mail address into the user ID, just don't do it but use a random
string or even the keys fingerprint.  For the majority of use cases a
mail address is still the best way to identify and even lookup a key.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: 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

[Stefan Claas]

Robert J. Hansen 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,
> 
> Sure.  And if they're important enough for me to justify breaking
> compliance, I am perfectly capable of removing the "rfc4880" flag from
> my gpg.conf file.
> 
> There is no excuse for willfully breaking RFC4880 compliance *when the
> user has explicitly requested strict compliance*.

Certainly there are many reasons to extend the standard, which is not
set in stone and which is not a politically adopted law, for meaningful
things.

Of course, a program author has the right to design his program as he
sees fit, but please don't be surprised if far-sighted pioneers expand
this standard to meet the needs of a user base who would also like to
use this standard. 

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

[Robert J. Hansen]

> 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,

Sure.  And if they're important enough for me to justify breaking
compliance, I am perfectly capable of removing the "rfc4880" flag from
my gpg.conf file.

There is no excuse for willfully breaking RFC4880 compliance *when the
user has explicitly requested strict compliance*.



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

Re: Comparison of RSA vs elliptical keys

[MFPA via Gnupg-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Thursday 14 May 2020 at 11:41:00 PM, in
, 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  

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

iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAALgAo
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/yLkuuawf9Lpcbg4BFmF99oSCisGAQQBl1UBBQEBB

Re: Comparison of RSA vs elliptical keys

[Stefan Claas]

Stefan Claas wrote:
 
> MFPA wrote:
>  
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Hi
> > 
> > 
> > On Thursday 14 May 2020 at 11:41:00 PM, in
> > , 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.

Sorry, and this label is assigned to public keys of course.

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

[Stefan Claas]

Andrew Gallagher wrote:
 
> 
> > On 14 May 2020, at 23:42, Stefan Claas  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. 

Good question!

First of all I do not keep an address book on my computer
nor on my smartphone and I use not only simple smpts channels.

Regarding the mapping of email IDs and keys. When I use labels
for my keys, in my keyring, it contains only simple stuff like a
nickname for example, because the peoples email addresses I know
also without using GnuPG, hence I use command line mode and no
common plug-ins. I do not say that people should follow
this procedure, but like I previously said GnuPG should allow
such an option. I am also used to use other communication
channels, beside standard smpts, where this works too.

I don't know if you, for example, knows RSA public key encryption
before PGP was invented. There was no such things like key-IDs
email mappings etc. and people lived with it, while using email.

If you check out GitHub, GitLab etc. for public key encryption
software you will rarely find tools, if any, which use the same
email, key-ID mapping approach GnuPG uses. and people do not
complain about it.

And last but not least, GnuPG is a very flexible tool with
many many command line parameters, so why not allow this option
too for users, wishing to use UID-less public keys?

I see no harm in it, only an enrichment in it's feature set.

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

[Stefan Claas]

MFPA wrote:
 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi
> 
> 
> On Thursday 14 May 2020 at 11:41:00 PM, in
> , 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

Re: Comparison of RSA vs elliptical keys

[Andrew Gallagher]

> On 14 May 2020, at 23:42, Stefan Claas  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

[Stefan Claas]

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

[Robert J. Hansen]

> 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.




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

Re: Comparison of RSA vs elliptical keys

[Stefan Claas]

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

[Werner Koch via Gnupg-users]

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.


signature.asc
Description: 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

[Werner Koch via Gnupg-users]

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.


signature.asc
Description: 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

[Alessandro Vesely via Gnupg-users]

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




























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

Re: Comparison of RSA vs elliptical keys

[Stefan Claas]

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

[Sylvain Besençon via Gnupg-users]

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

[Sylvain Besençon via Gnupg-users]

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

[Stefan Claas]

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: del...@example.org
> You selected this USER-ID:
> "Delete Me "
> 
> 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

[Robert J. Hansen]

> 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: del...@example.org
You selected this USER-ID:
"Delete Me "

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

[Damien Goutte-Gattat via Gnupg-users]

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


signature.asc
Description: 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

[Sylvain Besençon via Gnupg-users]

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

[Robert J. Hansen]

> 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.




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

Re: Comparison of RSA vs elliptical keys

[Johan Wevers]

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

[Grzegorz Kulewski]

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

[Konstantin Ryabitsev]

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

[Stefan Claas]

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

[Sylvain Besençon via Gnupg-users]

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

[Johan Wevers]

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

[Pete Stephenson via Gnupg-users]

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

Comparison of RSA vs elliptical keys

[Mark]

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