simple_encrypted_data
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
| — | simple_encrypted_data [2009/09/15 04:51] (current) – created - external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ======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 " | ||
| + | |||
| + | After each byte, the " | ||
| + | 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. | ||
| + | plaintext do not yield any additional benefit. | ||
| + | is used each time, this is an ECB cipher. | ||
| + | |||
| + | ======Examples: | ||
| + | If you ciphered the string " | ||
| + | |||
| + | 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. | ||
| + | that you're not sending your messages in plaintext which frustrates server-side | ||
| + | attempts to pattern match your conversations. | ||
| + | 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' | ||
| + | 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. | ||
| + | actually log all DCC SEND offers and send them to the government). | ||
| + | other clients support this, however. | ||
| + | |||
simple_encrypted_data.txt · Last modified: 2009/09/15 04:51 by 127.0.0.1
