"best" ed25519/curve25519 setup?

[Caleb Wolf]

On Mon, 01 Jan 2018 at 19:33:31 +0100, Guilhem Moulin  wrote:
> Hi Simon,
> 
> On Mon, 01 Jan 2018 at 14:28:34 +0100, Simon Josefsson wrote:
>> I want to use ed25519/curve25519, but right now I have an offline
>> master RSA key with three subkeys.  Does it work well to add new
>> subkeys for Ed25519/Curve25519?  What is the user experience in
>> various applications?  I'm thinking MUAs, SSH, git, gpg itself, and
>> also more exotic approaches like K9Mail.
> 
> AFAICT multiple Ed25519/Curve25519 subkeys work fine, with the following
> caveats:
> 
>   * You'll want to sign with both your Ed25519 and non-ECC (sub-)keys,
>     otherwise non-ECC capable OpenPGP implementations won't be able to
>     verify your data signatures.  You can do this by adding
> 
>         local-user $FINGERPRINT!
>     
>     for each (sub)key to sign with (note the trailing exclamation mark
>     to specify the subkey).
> 
>   * You'll want to create your Curve25519 encryption subkey *after* the
>     non-ECC one, as `gpg --encrypt --recipient $KEYID` only uses the
>     most recent valid encryption-capable subkey, I think.  So if you
>     have an older non-ECC encryption subkey, older gpg(1) will encrypt
>     to it while ≥2.1 will use the Curve25519 encryption subkey.
> 
>   * You can use multiple authentication subkeys with gpg-agent's SSH
>     agent emulation, but `gpg --export-ssh-key $KEYID` currently only
>     exports the most recent authentication (sub)key, so you'll need to
>     generate the relevant authorized_keys(5) for OpenSSH as follows:
> 
>        gpg --with-colons --list-key $FINGERPRINT \
>        | sed -nr 's/^[ps]ub:[^deir:]*(:[^:]*){2}:([0-9a-fA-F]+)(:[^:]*){7}a.*/\2/p' \
>        | xargs -I{} gpg --export-ssh-key {}\!
> 
>     (note the trailing exclamation mark to specify the subkey).  Recent
>     OpenSSH's PubkeyAcceptedKeyTypes default value contain “ssh-ed25519,
>     ssh-rsa” in that order so the Ed25519 (sub)key will be tried first.
>     Older OpenSSH — that don't support Ed25519 — will fallback to the
>     RSA (sub)key.
> 
>> The alternative for me of course is to create a brand new key, with an
>> offline Ed25519 master key, plus some subkeys.  Has anyone done this,
>> and can share their experience?
> 
> IMHO it's too early to use an Ed25519 master key in production, because
> there are still a lot of legacy systems out there and that will make the
> whole key unusable for encryption and verification.  It's fine to start
> bring such key to KSPs to improve its reputation and have a less painful
> key rollover later, though :-)
> 

Hi,

This is a bit of a necro post but it seemed most appropriate to reply here.

I have two 4096 bit RSA keys, one is for work, and one is my personal
one. I got given a Yubikey 5
https://www.yubico.com/product/yubikey-5-nfc and wanted to make use of
it. In fact I was thinking of doing something like
https://www.grepular.com/An_NFC_PGP_SmartCard_For_Android as I have a
phone that has NFC.

I do want to email people on Protonmail, I believe they like ECC
https://protonmail.com/blog/elliptic-curve-cryptography/ as their
default now. I still want to remain compatible for people who can only
do RSA.

I am not on Protonmail however, I use my own email server with
Thunderbird, or K-9 Mail on my phone.

What I want to know is, is this still the best way I should set things
up. I was thinking this:

# Personal
RSA offline master key
     RSA subkey for signature
     RSA subkey for decryption
     RSA subkey for authentication
     Ed25519 subkey for signature
     Curve25519 subkey for authentication
     Curve25519 subkey for decryption

# Work
RSA offline master key
     RSA subkey for signature
     RSA subkey for decryption
     RSA subkey for authentication
     Ed25519 subkey for signature
     Curve25519 subkey for authentication
     Curve25519 subkey for decryption

Then loading both keys and the subkeys on my Yubikey 5. I understand
keys cannot be removed once they are loaded on to the Yubikey for
security reasons.

For safe keeping I was going to burn my keys onto an optical disc and
put it in my safety deposit box. (Just in case I lost the Yubikey or it
broke).

My already existing keypair would become my "master key" and I would
start using the subkeys I guess.

The next post in this thread
https://lists.gnupg.org/pipermail/gnupg-users/2018-January/059863.html
kind of confused me:

On Mon, 23 Jan 2018 at 09:01:25 +0100, Simon Josefsson wrote:
> I already have a good RSA-based master key setup:
> 
>   RSA offline master key
>      RSA subkey for signature
>      RSA subkey for decryption
>      RSA subkey for authentication
> 
> So I'm thinking that my new setup should be 25519-based.
> 
> Would you want to use separate Curve25519 keys for authentication and
> signatures?
> 
> So I guess the "perfect" setup for me would then be to add the following
> new key:
> 
>   Ed25519 offline master key
>      Ed25519 subkey for signature
>      Curve25519 subkey for authentication
>      Curve25519 subkey for decryption
> 
> ?
> 

Wouldn't using a separate Ed25519/Curve25519 key like this make it
incompatible with people who are unable to decrypt ECC?

> I could adopt the middle way and continue to use my current RSA-based
> key and a new Ed25519-based key, and have both algorithms available as
> subkeys.
> 
>   RSA offline master key
>      RSA subkey for signature
>      RSA subkey for decryption
>      RSA subkey for authentication
>      Ed25519 subkey for signature
>      Curve25519 subkey for authentication
>      Curve25519 subkey for decryption
> 
>   Ed25519 offline master key
>      RSA subkey for signature
>      RSA subkey for decryption
>      RSA subkey for authentication
>      Ed25519 subkey for signature
>      Curve25519 subkey for authentication
>      Curve25519 subkey for decryption
> 
> I wonder if I should re-use the RSA subkeys from my current key into the
> new one...  I suppose for SSH it would be useful, but for anything
> OpenPGP-related it should be based on the master key id, right?
> 
> Algorithm migration is really tricky...

Wouldn't having a Ed25519 master key be incompatible with anything that
cannot handle ECC? It seems a bit redundant to have two master keys.

-- 
Caleb Wolf