> >> > > > >ok per block, it is still "a function (on a set) = output" > > > > > Sorry, I don't understand your analogy with rubik's cube (most possibly > because that's just not the way my brain's working... ;))
:o) > > 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. > yes. I guess so. > 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. > not thinking of anything as smart as brute force > 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. alright. > 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... ;) > will do, thanks! > Kind regards, > Ted > ;) > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
