Table of Contents
Simple Encrypted Data
The client always offers a basic obfuscating encryption cipher called SED (Simple Encrypted Data).
SED is an unbuffered ECB cipher that uses a variable length key.
Each byte in the input string is XORed with each corresponding byte in the cipherkey and XORed with a “mix” value, whose initial value is 0.
After each byte, the “mix” value is XORed with the initial value of the byte. Thus, the mix value at each position is the XOR of every plaintext byte previously analyzed.
When the end of the cipherkey is reached, it goes back to the beginning. Thus, longer passkeys yield better results. Passkeys longer than the plaintext do not yield any additional benefit. Because the same passkey is used each time, this is an ECB cipher.
Examples:
If you ciphered the string “testing” with the passkey “hello”:
Byte 1: MIX = 0x00, BYTE = 0x74, KEY = 0x0x68,
NEW BYTE == MIX ^ BYTE ^ KEY = 0x1C
NEW MIX == MIX ^ BYTE = 0x74
Byte 2: MIX = 0x74, BYTE = 0x65, KEY = 0x65,
NEW BYTE == MIX ^ BYTE ^ KEY = 0x74 NEW MIX == MIX ^ BYTE = 0x11
(…and so on)
Weaknesses:
SED is not a serious encryption scheme. But it does obfuscate your data enough that you're not sending your messages in plaintext which frustrates server-side attempts to pattern match your conversations. You should assume anyone who is interested in you could decrypt your messages, but since it's presumed most server-side surveilance is done by pattern matching plaintext, having a simple universal means to obfuscate your messages makes it not worth someone's bother to decrypt your messages just to pattern match them.
Because the client does recursive CTCP handling, if you are using encryption with someone and you DCC SEND them a file, the CTCP DCC SEND offer will be encrypted, which is extremely helpful for thwarting server-side attempts to log all file transfers on the network. (Yes, there have been networks that actually log all DCC SEND offers and send them to the government). Not all other clients support this, however.