Re: too much encryption



Ertugrul Soeylemez wrote:
Looking at Wei Dai's benchmarks (Crypto++ library) for Blowfish vs
AES, you see Blowfish gets roughly 64 MB/Sec while AES (Rijndael) gets
61 MB/Sec. This agrees with Brian Gladman's benchmark of AES, about 69
MB/Sec. So for performance, I don't think it really matters.

That really depends on the implementation. If both implementations were
equally well optimized, then Blowfish would outperform AES noticably.
However, I use AES for disk encryption, too, but I prefer Blowfish for
my swap space.

That was my point though. Unless I am misunderstanding Wei Dai's
benchmarks, it shows a similar performance of both. I've seen other
benchmarks that agree. Of course, there are some issues with timing
attacks, which means you can't use fully optimized code of both. But I
think in the general case, you are not going to notice any difference
in speed. AES was picked because of it's performance. Unless you are a
seriously loaded webserver doing massive TLS connections, I don't see
any advantage to using Blowfish.


Secondly, Blowfish has a problem that AES doesn't in that Blowfish
uses a 64-bit block size. AES uses a 128-bit block size. I'm going to
presume whatever software you are using is using AES in CBC mode, as
that is what most people do.

CBC mode has a property that after about 2^{n/2} blocks, where n is
the block size, you begin to leak information about the
plaintext. That is, after 64 * 2^{64/2} bits = 64 * 2^32 bits = 32 GB,
Blowfish is going to start leaking information.

With AES however, you wouldn't see this leak until 128 * 2^64 bits =
274,877,906,944 GB

Implementations are free to apply the IV to either the clear-text block
or to the key. Doing the latter would invalidate that statement, as
then the CBC cycle depends on the key size instead of the block size.

I assume when you say apply to the key, you mean you do something like
IV xor KEY and then
previous_CT xor KEY for each block.

CBC isn't defined in terms of applying the IV to the key. CBC is
defined as applying the previous ciphertext block to the next plaintext
block. I've never seen any implementation or standard in which the IV
is applied to the key, but if you have references, I'd love to see
them. If you start chaining with keys, you run the risk of breaking the
benefits of CBC. I haven't fully thought about it, but at the very
least, error propogation is going to be different.

During the decryption phase, with CBC (the real CBC), a single bit
error in the ciphertext (perhaps the bit error is due to the storage
medium) will cause complete corruption of that block, and the
corresponding bit in the next plaintext block to be inverted. Using a
checksum, you can then "fix" that next plaintext block, so you end up
with a single bit error causing a loss of a block.

In your scheme however, a single bit error in the ciphertext would
cause two full blocks to be completely corrupted. The ciphertext block
with an error would decrypt to garbage. That errored block would be
XORed with the key in the next block, producing basically a different
key, which would then cause the next plaintext block to be destroyed
(as the next ciphertext block is being decrypted under the wrong key).

There are probably some security concerns as well.

But I digress.


Blowfish is a great algorithm, but I think it's time is starting to
pass.

That may be true, but it's still a fine algorithm for things like swap,
at least for now. What I like about Blowfish is that only a single
noticable flaw has been found so far. There are a number of insecure
keys, but anyway, the probability to get such a bad key is impracticably
low.


I agree that Blowfish is fine for a lot of things, but I think with the
massive amounts of storage people are beginning to aquire, and the
availability of things like AES, means implementations should be moving
away from 64-bit block sizes. For swap space though, it's probably less
of a concern, since I really hope you are not swapping that much to
disk that you will be hitting a 32GB limit. The other advantage to AES
is it is the standard.

But what flaw are you refering to? The best attack is a 4 round 2nd
order differential. The weak keys don't even really apply, since it is
a small class of them. The weak keys allow 14 rounds of Blowfish to be
distinguished from pseudorandom permutation. Blowfish is defined with
16 rounds, so the weak keys shouldn't be a problem for anyone.

-Matt

.



Relevant Pages

  • Re: Modes of operation
    ... A block cipher is deterministic: with the same key and the same input ... This is the main reason why, when the AES competition was launched, ... He explicitly recommended Blowfish if what you wanted to do ... worthwhile attacks have been made on Blowfish - although it is pretty ...
    (sci.crypt)
  • Re: Multiple encryption: again, and again, and again...
    ... >Blowfish key, then try every single AES key, then the second Blowfish ... plaintext/ciphertext pair, encrypt plaintext with all possible AES keys, ... already making of the attacker having time to brute-force AES or Blowfish ...
    (sci.crypt)
  • Re: Welche Festplattenverschlüsselung ist sicherer?
    ... auf Performance dem AES 256 immer überlegen war. ... Zwischen AES und Blowfish gibt es zwar Unterschiede bei der Performace, ... Notebook, da hier die Gefahr des Diebstahls relativ ...
    (de.comp.security.misc)
  • Re: The importance of IVs
    ... I haven't looked into Twofish very much, ... <address the limitations of Blowfish. ... Time for some rhetoric on AES vs. ... <It wasn't the NSA's "stamp of approval" that made Rijndael the AES ...
    (sci.crypt)
  • Re: too much encryption
    ... AES uses a 128-bit block size. ... to presume whatever software you are using is using AES in CBC ... defined as applying the previous ciphertext block to the next ... corresponding bit in the next plaintext block to be inverted. ...
    (comp.os.linux.security)