Hi,

(Dropping in on the end of a discussion where I haven't been paying attention ...)

It is worth having a look at the Samba stream cipher, extensively analysed as part of the eStream project. Links:

http://cr.yp.to/snuffle.html
http://nacl.cace-project.eu/
http://www.ecrypt.eu.org/stream/
http://bench.cr.yp.to/

Timing attack resistant, fast. Timing attacks now seem to be a significant source of information leakage, and are a problem with some current AES implementations.

Also interesting in this context is that 64 bits of the IV can be used as a byte offset to get seekable encrypted streams (ie: page access).

The NaCl project has a good implementation.

Regards,

Jan.

On 10/11/2010, at 5:50 AM, Jim Starkey wrote:

> I'd like to suggest a short diversion into cryptology with regards to
> ECB (electronic code book), CBC (cipher block chaining), initialization
> vectors, Firebird, and security. It's not important, but it is interesting.
>
> There are two ways to analyze a crypto-system. One is to analyze
> possible attacks attempting to reconstruct the encryption key. The
> other is "information leakage", where information is deduced from the
> the cryptotext alone.
>
> As discussed earlier, ECB encrypts each 16 byte segment of plaintext
> independently, which CBC XORs the previous block of cryptotext with the
> next block of plaintext. To get things going, CBC XORs the first block
> with an initialization vector. The advantage of CBC is not that it
> makes the encryption harder to break -- it doesn't. What it does do is
> prevent information leakage by ensuring that identical blocks of
> plaintext are not represented as recognizably identical blocks of
> cryptotext.
>
> Wikipedia gives a graphic, though slightly disingenuous, example of the
> difference, showing that an image of the Linux penguin encrypted with
> ECB still looks like the Linux penguin, albeit fuzzy and gray scale
> rather than color. This is because every block of uniform code (it's a
> four color image) maps to the same cryptotext. The areas bordering
> color changes are all noise. This phenomenon is valid if the original
> image with an uncompressed bitmap. If the original image where jpeg or
> gif, for example, the compression artifacts would destroy the simple
> mapping of solid color to solid color.
>
> A Firebird page encryption has greater commonality with a jpeg image
> than a bitmap. Nothing except the page header (which is boring) is
> aligned and SQZ eliminates repeating values. Even if encoded with ECB
> (which I do no advocate), the potential information leakage is
> essentially zip. If, for example, you were trying to find instances of
> the string "Starkey". The string can fall anywhere within two
> consecutive blocks (32 bytes assuming AES), where the remaining 25 byte
> (24 if you discount the run length encoding byte) are extremely unlikely
> to be constant. This means that there are 2^192 possible blocks of
> adjacent cryptotext that can contain "Starkey". And, since there is no
> way of knowing where on the page a record might be, you wouldn't even
> know where to start. It certainly would be possible to find an analyze
> TIPs and PIPs, but that's about it. This isn't an argument for ECB,
> just that CBC doesn't really buy anything. But since CBC is dirty
> cheap, there's no down side either.
>
> This brings us to the CBC initialization vector. Does it matter for
> page encryption? No, not a bit. It doesn't increase the strength of
> the cipher, so it isn't really part of the crypto-system and isn't part
> of the "shared secret", which is the foundation all cryptology. Its
> purpose is to guard again information leakage. However, the variability
> in the page header does the same thing. So there is no point is losing
> sleep trying to be clever about the initialization vector.
>
> The line protocol is a different matter entirely. The packets are more
> deterministic and have less infrastructure than data pages, aren't
> compressed (last time I looked, at least). Carefully analyzed, it is
> distinctly possible that useful information might leak. Here, CBC is
> important. But is the initialization vector significant? If there were
> any chance that two sessions would play out identically, perhaps. But
> the nature of the protocol makes this virtually impossible.
>
>
> --
> Jim Starkey
> Founder, NimbusDB, Inc.
> 978 526-1376
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>