Atheme IRC services used to implement a custom SASL mechanism DH-BLOWFISH. (Version 7.1 also implemented a similar DH-AES.) Here I try to answer some common questions and misconceptions about these mechanisms.
I originally wrote this when a serious performance bug caused freenode to temporarily turn off DH-BLOWFISH for a few weeks, causing a flood of user complaints. After freenode upgraded to Atheme 7.2 (which completely removed DH-BLOWFISH and DH-AES support), the page is relevant again.
There seem to be many misconceptions about the security of these mechanisms – some users, when asked to reconfigure their clients, try to argue that DH-BLOWFISH has provided more security than PLAIN-over-TLS or PLAIN-over-Tor; others are just curious about the removal.
Both mechanisms are relatively simple – they send an encrypted password to services, with DH key exchange used to agree on the shared key. So they do provide security against simple kinds of passive monitoring (e.g. your neighbour kid trying out Wireshark).
However, DH alone does not authenticate either party, so it is vulnerable to MITM attacks; this alone means that it cannot be more secure than TLS, only less – assuming the client verifies the server's certificate, or if the client connects to a Tor hidden service which are verified by its .onion name. (With no verification, all three are equally poor.)
Another common misconception is that with DH-BLOWFISH, services never receive the plaintext password. This is false as well – as already mentioned, both DH-BLOWFISH and DH-AES send an encrypted password, not hashed; services will decrypt it when received.
Also, DH-BLOWFISH encrypts only the password during authentication, and nothing more. If you have to manually log in again or change your password using "
/msg NickServ …" commands, that will be sent in plain text. This is yet another disadvantage over TLS or Tor hidden services, both of which encrypt every single byte sent over the connection.
(Edit: The comment on DH parameter size was based on my flawed understanding about DH key generation and therefore removed. – 2014-12-16)
Use SASL PLAIN, over a secure TLS connection. (For KVIrc that means using a SVN build, since 4.2 only supports DH-BLOWFISH.)
If the network supports it, use SASL EXTERNAL with TLS client certificates. (Unfortunately, freenode's CertFP is not integrated with SASL yet.)
If you use Irssi, try cap_sasl.pl 1.9 with SSH-like public-key authentication support (SASL ECDSA-NIST256P-CHALLENGE); use
/sasl keygen to set it up.