If you care how it works, pay attention to the Background slidesBuy me a beer and ask for more detailsMore understanding makes these attacks more effective
Ciphertext generated using a sound algorithm shows signs of randomnessEnt is a nice tool for testing randomness of datahttp://fourmilab.ch/randomRandom bytes play hell with lots of protocolsUsual suspects:Base64URL-safe Base64ASCII hexURL encodingDecoded length is often a multiple of 8/16/32 bytesAuthenticated crypto generally adds another 4 bytes
Developers reuse cryptovariablesKeyIVCipherDevelopers usually reuse cryptovariables and trust that the data they have decrypted using their application is sane, due to the poor assumption that no one can generate or alter the encrypted data without the key.No input validationNo error handling
Similar to fuzzing for XSSBit flipping should produce garbled dataWith authenticated crypto, swapping ciphertext might work
Similar to fuzzing for XSS
Stream ciphersProduce pseudo-random bytes (keystream) using key & IVEncryption/Decryption: XOR with keystreamIV reuse was the downfall of WEP
Here is a multi-byte XOR operation. We assume this to be a part of a stream cipher. The middle row is the keystream, which is XORed with the ciphertext to decrypt the message.
We do not know the keystream, but we know that flipping the bits of the ciphertext results in corresponding bits of the plaintext being flipped.
Other messages’ blocks can be used tooRequires key reuse