Add ecdsa-nist256p-challenge into sasl. [$10] #414

New Issue

2026-10-05T04:19:18+02:00

adam commented

2026-10-05 04:19:18 +02:00

Since dh-blowfish and dh-aes have been killed off, might as well add support for ecdsa-nist256p-challenge.

https://github.com/atheme/ecdsatool

https://github.com/atheme/atheme/blob/master/modules/saslserv/ecdsa-nist256p-challenge.c

Did you help close this issue? Go claim the $10 bounty on Bountysource.

Since `dh-blowfish` and `dh-aes` have been killed off, might as well add support for `ecdsa-nist256p-challenge`. https://github.com/atheme/ecdsatool https://github.com/atheme/atheme/blob/master/modules/saslserv/ecdsa-nist256p-challenge.c ## <bountysource-plugin> Did you help close this issue? Go claim the **[$10 bounty](https://www.bountysource.com/issues/5926443-add-ecdsa-nist256p-challenge-into-sasl?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam closed this issue

2026-10-05 04:19:18 +02:00

adam commented

2026-10-05 04:19:19 +02:00

Also going to affect at freenode.

The SASL mechanism DH-BLOWFISH has been removed. People using it
can connect via SSL and use PLAIN or upgrade to ECDSA-NIST256P-CHALLENGE.
Details of how to do so are here and our SASL page will be updated with the relevant documentation soonish.

Via https://blog.freenode.net/2014/11/atheme-7-2-and-freenode/

