Crypt module: "+OK *" and "+OK" compatibility #836

New Issue

2026-10-05T04:47:35+02:00

adam commented

2026-10-05 04:47:35 +02:00

Hi, I tested the blowfish / DH_1080 implementation of crypt and it looks like there's a compatibility problem (at least from what I can tell).

This is probaby a question for @Cizzle who did the implementation to justify if it's a bug / lack of standardization etc...

I'm not a developer, but from the code I've checked other implementations does not seem to have the * char before the crypted message which seem to make crypt DH_1080 uncompatible with the other implementations out there which I can find source for, below are a two examples:

Fish module linked from znc.in https://gist.github.com/v4lli/ee4edd99128e7cb518ebad548cab7a41

/msg *fish setkey testuser2 testing
<*fish> Set encryption key for [testuser2] to [testing]
<testuser2> *ANzZ9z9bt2ohbcrrsAdW1w==

/msg *crypt setkey testuser testing
<*crypt> Set encryption key for [testuser] to [testing]
<testuser> +OK l/Msh.OInW41

+OK used for all but topic change where +OK * is used: https://github.com/sysadm1ns/mceggdrop/blob/master/tcleggdrop_mcpsfuncs.tcl#L321-L328
+OK used for PRIVMSG, NOTICE and TOPIC: https://github.com/flakes/mirc_fish_10/blob/73208781808b44f7accfd9c233579f89356c72d8/fish_10/src/fish-main.cpp#L78-L91

My interpretation is that crypt sees +OK as raw text since it doesn't match +OK *
Running ZNC v1.7.0 (https://hub.docker.com/_/znc/)

Hi, I tested the blowfish / DH_1080 implementation of crypt and it looks like there's a compatibility problem (at least from what I can tell). This is probaby a question for @Cizzle who did the implementation to justify if it's a bug / lack of standardization etc... I'm not a developer, but from the code I've checked other implementations does not seem to have the `*` char before the crypted message which seem to make crypt DH_1080 uncompatible with the other implementations out there which I can find source for, below are a two examples: - Fish module linked from znc.in https://gist.github.com/v4lli/ee4edd99128e7cb518ebad548cab7a41 ``` /msg *fish setkey testuser2 testing <*fish> Set encryption key for [testuser2] to [testing] <testuser2> *ANzZ9z9bt2ohbcrrsAdW1w== ``` ``` /msg *crypt setkey testuser testing <*crypt> Set encryption key for [testuser] to [testing] <testuser> +OK l/Msh.OInW41 ``` - `+OK` used for all but topic change where `+OK *` is used: https://github.com/sysadm1ns/mceggdrop/blob/master/tcleggdrop_mcpsfuncs.tcl#L321-L328 - `+OK` used for PRIVMSG, NOTICE and TOPIC: https://github.com/flakes/mirc_fish_10/blob/73208781808b44f7accfd9c233579f89356c72d8/fish_10/src/fish-main.cpp#L78-L91 My interpretation is that crypt sees `+OK` as raw text since it doesn't match `+OK *` Running ZNC v1.7.0 (https://hub.docker.com/_/znc/)

adam closed this issue

2026-10-05 04:47:35 +02:00

adam commented

2026-10-05 04:47:36 +02:00

Just ran into the same issue, fish users can read my encrypted messages, but i cannot read those of them.

Just ran into the same issue, fish users can read my encrypted messages, but i cannot read those of them.

adam commented

2026-10-05 04:47:36 +02:00

There are two modes currently in use for the blowfish crypt: ECB and CBC.
ECB mode uses the "+OK " prefix and is deprecated due to its insecurity (every textblock is always encrypted the same).
CBC mode uses the "+OK *" prefix and is the preferred mode.

Not all IRC clients/bots support both modes, many have different methods of passing this info on during the DH1080_INIT or don't pass this along and use a certain mode as default.

To answer the question: this is not a bug and can be attributed to a lack of standards and lazyness of users and devs to switch from ECB to CBC mode.

There are two modes currently in use for the blowfish crypt: ECB and CBC. ECB mode uses the "+OK " prefix and is deprecated due to its insecurity (every textblock is always encrypted the same). CBC mode uses the "+OK *" prefix and is the preferred mode. Not all IRC clients/bots support both modes, many have different methods of passing this info on during the DH1080_INIT or don't pass this along and use a certain mode as default. To answer the question: this is not a bug and can be attributed to a lack of standards and lazyness of users and devs to switch from ECB to CBC mode.

adam commented

2026-10-05 04:47:37 +02:00

Thank you for clarification!

Thank you for clarification!

adam commented

2026-10-05 04:47:38 +02:00

Looks like this can be closed.

Looks like this can be closed.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#836