"best" ed25519/curve25519 setup?
guilhem at fripost.org
Wed Jan 24 00:10:12 CET 2018
On Tue, 23 Jan 2018 at 09:01:25 +0100, Simon Josefsson wrote:
> Guilhem Moulin <guilhem at 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
>> * 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.”
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Gnupg-users