I have been reading that DES is slow. Is it only slow in software or slow overall? Also, as far as Triple DES being slow is concerned, is double AES with two 128 bit keys slower than single AES with a 256 bit key?
DES is slow in software because it was designed back in the early 70's even before the 8086 processor existed, and uses several bit oriented operations that are just not implemented efficiently in a processor with a word oriented instruction set.
Its intended product was ASIC hardware designs, in which DES runs quickly. DES hardware processors are quite common on older network cards intended for use in servers and workstations (I still have LAN card with wire speed TDES hardware). DES was already considered obsolete by the time the technology would have trickled down into consumer grade hardware.
DES becomes even slower when we compare it from a security standpoint against AES. DES in software is probably half the speed of AES, and it is also half the key space. Therefore TDES is used to increase the key space, but now it is 1/6th the speed of AES. AES is also better designed to resist attacks other than brute force.
Double AES with two 128 bit keys requires about 1.5X the processing of AES with a 256-bit key, and at least from a brute force perspective is not as secure. The reason TDES is used instead of double DES is because it requires 3 operations in order to double the key space.
DES is slow compared to AES including in hardware because
- for comparable security we must use 3DES, which triples the number of rounds per block, to 48 for 3DES versus 10, 12, or 14 for AES;
- DES's block size is 64 bits, half of AES's 128 bit; so when encrypting a sizable block of data, 3DES does more rounds that AES by a factor of 96/10, 96/12, or 96/14;
- these is no (or little) hardware support for DES in modern CPUs, when there is for AES in increasingly many CPUs, including most targeting servers; hence hardware DES is offloaded to a distant IC, when AES is often in-core;
- DES is often used in CBC mode which does not allow parallelization and in-advance processing during encryption, when AES is often used in CTR mode which does.
However when we compare DPA-protected implementations as used in Smart Cards, there is not so much of a difference, and it is tends to be buried among other delays.
Double AES with two 128 bit keys would be significantly slower than single AES with a 256 bit key (20 rounds versus 14). Also double AES-128 would theoretically be vulnerable to a Meet-in-the-Middle attack, when AES-256 is not.
The Digital Encryption Standard is the description of an algorithm originally requiring a hardware implementation to be compliant.
The Initial Permutation when implemented with an 8 bit interface is 8 wires, the Inverse Permutation swaps the L and R block by swapping odd and even elements on the 8 bit interface.
The issue with performance in software comes from not having instructions to do things that we can describe in hardware that have no performance penalty (permutations).
Intel had an i8048 based implementation using embedded programming and couldn't keep up with a 300 baud MODEM.
At the same time Fairchild Federal had a bipolar CMOS chipset that was used in encrypting satellite transponders (105 Mbits/sec). We've seen papers describing high speed hardware implementations in the 5.4 GHz range in the past.
A decade ago Stretch Inc. had a programmable instruction coprocessor that could perform a complete DES round. There can be separate instructions for things like the Initial Permutation. Unfortunately their reconfigurable hardware isn't big enough for more complex algorithms, DES can be implemented in around 4.7K NAND gate equivalents, a DES round the majority of that).
As noted in the other answers once we accepted the idea of implementing encryption algorithms in higher performance computers we started developing algorithms targeting software implementation. There's also no real security advantage imposed in requiring complexity best left to hardware with the advent of higher performance FPGAs (or ASICs when you need that last factor of 10 speed up).
The restriction to hardware implementations was to control the dissemination of cryptography, which is now pervasive (and systemically attacked in different ways such as through key exchange weaknesses or secret subpoenas).
The original UNIX libcrypt had a DES implementation that could be initialized with a null salt (it was used for password hashing) and with some input and output alignment be compatible with the DES standard, executing 16 rounds once (instead of 25 DES interations). Essentially the cat had already been let out of the bottle (mixing metaphors).