Mailing List Archive

"best" ed25519/curve25519 setup?
Hi. 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.

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?

Naturally, I want the subkeys to be on hardware (smartcard). Is it
possible to have multiple OpenPGP cards for the same master key, but for
different subkeys? Does GNUK handle combined RSA+25519 keys?

/Simon
Re: "best" ed25519/curve25519 setup? [ In reply to ]
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 :-)

Cheers,
--
Guilhem.
Re: "best" ed25519/curve25519 setup? [ In reply to ]
Guilhem Moulin <guilhem@fripost.org> writes:

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

Have you noticed any problem with this approach? I could imagine some
software might be equally confused by two signatures, or become confused
that GnuPG "under the hood" adds another signature.

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

That is an important aspect, thank you!

>> 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 :-)

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

?

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

/Simon
Re: "best" ed25519/curve25519 setup? [ In reply to ]
On Tue, 23 Jan 2018 at 09:01:25 +0100, Simon Josefsson wrote:
> Guilhem Moulin <guilhem@fripost.org> writes:
>> 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).
>
> Have you noticed any problem with this approach? I could imagine some
> software might be equally confused by two signatures, or become confused
> that GnuPG "under the hood" adds another signature.

There are non RFC-compliant implementations for sure, but FWIW RFC 4880
allows multiple signatures on the same data. That's the last octet of
One-Pass Signature Packets, cf. RFC 4880 Sec. 5.4:

“A one-octet number holding a flag showing whether the signature is
nested. A zero value indicates that the next packet is another
One-Pass Signature packet that describes another signature to be
applied to the same message data.”
https://tools.ietf.org/html/rfc4880#section-5.4

That's often used in OpenPGP key transition statements, for instance.

That being said I didn't add a signing-capable Ed25519 subkey along with
my RSA one, and the only OpenPGP implementation I use is GnuPG, so I
don't know how well other implementations support nested signatures.

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

I see no reason to do that for signing and decryption, indeed.

--
Guilhem.
Re: "best" ed25519/curve25519 setup? [ In reply to ]
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

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