[tor-bugs] #20205 [Applications/Tor Messenger]: Implement SASL EXTERNAL

[Tor Bug Tracker & Wiki]

#20205: Implement SASL EXTERNAL
----------------------------------------+-------------------------
 Reporter:  arlolra                     |          Owner:  arlolra
     Type:  defect                      |         Status:  new
 Priority:  Medium                      |      Milestone:
Component:  Applications/Tor Messenger  |        Version:
 Severity:  Normal                      |     Resolution:
 Keywords:                              |  Actual Points:
Parent ID:                              |         Points:
 Reviewer:                              |        Sponsor:
----------------------------------------+-------------------------

Comment (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 https://www.ietf.org/rfc/rfc5480.txt 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);
     console.log(btoa(s));
   });
   }}}
   (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 https://github.com/Brightspace
 /node-ecdsa-sig-formatter is useful, once you change the `Buffer` calls to
 use `Uint8Array` APIs.

 * The biggest issue is the ECDSA algorithm itself. As defined,
   https://www.w3.org/TR/WebCryptoAPI/#ecdsa-operations
   it necessitates using a hash function before signing, which matches,
 https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm
   However, the challenge in the protocol is already the bit length of the
 group order (256) and wants that signed w/o hashing.
   The tool above just calls `ECDSA_sign` directly,
   https://github.com/kaniini/ecdsatool/blob/master/libecdsaauth/op.c#L64
   which seems like a showstopper.

 Switching to https://github.com/indutny/elliptic, producing a patch that
 worked was a lot simpler,
 https://github.com/TheTorProject/tor-messenger-
 build/commit/5cbff442d43f47672faa23f6c0247ae62f3bfb3c
 but adds this ~10k LOC library, which is obviously not ideal.

 Here's a build w/ the above patch applied,
 https://paganini.erinn.org/~arlolra/tor-messenger/tor-messenger-0.2.0b2
 -osx-x86_64-6f7049.dmg

 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20205#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online