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
