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