Skip to content

Latest commit

 

History

History
170 lines (113 loc) · 6.15 KB

ircrypt-protocol.md

File metadata and controls

170 lines (113 loc) · 6.15 KB
Raw

Part 1: General protocol information

IRCrypt only affects private messages and notices as defined by section 4.4 of [rfc1459]. All other messages shall be passed unchanged by plug-ins implementing IRCrypt. Furthermore, only the <text> part of these messages may be modified.

IRCrypt Message Template

An IRCrypt message has the following form.

<PREFIX>-<PART-ID> <CRYPT-MSG>

Notice that the <text> part of a message has not to start with the IRCrypt message, so that IRCrypt can also handle e.g. timestamps in front of an IRCrypt message.

<PREFIX>

Every IRCrypt message starts with a <prefix>. If a message is too long and has to be cut in separate parts (see <PART-ID>), every part starts with <prefix>.

Based on this <prefix> IRCrypt knows how to handle the message, so different IRCrypt functions like symmetric encryption or key exchange have different prefixes. The prefix for errors is UCRY. All other prefixes are described below in their own chapter.

<PART-ID>

<PART-ID> identifies the part of the message. This is intended for multipart messages and is a continuous descending integer value with a value of 0 indicating the last part of a message.

It is possible, that an already long message grows even to large to be sent at once via IRC after encryption, as one message may not exceed 512 characters (including IRC protocol command identifier, trailing \CR\LF, etc.) as specified in [rfc1459, 2.3]. In such case it is necessary to split the encrypted messages in multiple parts, sending them as separate IRCrypt messages (see IRCrypt Message Template). Given that the message has to be split in N parts the <PART-ID> of the first part to send is N, the second is N-1, … until the last part, is sent with <PART-ID> set to 0.

The descending order of the <PART-ID> ensures that:

  • The client knows how many parts will be send, making it possible to effectively allocate memory or, if the number of parts is to high for the client to handle, to refuse the messages.

  • The client can indicate and may throw away “old” message parts which were never completely transmitted, i.e. due to a failing connection. If, for example, a client receives messages preceded by “<PREFIX>-2” and “<PREFIX>-1” but the next message is again preceded by “<PREFIX>-2”, the client may throw away the old message parts and try decoding the current message only.

<CRYPT-MSG>

<CRYPT-MSG> is a message encrypted according to the OpenPGP standard [rfc4880], Base64 encoded and cut into multiple parts (see <PART-ID>) if necessary.

TIMEOUT

As using <PART-ID> values greater than 0 should make a client keep these message parts in memory while waiting for subsequent parts, this could be used as a possible attack on clients: Sending such parts would cause a client to constantly allocate new memory. However, subsequent message parts should be send one after another over a short period of time. Thus is is not only valid but recommended to discard old message parts after some time, if no subsequent parts are being received.

Given the nature of IRC as an instant chat protocol, consecutive messages should not be delayed over a long time and it should be reasonable to assume a message to time out after five minutes.

Part 2: Symmetric Cipher

<PREFIX>

The prefix of a symmetric encrypted messages is >CRY.

<CRYPT-MSG>

The used cipher may be everything allowed by OpenPGP, nevertheless, it is strongly suggested to use modern and secure ciphers like AES256 or TWOFISH. It would be also nice, if the user can choose the used cipher himself.

Using GPG and the Unix base64 tool such a message e.g. can be generated by using the following command

echo 'Message' | gpg --symmetric --cipher-algo TWOFISH | base64 -w 0

and decrypted by using

echo 'Encrypted Message' | base64 -d | gpg -d

Errors

Not every implementation of the OpenPGP standard includes the same symmetric ciphers and the list of ciphers that has to be working to fulfill the OpenPGP standard is very limited (see [rfc4880 8.2]). If an symmetric encrypted IRCrypt message with an unknown cipher is received, the error

>UCRY-CIPHER-NOT-FOUND

should to be sent back as a notice.

Example message

The following line contains a valid IRC Message from Angel to Wiz. It is encrypted using the TWOFISH cipher with 256bits key size and “secret” as passphrase. The decrypted content of this message is “Hello are you receiving this message ?”:

:Angel PRIVMSG Wiz :>CRY-0 jA0ECgMCpf88FdB5AdFg0lwB03DpHgpQAqoGSR2QTIynudCXM178TN2Y06ahv+I1i/mLwDMt+s021cb14YdVWJXUVqBKTbpQ3B3aIthsxsb0qrQoUTdZTKHjGYXeYPCFoRaetkOiEPUcAWK9RA==

Assuming that this message would be to long, the following two IRC messages should produce the same output in Wizs IRC client:

:Angel PRIVMSG Wiz :>CRY-1 jA0ECgMCpf88FdB5AdFg0lwB03DpHgpQAqoGSR2QTIynudCXM178TN2Y06ahv+I1i/mLwDMt+s02
:Angel PRIVMSG Wiz :>CRY-0 1cb14YdVWJXUVqBKTbpQ3B3aIthsxsb0qrQoUTdZTKHjGYXeYPCFoRaetkOiEPUcAWK9RA==

Part 3: Asymmetric Cipher

Basic Version

In the lite version encryption with asymmetric cipher shall not be implemented, but if an asymmetric encrypted message is received, IRCrypt has to send back the error

>UCRY-NOASYM

Most of the asymmetric encrypted messages are received in different parts (see <PART-ID>), but the error should only be sent once and not one error per part. The prefix of an asymmetric encrypted messages is >ACRY.

PART 4: Key Exchange

Basic Version

In the lite version a key exchange shall not be implemented, but if an key exchange request is received, IRCrypt has to send back the error

>UCRY-NOEXCHANGE

Most of the asymmetric encrypted messages are received in different parts (see <PART-ID>), but the error should only be sent once and not one error per part. Key exchanges are received by notices defined in [rfc1459 4.4.2]. The prefix of a key exchange request message is >WCRY.

References