OK, a reasonable discussion.

Rindael, on which AES is based, has many more parameters than AES. AES,
in specific, dictates keys of 128, 196, and 256 size with 10 rounds, 12
rounds, and 14 rounds respectively.

Your point about ECB (electronic code book -- single block encryption)
and CBC (cipher block chaining) is correct, but for a different reason
than you suggest. ECB encodes each 16 byte identically, while CBC uses
a progressive XOR so that subsequent identical blocks have different
encoding. ECB does not weaken the encoding, per se, but does allow a
degree of analysis based on repetitions of identical blocks.

In either line or file encoding, I don't think either is of any
significance, but since the delta cost of CBC is insignificant, well,
why not? I'll probably accept your kind suggestion and change my
encoding accordingly.

Still, the idea that either plaintext attacks or even chosen plaintext
attacks are effective against AES is not correct. A symmetric crypto system

plaintext => gook (aka cryptotext) => plaintext

with an implicit assumption that a successful decode of gook can be
readily recognized. So, if you know the gook and can recognize a
successful encoding, the code breaking process is identical to knowing
the original text and the gook. So knowing either the original or
resulting plaintext gives the exactly the same information. If it were
possible to compute the key from a finite number of { plaintext,
cryptotext } pairs, then you would have an argument. But since it is
near universally regarded that this isn't possible, you are on thinner ice.

On 11/7/2010 7:24 PM, Geoff Worboys wrote:
> Jim Starkey wrote:
>> Geoff, this is so staggeringly silly as to qualify you as a
>> prime candidate for the Firebird "Helen of the Year" award.
> Not very often you throw compliments around, Jim. Thanks.
>
>> AES, like most modern encryption algorithms, is *not*
>> vulnerable to plaintext attacks or,
>> [...]
>> And, no, a developer doesn't have to understand the crypto to
>> use it, [...]
> You speak of AES as if it is something complete in and of
> itself. You only need to look at any competent implementation
> to realise that this is not true.
>
> A symmetric encryption block cipher allows encryption of only
> a single block of data. Conceptually that process looks
> something like this:
>
> K
> |
> P-(A)-C
>
> Where C is the CipherText (encrypted text)
> P is the PlainText
> K is the Key
> and (A) is the encryption/decryption process: AES or whatever.
>
> This is deterministic to the extent that if K and P are the
> same then (A) will produce the same C (and vise-versa for
> C and K producing P).
>
> As I understand it (A) is written so that it is very difficult
> to determine K even given matching P and C pairs ... BUT this
> is only true for AES (and most others) if executed with
> sufficient "rounds" to ensure this property (ie. You still
> have to know how to implement it properly.)
>
>
> But that is not the only form of plain-text attack.
>
> Remember that a block-cipher typically encrypts only small
> blocks at a time (eg: 16 bytes). The deterministic nature of
> (A) means that every block of P that you encrypt with the same
> K will produce the same C.
>
> If you were foolish and ignorant enough to use ECB mode of
> operation (as per the example you so generously posted to this
> list, Jim) then you have just opened a major vulnerability in
> your encryption.
>
> What you are left with is like a huge jigsaw where some parts
> are known (or can be easily guessed) and some parts are not
> known but may well be inferred from adjacent known parts (and
> once inferred they add to your overall knowledge).
>
>
> 1: There are quite a large number of pages in a Firebird
> database for which we already know the content (or most of the
> page). So we start every new attack already having a large
> number of known pieces. [This is valuable input for any brute
> force attack that, but it is not the only problem.]
>
> 2: I am guessing that internal knowledge of Firebird page
> structure may very well lead to good guesses about parts
> (16-byte parts?) of many (most?) other pages. (eg: Easy
> identification of index pages from data pages etc.)
>
> 3: Plain text - of which a Firebird database contains a great
> deal - is simply not very random. Given the small blocks of
> encryption some of your database is very likely to repeat
> itself. (Especially given its multi-generational transactions
> etc.)
>
> 4: It is subject to replay-attacks because a user of the
> system could easily prime the database with inputs to aid
> later analysis.
>
> 5: If you were also foolish enough to not have any salt
> involved per database (so you end up with multiple databases
> all using the same K) then you are going to exacerbate the
> problem - and given some of Firebird's other vulnerabilities
> this could well lead to a very effective attack.
>
> 6: If you were foolish enough to implement the same effect
> on your line protocol then the repetitive nature of
> communication between the server and client is likely to
> reveal a lot about your data.
>
>
> This is, admittedly, just an amateurs analysis. I suspect that
> a specialist in the field may be able to take this further.
> But I think it's enough.
>
> If people here want to take Jim's word for it then go ahead,
> it's not a feature I intend to use anyway. But if you want to
> implement some real encryption I strongly urge you to listen
> to someone more qualified.
>



[Non-text portions of this message have been removed]