Simple Encrypted Data

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.