Alok wrote:
Sorry, I don't understand your analogy with rubik's cube (most possibly because that's just not the way my brain's working... ;))I'm no expert, so please verify anything that you don't trust here.
Block algorithms typically don't operate the way a cube operates. They
are named a block algorithm because they operate on a single block in,
single block out.
ok per block, it is still "a function (on a set) = output"
A block cypher has a defined output for a defined input, so if you encode the same cleartext with the same key you'll get the same cryptotext.
This indeed makes you vulnerable to known-plaintext type of attacks if the algorithm is not implemented correctly.
One way of attack if you know (or can guess) the plaintext is the brute force attack. If you know cleartext and cyphertext of a block cypher you can always try encrypting the plaintext with every possible key, and if you get the same cyphertext you have found the key. This attack is thwarted by using large enough keysizes. A 128 bit key needs 2^128 encrypt operations, so even if you can do thousands of encryptions per second you still need a very very long time.
Another vector of attack is the dictionary attack. If you find a cyphertext you already know and you know it is encrypted with the same key you know that the cleartext is the same. Suppose you know that Alice answers Bob's question always either with "YES!!!!!" or "NEVER!!" and those answers are encoded in a single block with the same key you just have to know the one of the answers to know all. That's the reason why you usually should not operate a block cypher in the (most simple) ECB mode.
To protect against this kind of attack you have to make sure that something is unpredictably different in each cleartext block you send. This is often a cryptographic checksum of the previous block (for example in the different modes of block cyphers like CBC, CFB of OFB) or some kind of random padding. Even if no randomness is included (this is always dangerous, since it's important to use "real random numbers" which are not easily generated by the typical computer) and you know the start of a protocol handshake the only thing you can get out of the cryptotext is which block is the first in which any bit is different from your known handshake.
BTW, this is just my summary of chapter 6 in "Network Security with OpenSSL" by Viega, Messier & Chandra. I have said this before and will say it again, that purchasing that book, though not really cheap, indeed is a very sensible investment if you want to go deeper into the subject. And I do not get paid for saying that, I don't even own O'Reilly stock... ;)
Kind regards, Ted ;)
-- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26
smime.p7s
Description: S/MIME Cryptographic Signature