Also going to affect at freenode. > The SASL mechanism DH-BLOWFISH has been removed. People using it > can connect via SSL and use PLAIN or upgrade to ECDSA-NIST256P-CHALLENGE. > Details of how to do so are [here](https://github.com/atheme/ecdsatool) and [our SASL page](https://freenode.net/sasl/) will be updated with the relevant documentation soonish. Via https://blog.freenode.net/2014/11/atheme-7-2-and-freenode/

adam commented

2026-10-05 04:19:20 +02:00

I am not sure how this is going to work when implemented. If I understand this correctly, ~~username and~~ password ~~aren't~~ isn't used, but separate keypair.

Will users install ecdsatool and generate the key and upload to ZNC like with certfp or will ZNC do the generating and just tell users to add it to services?

And as this looks like certfp, could there be option to load SASL as user module? It would made sense if the user only used ecdsa-nist256p-challenge and EXTERNAL as they don't seem to be so network specific as passwords are. UPDATE: username is required and that can be considered as network-specific.

I am not sure how this is going to work when implemented. If I understand this correctly, ~~username and~~ password ~~aren't~~ isn't used, but separate keypair. Will users install ecdsatool and generate the key and upload to ZNC like with certfp or will ZNC do the generating and just tell users to add it to services? And as this looks like certfp, could there be option to load SASL as user module? It would made sense if the user only used ecdsa-nist256p-challenge and EXTERNAL as they don't seem to be so network specific as passwords are. **UPDATE: username is required and that can be considered as network-specific.**

adam commented

2026-10-05 04:19:20 +02:00

Oh and another thing that I am not understanding, but this is probably wrong place for it, is the way to add fingerprint, /ns set property pubkey <key>. Isn't this publicly visible to everyone unlike SSL certificate fingerprint which is hidden by most of IRCds in whois.

I am seeing the same issues with both, someone else can see your fingerprint and add it to another account on network where you aren't yet or haven't added the fingerprint and then have script auto-ghost you or something. I am also unsure on what do services do when multiple people add the same pubkey as property.

2014-11-21 15:09:57+0200 < Aaron> ecdsatool is for SASL authentication which takes an account name.

~~Oh and another thing that I am not understanding, but this is probably wrong place for it, is the way to add fingerprint, `/ns set property pubkey <key>`. Isn't this publicly visible to everyone unlike SSL certificate fingerprint which is hidden by most of IRCds in whois.~~ ~~I am seeing the same issues with both, someone else can see your fingerprint and add it to another account on network where you aren't yet or haven't added the fingerprint and then have script auto-ghost you or something. I am also unsure on what do services do when multiple people add the same pubkey as property.~~ > `2014-11-21 15:09:57+0200 < Aaron> ecdsatool is for SASL authentication which takes an account name.`

adam commented

2026-10-05 04:19:21 +02:00

Oh and another thing that I am not understanding, but this is probably wrong place for it, is the way to add fingerprint, /ns set property pubkey . Isn't this publicly visible to everyone unlike SSL certificate fingerprint which is hidden by most of IRCds in whois.

Even though ECDSA-NIST256P-CHALLENGE takes an account name, this can be solved by moving the pubkey variable into a private: metadata namespace: zohlai/zohlai@33f635c717 (I plan on changing this so a user can use multiple public keys like for CertFP/EXTERNAL)

> Oh and another thing that I am not understanding, but this is probably wrong place for it, is the way to add fingerprint, /ns set property pubkey <key>. Isn't this publicly visible to everyone unlike SSL certificate fingerprint which is hidden by most of IRCds in whois. Even though ECDSA-NIST256P-CHALLENGE takes an account name, this can be solved by moving the pubkey variable into a `private:` metadata namespace: zohlai/zohlai@33f635c7170c5dfbf8865398e4aeb19c8b2cc11c (I plan on changing this so a user can use multiple public keys like for CertFP/EXTERNAL)

adam commented

2026-10-05 04:19:22 +02:00

Today freenode upgraded their Atheme so only PLAIN and ECDSA-NIST256P-CHALLENGE are supported there.

People probably noticed it already, but I thought I would add comment about it as https://github.com/weechat/weechat/issues/251#issuecomment-66883287 was added too.

Today freenode upgraded their Atheme so only PLAIN and ECDSA-NIST256P-CHALLENGE are supported there. _People probably noticed it already, but I thought I would add comment about it as https://github.com/weechat/weechat/issues/251#issuecomment-66883287 was added too._

adam commented

2026-10-05 04:19:22 +02:00

related discussion: https://github.com/atheme/atheme/issues/419
article on DH-BLOWFISH: https://nullroute.eu.org/~grawity/irc-sasl-dh.html

related discussion: https://github.com/atheme/atheme/issues/419 article on DH-BLOWFISH: https://nullroute.eu.org/~grawity/irc-sasl-dh.html

adam commented

2026-10-05 04:19:23 +02:00

WeeChat git version got support for it last night https://github.com/weechat/weechat/commit/e2be01833f2593b90c4059f712a9a2e2cf01ea43 (quick instructions: https://github.com/weechat/weechat/issues/251#issuecomment-70576923) and Limnoria merged the support to stable version some time ago.

WeeChat git version got support for it last night https://github.com/weechat/weechat/commit/e2be01833f2593b90c4059f712a9a2e2cf01ea43 (quick instructions: https://github.com/weechat/weechat/issues/251#issuecomment-70576923) and Limnoria merged the support to stable version some time ago.

adam commented

2026-10-05 04:19:24 +02:00

I think it was decided that this isn't going to happen because of the log quoted below, but I am unable to find source for it at GitHub.

[11:28:05] <kaniini> but ECDSA-CHALLENGE is probably dead anyway
[11:28:20] <kaniini> because in mammon we're going to implement a version which does not use NIST curves
[11:28:37] <kaniini> because they appear to be malleable: http://safecurves.cr.yp.to/rigid.html
[11:31:43] <SaberUK> nist standardising things which are dodgy? colour me surprised! ;)
[11:36:23] <kaniini> i doubt they knew
[11:42:25] <sheep> is it going to use Curve25519/Ed25519?
[11:43:04] <kaniini> probably

From #ircv3 on 2015-04-04.

I think it was decided that this isn't going to happen because of the log quoted below, but I am unable to find source for it at GitHub. ``` [11:28:05] <kaniini> but ECDSA-CHALLENGE is probably dead anyway [11:28:20] <kaniini> because in mammon we're going to implement a version which does not use NIST curves [11:28:37] <kaniini> because they appear to be malleable: http://safecurves.cr.yp.to/rigid.html [11:31:43] <SaberUK> nist standardising things which are dodgy? colour me surprised! ;) [11:36:23] <kaniini> i doubt they knew [11:42:25] <sheep> is it going to use Curve25519/Ed25519? [11:43:04] <kaniini> probably ``` From #ircv3 on 2015-04-04.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#414