Hi all,
I'm a long-time user of Mircryption since my early days in IRC.
I think since "Operation Boxenstopp" in 2006, which made everyone panick.

I was expieriencing some difficulties using glftpd's sitebot pzs-ng, lately:
In the most recent versions, it:
- refuses to talk to me,
- refuses to invite me.
After a key-exchange has been triggered by me or the sitebot itself.
I've reported it, but I don't think it will ever be fixed, because most people seem to use Fish_10 now.
Bug-Ticket:
https://github.com/g...tpd/pzs-ng/issues/47Details:On my journey of trying to debug this, I have uncovered some incompatibilities between pzs-ng's, weechat's, fish_10's and Mircryption's key-exchange mechanism and fallbacks to ECB.
In short, from my memory, from one month ago:
-
DH1080_INIT <pubKey> and
DH1080_FINISH <encryptedSecret> work with all versions to exchange a key and use it for
ECB mode BlowFish encryption.
- Mircryption uses
DH1080_INIT_cbc <pubKey> and
DH1080_FINISH_cbc <encryptedSecret> to exchange keys with the intention to use it for
CBC encrypted chats. I'd call this syntax Mircryption's syntax or command suffix syntax.
- Fish_10 and PZS-NG seem to use
DH1080_INIT <pubKey> CBC and
DH1080_FINISH <encryptedSecret> CBC to exchange keys with the intention to use it for
CBC encrypted chats. I'd call this syntax Fish syntax or key suffix syntax.
- Some implementations (Weechat?) seem to exchange without any CBC suffix, but just enable sending in CBC mode by default and decode anything that arrives with a * as first character in CBC mode and anything else in ECB mode. So they switch without further noticing the user about using less secure ECB...
What happens now when Fish_10 or PZS-NG initiate a key-exchange with Mircryption in CBC mode?
- partner sends
DH1080_INIT <pubKey> CBC- Mircryption ignores the CBC key suffix, treats this as an ECB exchange and answers with a ECB finish:
DH1080_FINISH <encryptedSecret>- Fish_10 falls back to ECB mode, PZS-NG is not being triggered by the answer, waits endlessly, blocks pms and invites...
If Mircryption triggers the exchange:
- Mircryption sends
DH1080_INIT_cbc <pubKey>- partner ignores the request at all (PZS-NG) OR ignores the command suffix (Fish_10), misinterprets it as ECB exchange and answers with ECB finish:
DH1080_FINISH <encryptedSecret>I've also found out: when I "patch" this, so mircryption can also initiate a key-exchange in Fish-syntax or respond to Fish-syntax with Fish-syntax, PZS-NG seems to exchange in CBC mode, but just sends in ECB mode anyways...
Mircryption will just show "ERROR_NONCBC: <garbage>", while FIsh_10 just detects the non-cbc messages by the missing * and decrypts it in ECB mode without further notice...
Solution and Questions:1. I have "patched" this, so it can do key-exchanges in fish syntax: initiate them AND respond to them "properly". However, I'm not fully sure if this is the "right" way to handle this, because I cannot find a standard specifying it... Do you want me to make it "presentable" (remove the debug outputs) and provide it to you?
2. Do you think it is the right way/solution?
3. I'm mostly a C-coder, my MSL-skills are pretty rusty and I could really benefit from a code review! Is anyone volunteering for a review?
4. Is Mouser still alive? Does he maybe want to integrate this into his package?
5. How do you think Mircryption should handle a partner sending in ECB mode, when CBC has been exchanged, or vice versa?
- just show a error message and garbage, as now? (security solution)
- automatically decrypt in correct mode? (so auto switch to ECB/CBC decryption depending on encrypted input string: * prefix and possible = suffices) (compatibility solution)
- show an error message for wrong mode AND decrypt in mode indicated by prefix? (mix of compatibility and security)
- use specific styling to differentiate between ECB, CBC and plain text messages?
- should it also switch its configured sending mode, when other mode messages arrive? (risky mode: enforced fallback to ECB possible)