Opened 10 months ago

Last modified 4 months ago

#20205 new defect


Reported by: arlolra Owned by: arlolra
Priority: Medium Milestone:
Component: Applications/Tor Messenger Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


So we can connect to freenode's onion.

Child Tickets

Change History (9)

comment:1 follow-up: Changed 10 months ago by dcf

I was just looking for this feature :)

I don't know if it's the same thing, but says

SASL authentication is now supported, this is required for certain IP ranges or when using Tor and connecting to Freenode.

comment:2 Changed 10 months ago by arlolra


pass­word-based SASL au­then­ti­ca­tion is dis­abled over the Tor gate­way

That's the one IB does support :(

Now they're saying,

You must log in us­ing SASL's EXTERNAL or ECDSA-NIST256P-CHALLENGE (more be­low)

Shouldn't be too bad to implement that though. All the code is contained in,

comment:3 Changed 10 months ago by yawning

Is there support for using a TLS client cert already? If so EXTERNAL looks a lot easier...

comment:4 Changed 10 months ago by arlolra

Three reasons why the Webcrypto API was perhaps not the best choice to quickly push ahead on ECDSA-NIST256P-CHALLENGE,

  • Raw export of the public key is uncompressed. See "2.2. Subject Public Key" in where it says,

    The uncompressed form is indicated by 0x04 ...

    which means you need to do something like the following to get the string to set with nickserv,
    crypto.subtle.exportKey("raw", kp.publicKey).then(function(ab) {
      // the first byte of ab indicates the form
      let v = new Uint8Array(ab);
      let u = v.slice(0, 33);  // +1 here for the compressed point
      u[0] = 2 + (v[v.length - 1] & 1);
      let s = String.fromCharCode.apply(null, u);
    (note, to retrieve the uncompressed point from a PEM, openssl ec -noout -text -conv_form uncompressed -in test.pem)
  • The returned signature from crypto.subtle.sign is a byte array of concatenated r,s values, but the protocol wants a base64 encoding of the DER formatted signature. A library like is useful, once you change the Buffer calls to use Uint8Array APIs.

Switching to, producing a patch that worked was a lot simpler,
but adds this ~10k LOC library, which is obviously not ideal.

Here's a build w/ the above patch applied,

To use it, take the tool linked to above and follow its readme. Then, do ecdsatool keyinfo test.pem and copy the priv hex pairs but remove the newlines and colons. Add the preference messenger.account.accountN.ecdsa in the Tor Messenger config editor, and connect.

comment:5 Changed 10 months ago by arlolra

Submitted the patch for discussion upstream as,

comment:6 Changed 9 months ago by arlolra

The patch was merged in

Let's consider that an experimental feature for now. I've been using it successfully for a few weeks.

As Yawning mentioned though, we probably still want to support SASL EXTERNAL as well.

comment:7 in reply to: ↑ 1 Changed 8 months ago by arlolra

Replying to dcf:

I was just looking for this feature :)

SASL ECDSA-NIST256P-CHALLENGE went out in TM v0.3.0b1 as a quasi- undocumented feature.

Here're some notes on how to use it,

comment:8 Changed 4 months ago by windmiller

There's a bug in the JavaScript in the wiki notes that drops the leading zero from any 0x0n byte when hex-encoding the private key. This explains the mystery of the broken keypairs raised on IRC.

comment:9 Changed 4 months ago by arlolra

Aha! Thanks for digging in. I made this change,

<   let padStart = (s, l, c) => Array(l - s.length + 1).join(c || " ") + s;
<     let h = a.reduce((prev, next) => prev + padStart(next.toString(16), 2, "0"), "");
>     let h = a.reduce((prev, next) => prev + next.toString(16), "");
Note: See TracTickets for help on using tickets.