I've not been able to understand exactly the reason behind Blowfish being faster than AES. Is it dependent on the block size? Or is it processor dependent? (if Yes, then lets assume that AES accelerators are not used) I'd like to know the exact reason behind it. Thanks.
$\begingroup$
$\endgroup$
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
6
Blowfish has strong points regarding speed because bulk encryption (and decryption) reduce to an alternation of: a 8->32-bit table lookup, and one or two 32-bit operations (addition or XOR). That structure is very well suited to 32-bit CPUs with a short pipeline and a fast cache of at least 4 kByte; and is well suited for a straight C implementation, which generates code that often is very near optimum.
For each byte enciphered, and unless I miscount:
- Blowfish performs on average 8 table lookups and 10.25 straight 32-bit operations.
- AES-128 performs on average 10 table lookups and
7.7510.25 straight 32-bit operations (when using a common optimization also requiring 4 kByte of tables).
Table lookups are much more expensive than straight 32-bit operations (most of these come almost for free in practice), and dominate the cost. Thus yes, Blowfish can be a little faster than AES implemented in software; especially if the AES implementation is not optimized to the max, or is AES-256.
Other than that, Blowfish and AES are not playing in the same league, and AES often wins without battle:
- Blowfish is a 64-bit block cipher, while AES is a 128-bit block cipher; this is a serious issue in a growing number of applications.
- Blowfish key setup is a slow process that produces 4 kByte of table per instance, in RAM. By contrast AES can be implemented efficiently (at least in hardware) with no RAM, and (for encryption, which is the most used) no pre-computation at all (decryption requires a tiny pre-computation).
- The 4 kByte table (or 1 kByte, 512 bytes, or even 256 bytes with speed trade-of) used for fast software AES implementation can be shared between instances (or in ROM/flash), it can't in Blowfish.
That makes Blowfish a terrible algorithm when 64-bit block is an issue (e.g. CBC mode with gigabytes of data); or when key agility matters (on occasions the relative slowness of Blowfish's key setup is an asset, see bcrypt); or for hardware implementation; or when 4 kByte is a lot of RAM (e.g. some embedded systems, or a server handling many simultaneous connections).
Also: as rightly pointed in cherio's comment, AES has hardware implementation on many modern CPUs, and that more than offset any speed advantage Blowfish may have (but the question states "AES accelerators are not used").
-
$\begingroup$ Thank You very much for taking the time to give a detailed answer. $\endgroup$– SidCommented Apr 17, 2013 at 14:07
-
$\begingroup$ AES may indeed be faster than Blowfish in real-world scenarios, see e.g. these old Linux dm-crypt benchmarks. $\endgroup$ Commented Dec 10, 2013 at 18:46
-
$\begingroup$ How can it be implemented without RAM? $\endgroup$– MelabCommented Mar 22, 2015 at 18:45
-
2$\begingroup$ Most CPUs these days have support for AES instructions. If enabled EAS will blow blowfish out of water. Test if yours is enabled: access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/… $\endgroup$– oᴉɹǝɥɔCommented Jan 12, 2017 at 18:38
-
1$\begingroup$ @GroovyDotCom: the number (and AFAIK, cost) of table lookups for decryption is the same as in encryption, for both AES and Blowfish. Decryption in (at least, software) AES is slightly slower than encryption, for another reason: InvMixColumns is more costly than MixColumns. Also, on-the-fly computation of AES subkeys is not possible on decryption, which impacts implementations that do not amortize the derivation of subkeys across multiple encryptions. $\endgroup$– fgrieu ♦Commented Nov 25, 2020 at 8:50