💾 Archived View for rawtext.club › ~sloum › geminilist › 006318.gmi captured on 2024-02-05 at 11:01:09. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[tech] support for Ed25519 in clients

Stéphane Bortzmeyer stephane at sources.org

Sun Apr 11 07:27:02 BST 2021

- - - - - - - - - - - - - - - - - - -

On Thu, Apr 08, 2021 at 12:33:39AM +0200, Johann Galle <johann at qwertqwefsday.eu> wrote a message of 170 lines which said:

choosing Ed25519 as the default algorithm over ECDSA [1], I have

received multiple complaints about server operators not being able

to connect to their own servers because clients seemingly did not

support this signing algorithm.

Lupa <gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi> showsthat indeed only a small minority of capsules use Ed25519. There isprobably a chicken-and-egg probleme here, since client support, as younoticed, is poor, which does not motivate capsulemasters.

This is a serious problem for Gemini. Ed25519 in TLS was standardizedin RFC 8410 <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8410.txt>,more than two years ago. And of course, it is much older than that, soall TLS implementations should have it by now. The Web has no suchproblem.

Ed25519 has two characteristics:

not developed inside an "official" agency, which some people believea strength, since there was documented evidence of standarddevelopment organizations like NIST tampering with the security ofalgorithms, to make surveillance easier,

widely recognized among cryptographers.

So I do not really see why someone would like to use exotic TLSlibraries without Ed25519.