Re: [TLS] Updated EdDSA/Ed25519 PKIX document
On Wed, Sep 23, 2015 at 10:33:29AM +0200, Simon Josefsson wrote:
> Hi all,
>
> I have pushed out a new version of the document describing EdDSA public
> keys, signatures and certificates for PKIX. The change in -03 include
> the addition of the prehash mode, test vectors generated by GnuTLS, and
> a section recommending certain human readable names.
>
> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03
>
> I've started a thread to discuss whether it is wortwhile to be able to
> use the same Ed25519 key for both PureEdDSA mode and HashEdDSA signing,
> and I'd appreciate feedback on whether people are interested in this and
> generally if it is a good idea or not. The complexity involved make me
> shy away a bit from it, but it is fun to consider. The thread is here:
> https://moderncrypto.org/mail-archive/curves/2015/000630.html
Some comments:
1) Taking private key example and decoding the ASN.1 yields:
0 37: SEQUENCE {
2 1: ENUMERATED 1
5 32: OCTET STRING
: D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD
: 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42
: }
What is that ENUMERATED 1 for? The text description has algorithm of
SHA512-Ed25519, which would AFAICT be ENUMERATED 2 if private keys use
the same kind enumeration as public keys.
2) AFAICT, EdDSA-20150704 calls the signature without prehash, with
25519 curve and SHA-512 hash "Ed25519-SHA-512" (and the corresponding
version with SHA-512 prehash "SHA-512-Ed25519-SHA-512").
The first of those is AFAIK the same as the old "Ed25519" signature
primitive.
One problem with those names is that those things might get rather
nasty to read when '-' both appears inside hash names and component
separator.
3) Using the same key for both PureEdDSA and HashEdDSA sounds like a
bad idea. However, it would be technically possible to alter the
internal subkey derivation so that different prehashes give logically
separate keys.
Such change would only affect signing, not verification (since verifier
sees the change as different public key).
4) For TLS PoP signatures, does it make sense to use HashEdDSA at all?
Another way would to always use PureEdDSA and perform hash separtion
from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))).
The certificate signatures are different matter tho, since CAs use
HSMs for signing (those HSMs tend to be rather beefy, but still).
Then there are CRLs. I would imagine those are so large that one rather
uses prehashing.
-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Updated EdDSA/Ed25519 PKIX document
On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote: > 4) For TLS PoP signatures, does it make sense to use HashEdDSA at > all? > Another way would to always use PureEdDSA and perform hash separtion > from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))). > The certificate signatures are different matter tho, since CAs use > HSMs for signing (those HSMs tend to be rather beefy, but still). The problem with the PureEdDSA is that if you use a smart card or an HSM (both common for TLS), you have to transfer lots of data to them, something that may render it not really useful. Also the PureEdDSA in most implementations it requires a new API for signing. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Updated EdDSA/Ed25519 PKIX document
For this reason (among others) I am against PureEdDSA. HashEdDSA dooes the job well enough. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Nikos Mavrogiannopoulos Sent: Thursday, September 24, 2015 10:04 To: Ilari Liusvaara; Simon Josefsson Cc: tls@ietf.org Subject: Re: [TLS] Updated EdDSA/Ed25519 PKIX document On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote: > 4) For TLS PoP signatures, does it make sense to use HashEdDSA at > all? > Another way would to always use PureEdDSA and perform hash separtion > from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))). > The certificate signatures are different matter tho, since CAs use > HSMs for signing (those HSMs tend to be rather beefy, but still). The problem with the PureEdDSA is that if you use a smart card or an HSM (both common for TLS), you have to transfer lots of data to them, something that may render it not really useful. Also the PureEdDSA in most implementations it requires a new API for signing. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Updated EdDSA/Ed25519 PKIX document
On Thu, Sep 24, 2015 at 04:03:28PM +0200, Nikos Mavrogiannopoulos wrote: > On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote: > > > 4) For TLS PoP signatures, does it make sense to use HashEdDSA at > > all? > > Another way would to always use PureEdDSA and perform hash separtion > > from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))). > > The certificate signatures are different matter tho, since CAs use > > HSMs for signing (those HSMs tend to be rather beefy, but still). > > The problem with the PureEdDSA is that if you use a smart card or an > HSM (both common for TLS), you have to transfer lots of data to them, > something that may render it not really useful. Well, hash_func_id|H(tbs_data) is 33-65 bytes for most nontrivial hashes. In TLS 1.3 Editor's copy, tbs_data itself is <150 bytes (but there will be changes to merge certificate and its verify, which will presumably enlarge that a bit, but still maybe <200 bytes). I presume if TLS PoP can use HashEdDSA keys, then the TLS HashAlgorithm MUST equal HashEdDSA prehash (and with current proposed kinds, that would always be 6 => SHA-512). > Also the PureEdDSA in most implementations it requires a new API for > signing. Oh yes, the old bad PKCS#11 signature API that takes online signing model... Nevermind most of the time verification is offline (TLS is actually one of the few exceptions). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Updated EdDSA/Ed25519 PKIX document
On Thu, 2015-09-24 at 18:26 +0300, Ilari Liusvaara wrote: > On Thu, Sep 24, 2015 at 04:03:28PM +0200, Nikos Mavrogiannopoulos > wrote: > > On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote: > > > > > 4) For TLS PoP signatures, does it make sense to use HashEdDSA at > > > all? > > > Another way would to always use PureEdDSA and perform hash > > > separtion > > > from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))). > > > The certificate signatures are different matter tho, since CAs > > > use > > > HSMs for signing (those HSMs tend to be rather beefy, but still). > > > > The problem with the PureEdDSA is that if you use a smart card or > > an > > HSM (both common for TLS), you have to transfer lots of data to > > them, > > something that may render it not really useful. > > Well, hash_func_id|H(tbs_data) is 33-65 bytes for most nontrivial > hashes. > > In TLS 1.3 Editor's copy, tbs_data itself is <150 bytes (but there > will be changes to merge certificate and its verify, which will > presumably enlarge that a bit, but still maybe <200 bytes). Correct and that's not an issue for most hw out there, but I was thinking it in the sense that if we standardize a signing algorithm, it should be the same whether we sign large files or a TLS handshake. Said that, I pretty much like the properties of PureEd25519, I just think the practicalities around it are not insignificant. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
