Cryptography Reference
In-Depth Information
This is the reason why fcrypt writes the 256-byte plaintext blocks in a 16
16
matrix such that each row contains the elements of one group. (The order of the
plaintext bytes written in the matrix is secret!) Once the encryption 'by rows' is
complete, we analogously encrypt 'by columns'. This approach introduces yet
another considerable improvement to the method's statistical properties, and
makes it a bit more secure.
×
Attacking fcrypt
What happens with the improved fcrypt if two plaintexts differ in one byte
only? You may come to think that the ciphertexts (again created with the same
key) differ in all bytes, except for the bytes in positions within the matrix (in
columns or rows) that coincide with the position of the changed byte. Let's
look at an example: two plaintexts differ in the byte written in row 7, column 4.
Writing '.' for changed bytes and '0' for unchanged bytes in the ciphertext, the
ciphertext block (written as a matrix) we create would basically look like this:
...0............
...0............
...0............
...0............
...0............
...0............
0000000000000000
...0............
...0............
...0............
...0............
...0............
...0............
...0............
...0............
...0............
Don't forget, the ciphertext doesn't appear in rows in this matrix, since the
way the characters are written in the matrix (and read from it) is secret. The
only thing we can see is that 31 positions somewhere strewn across the text
haven't changed, and we know that they've got to be in the same row or in
the same column that the changed byte is in.
An attacker initially won't be able to do much with these 31 numbers. What I
(incomprehensibly!) hadn't thought of back then was the following:
Search WWH ::




Custom Search