💾 Archived View for gem.benscraft.info › mailing-list › messages › 188 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
- Stéphane Bortzmeyer <stephane at sources.org>
@ Sun, 11 Apr 2021 08:27 +0200
Reply to Johann Galle <johann at qwertqwefsday.eu>
────────────────────────────────────────────────────────────────────────────────
On Thu, Apr 08, 2021 at 12:33:39AM +0200,
Johann Galle <johann@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> shows
that indeed only a small minority of capsules use Ed25519. There is
probably a chicken-and-egg probleme here, since client support, as you
noticed, is poor, which does not motivate capsulemasters.
This is a serious problem for Gemini. Ed25519 in TLS was standardized
in RFC 8410 <gemini://gemini.bortzmeyer.org/rfc-mirror/rfc8410.txt>,
more than two years ago. And of course, it is much older than that, so
all TLS implementations should have it by now. The Web has no such
problem.
Ed25519 has two characteristics:
a strength, since there was documented evidence of standard
development organizations like NIST tampering with the security of
algorithms, to make surveillance easier,
So I do not really see why someone would like to use exotic TLS
libraries without Ed25519.
════════════════════════════════════════════════════════════════════════════════