[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.2.0 (work5) now available
- From: Rob Kendrick <rjek@...>
- Date: Sat, 6 Nov 2010 12:17:26 +0000
On Sat, Nov 06, 2010 at 01:29:43PM +1000, pj@pjb.com.au wrote:
> Joseph Stewart wrote:
> > but what can't you do with 32-bit values that you need to do?
>
> I wrote:
> > Strong encryption ?
> > In block cyphers, you need lots of XOR ops, and block sizes of
> > 32 bits are inherently vulnerable but 64 bits are very tough...
>
> Rob Kendrick wrote:
> > It's difficult to see how simply doubling the number of bits
> > you process at once removes an inherent vulnerability.
>
> See: http://en.citizendium.org/wiki/Code_book_attack
>
> DES and the generation of ciphers that followed it all used a 64-bit
> block size. To completely break a single key, an attacker would need
> a code book with 2^64 entries. Even to weaken it significantly takes
> a code book with 2^32 entries with the same key, 32 gigabytes of data.
> With any sensible re-keying policy, a code book attack is not a threat.
> More recent ciphers such as AES use a 128-bit block size,
> which makes code book attacks utterly impractical.
Then how do we implement ciphers with 128 or 256 bit block sizes on 32,
or even 16 bit CPUs? :)
The point is that just because you don't have 64 bit integers in your
language, it doesn't mean you can't handle 64 bit data. Infact, most
ciphers this is absolutely no barrier what-so-ever, and in a few it is
an utterly trivial inconvience.
In most cases, given you don't care about the actual /value/ of the
data, you just do two 32 bit operations instead of one 64 bit one.
Sometimes these operations don't even need to refer to each other.
B.