RSA pub-sec pri key pair + ELG enc + RSA sign subkeys + EDDSA/ECDH subkeys -> e-mail familiar RSA/ELG key recipient

[Brian Minton]

On Fri, Jun 10, 2016, 3:58 AM Fulano Diego Perez
<fulanoperez at cryptolab.net <mailto:fulanoperez at cryptolab.net>> wrote:

    will gnupg 2.1.x automatically select the senders' older _non expired_
    RSA/ELG subkeys so the recipient can decrypt/verify signed/encrypted
    email ?

    is the converse true for the sender for whatever software implementation
    they use (is this wishful thinking?) - in that their software will not
    fail after detecting newer incompatible subkeys, and then proceed to
    select the recipients' older but valid, compatible subkeys ?

    in other words at this time can gnupg 2.1.x automatically, compatibly
    operate with both RSA and EDDSA/ECDH keys/subkeys ?


This is exactly the situation I'm in with my public key, 0424DC19B678A1A9.

Here's what gpg2 -K shows:

sec   rsa4096/0424DC19B678A1A9 2014-10-08 [C] [expires: 2016-10-07]
uid                 [ultimate] Brian Minton <brian at minton.name
<mailto:brian at minton.name>>
uid                 [ultimate] Brian Minton <bjmgeek at gmail.com
<mailto:bjmgeek at gmail.com>>
uid                 [ultimate] Brian Minton <bminton at blinkenshell.org
<mailto:bminton at blinkenshell.org>>
uid                 [ultimate] [jpeg image of size 5202]
uid                 [ultimate] Brian Minton <bminton at freeshell.de
<mailto:bminton at freeshell.de>>
uid                 [ultimate] keybase.io/bjmgeek
<http://keybase.io/bjmgeek> <bjmgeek at keybase.io <mailto:bjmgeek at keybase.io>>
ssb   nistp384/EA49CFDB55D113E9 2014-10-12 [E] [expires: 2016-10-11]
ssb   ed25519/37B9507ACFF2016E 2014-10-12 [S] [expires: 2016-10-11]
ssb   elg3200/28FA8B9659A70692 2016-03-07 [E] [expires: 2016-10-10]
ssb   elg2048/25353D56E26A744C 2014-10-09 [E] [expires: 2016-10-08]
ssb   elg2048/32483BAF5EA82613 2014-10-10 [E] [expires: 2016-10-09]
ssb   dsa2048/6B8EB3A065CFBAA9 2014-10-10 [S] [expires: 2016-10-09]

For encryption, people encrypting to you will use whatever key their
software can use. If the ECC key is newer, then senders that can use it
will by default, while senders that can't will use your ELG key. So,
keep both secret keys available and you'll be fine.  Note that I have a
few extra ELG keys which I keep around just in case I need to decrypt a
file that I encrypted with them.  There's nothing wrong with them, so I
haven't revoked them.  However, gpg (and probably other PGP clients will
use the newest usable key, so people encrypting to me with gpg2.1 will
use EA49CFDB55D113E9 to encrypt, and people using gpg 2.0 and earlier
will use 28FA8B9659A70692.

For signing, I like to put both key IDs (in my case, ed25519 and DSA) in
my gnupg conf file, so signing automatically uses both keys. The trick
is to use the key IDs of each subkey with an exclamation point so gnupg
takes that specific key.

For instance, here are the relevant lines from my ~/.gnupg/gpg.conf-2
file (side note: if you use both gpg 1 and 2 you can use that kind of
config file name to have different config files for each version):

*local-user 37B9507ACFF2016E!
local-user 6B8EB3A065CFBAA9!*

The nice thing about this setup is that I don't need to have any sender-
or recipient-specific rules.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160610/0364e631/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20160610/0364e631/attachment.sig>