Re: 256-bit Camellia vs 256-bit AES - Which is better?

[Terra Frost <terrafrost@gmail.com>]

On Fri, Feb 13, 2009 at 10:19 PM, Chip Panarchy <forumanarchy@gmail.com> wrote:
> Hi
>
> Recently found a website, (using Firefox 3, love there blue favicon
> idea, always click it), that was using Camelia 256-bit, instead of
> what I usually see (RC4 128 bit or AES 256-bit).

Which website, out of curiosity?

> Can rainbow tables be generated for both ciphers? If so, how much
> hard-drive space would I need to store them? And what program should I
> use to generate these rainbow tables? (eg Winrtgen, etc.)

Rainbow tables are intended for hash functions - not for encryption
algorithms.  With a hash function the only things you need to keep
track of are the plaintext and the hash.  The plaintext will always
produce the same hash, no matter what.  The plaintext might be salted,
but all salting really does is turn one plaintext into another longer
plaintext.  So instead of 'test' you have 'abtest' because you
prepended 'ab' to 'test'.

For encryption algorithms, it's different.  You don't just keep track
of the plaintext - you keep track of the key.  I guess you could have
a table with every possible plaintext block, every possible key, and
the plaintext that it corresponds to, but that'd be huge.  For a 128
bit key, that'd take 16 ** 16 bytes or 16.7 million terabytes.  And
whereas rainbow tables often include only the most common characters
(a-zA-Z0-9, whatever), a table like this for AES couldn't make any
omissions.  Thanks to the CBC mode of encryption, even if you were
just encrypting the letter a repeated 160 times (10 blocks), only the
first block would be encrypting the letter a.  All subsequent blocks
would be encrypting the letter a XOR'd against the previous block's
ciphertext.

Now, I suppose you could just attack the first block and ignore all
other blocks until you've found a key that produces a realistic
looking plaintext block, but even then, you're still likely to have a
huge table.

Long story short, rainbow tables are really best suited for hashes -
not encryption algorithms.