Block cipher: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
imported>Sandy Harris
Line 1: Line 1:
{{subpages}}
{{main|Cryptography}}
{{TOC-right}}
A '''block cipher''' is a symmetric [[cipher]] that operates on fixed-size blocks of [[plaintext]], giving a block of [[ciphertext]] for each. The other main type of symmetric cipher is a [[stream cipher]], which generates a stream of keying material to be mixed with messages. Block ciphers can be used in various [[#Block cipher modes|modes]] when multiple blocks are to be encrypted.
There is an extensive literature both on the design of block ciphers and on methods of attacking them. For the design, see below and articles on specific ciphers. For the attacks, see [[cryptanalysis]] and articles on specific attacks. The standard references "Applied Cryptography" <ref name="schneier">{{citation
| first = Bruce | last = Schneier
| title = Applied Cryptography
| date = 2nd edition, 1996,
| publisher = John Wiley & Sons
|ISBN =0-471-11709-9}}</ref> and "Handbook of Applied Cryptography" <ref name=HAC>{{citation
| first1 = AJ | last1 = Menezes | first2 = PC | last2= van Oorschot | first3= SA | last3 = Vanstone 
| url=http://www.cacr.math.uwaterloo.ca/hac/
| title = Handbook of Applied Cryptography
| date = Fifth Edition, 2001
| ISBN=0-8493-8523-7}}</ref>, each have a large section on block ciphers. A useful web index of current work is the [http://www2.mat.dtu.dk/people/Lars.R.Knudsen/bc.html Block Cipher Lounge].
Among the best-known and most widely used block ciphers are two US government standards. The [[#DES | Data Encryption Standard]] (DES) from the 1970s is now considered obsolete; the [[#AES | Advanced Encryption Standard]] (AES) replaced it in 2002. Both of these ciphers are discussed below. Both also have their own articles; links are in the discussion below.
To choose the new standard, the [[National Institute of Standards and Technology]] ran an [[#AES candidates | AES contest]]. Fifteen ciphers were entered, five finalists selected, and eventually AES chosen. Text below covers all five finalists &mdash; Rijndael which became [[#AES | AES]], [[#Twofish | Twofish]],  [[#Mars | Mars]],  [[#RC6 | RC6]] and  [[# Serpent | Serpent ]] &mdash; and some other candidates.
In applications which encrypt a large volume of data, any cipher must be re-keyed from time to time. This prevents an enemy from accumulating large amounts of data encrypted with a single key; such a collection both facilitates some attacks and makes the payoff for breaking that key very large. Re-keying also limits the damage if a key is compromised in some other way. Block ciphers do not usually include a re-keying mechanism; some higher-level protocol manages that and re-keys the cipher using the normal keying mechanism.
== Principles and techniques ==
Most of the principles discussed here for block ciphers also apply to other cryptographic primitives. Key size is critical in [[stream cipher]]s as well as block ciphers. [[Hash]] algorithms generally use iteration and require avalanche. In both hashes and [[stream cipher]]s, non-linearity is an important design criterion, and s-boxes can be used in either.
=== Adequate key size ===
=== Adequate key size ===


Any cipher can be broken by a [[brute force]] attack if its key size is inadequate.  Current block ciphers all use at least 128-bit keys to protect against this; many support larger keys as well. For a block cipher, the cost of brute force increases as 2<sup>keysize-1</sup>. For discussion, see the [[Brute_force#Symmetric_ciphers | symmetric ciphers]] section of the "brute force attacks" article.
Any cipher can be broken by a [[brute force]] attack if its key size is inadequate.  Current block ciphers all use at least 128-bit keys to protect against this; many support larger keys as well. For a block cipher, the cost of brute force increases as 2<sup>keysize-1</sup>. For discussion, see the [[Brute_force#Symmetric_ciphers | symmetric ciphers]] section of the "brute force attacks" article.
=== Iterated block ciphers ===
Nearly all block ciphers use iteration; define some relatively simple transformation and apply it repeatedly to create the cipher. At setup time the '''primary key''' undergoes '''key scheduling''' giving a number of '''round keys'''. The actual cipher then has multiple '''rounds''', each applying the same transformation to the output of the previous round using the round key for the current round.
Some ciphers have an additional step called  '''whitening'''; additional material derived from the key is mixed into the plaintext before the first round, or into the ciphertext after the last, or both. [[#Variations on DES | DES-X]] is an example.
There is a trade-off that can be made in the design. With a simple fast round function many rounds may be required to achieve adequate security; for example, [[#GOST | GOST]] uses 32 rounds. A more complex round function might allow fewer rounds; for example, [[#IDEA | IDEA]] uses only 8 rounds. Since the ciphers with fast round functions generally need more rounds and the ones with few rounds generally need slower round functions, neither strategy is clearly better. Secure and reasonably efficient ciphers can be designed either way, and compromises are common.
In choosing the number of rounds, a safety margin is often applied. If the cipher appears to be secure after a certain number of rounds, the designer generally specifies a larger number for actual use.
When a block cipher is constructed from another cryptographic primitive, there may be no need to iterate because the other primitive provides adequate security. For example, [[RSA]] can be used as a block cipher with block size equal to the RSA modulus, and other [[public key]] techniques can be used in the same way. In effect, this is one extreme of the trade-off described in the previous paragraph; if the round function is itself cryptographically secure, then only one round is needed.
In [[cryptanalysis]] it is common to attack '''reduced round''' versions of a cipher. For example, instead of full 16-round DES, the analyst might start by trying to break a two-round or four-round version. Such attacks are easier and success there may lead to insights that are useful in work against the full cipher, or even to an attack that can be extended to break the full cipher. In the best possible case for the cryptanalyst, a break of the two-round system might lead to an attack on a four-round system which in turn might break the eight-round version and finally all 16 rounds.
=== Avalanche ===
The designer wants changes to propagate through the cipher so that, for example, a single-bit change at round n affects all bits of the ciphertext by round n+x for some reasonably small x. Ideally, x would be 1; certainly it must be much less than the total number of rounds. If the round function design gives a large x then the cipher will need more rounds to be secure.
This was named the '''avalanche effect''' in a paper <ref>{{ cite paper | author = Horst Feistel | title = Cryptography and Computer Privacy | journal = Scientific American | date = 1973 | url = http://www3.edgenet.net/dcowley/docs.html }}</ref> by [[Horst Feistel]]. The idea is that changes should build up like an avalanche, so that a tiny initial change quickly creates large effects. The term and its exact application were new, but the basic concept was not; avalanche is a variant of [[Claude Shannon]]'s diffusion and that in turn is a formalisation of ideas that were already in use.
The '''strict avalanche criterion''' <ref name=strictav> {{cite paper | author = A. F. Webster and [[Stafford E. Tavares]] | title = On the design of S-boxes | journal = Advances in Cryptology - Crypto '85 (Lecture Notes in Computer Science) | date = 1985 }} </ref> is a strong version of the requirement for good avalanche properties. Complementing any single bit of input should give a 50% chance of a change in any given bit of output.
=== Substitution-permutation networks ===
The idea of a '''substitution-permutation network''' or '''SP network''' originated with [[Claude Shannon]] <ref>{{cite paper
| author = C. E. Shannon
| title = Communication Theory of Secrecy Systems
| journal = Bell Systems Technical Journal
| volume = 28
| date = 1949
| pages = pp.656-715 }}</ref>. In his terms, a cipher needs both '''confusion''' and '''diffusion'''. In an SP network, there are two layers in each round: a substitution layer provides confusion, then a permutation layer provides diffusion.
The '''S-layer''' typically uses look-up tables called S-boxes or substitution boxes, though other mechanisms are also possible. The input is XOR-ed with a round key, split into parts and each part used as an index into an S-box. The S-box output then replaces that part so the combined S-box outputs become the S-layer output. S-boxes are discussed in more detail in their own [[#S-boxes | section]] below.
The '''P-layer''' permutes the resulting bits, adding confusion or in Feistel's terms helping to ensure avalanche.
A single round of an SP network does not usually provide good avalanche properties; output bits are affected only by inputs to their S-box. not by all input bits. However, the P-layer ensures that the output of one S-box in one round will affect several in the next round so, after a few rounds, overall avalanche properties can be very good.
=== Feistel structure ===
Many block ciphers use the Feistel structure, devised by [[Horst Feistel]] of IBM and used in DES. Such ciphers are known as [[Feistel cipher]]s. Each round uses a function F whose input and output are each half a block. Splitting the block into right and left halves and showing XOR as ^ and round key for round n as k<sub>n</sub>, even numbered rounds are then:
left<sub>n</sub> = left<sub>n-1</sub> ^ F(right<sub>n-1</sub>, k<sub>n</sub>)
right<sub>n</sub> = right<sub>n-1</sub>
and odd-numbered rounds are
right<sub>n</sub> = right<sub>n-1</sub> ^ F(left<sub>n-1</sub>, k<sub>n</sub>)
left<sub>n</sub> = left<sub>n-1</sub>
Since XOR is its own inverse and the half-block that is used in the F function is unchanged in each round, reversing this is straightforward. For example, the decryption step matching the first example above is:
left<sub>n-1</sub> = left<sub>n</sub> ^ F(right<sub>n</sub>, k<sub>n</sub>)
right<sub>n-1</sub> = right<sub>n</sub>
In some ciphers, all operations must be reversible so that decryption can work. In a Feistel cipher, the F function itself need not be reversible, only repeatable. This gives the designer extra flexibility; almost any operation he can think up can be used in the F function.
A single round in a Feistel cipher has less than ideal avalanche properties. In our first example above, half the output bits (on the right) are unchanged and the left<sub>n-1</sub> input bits each affect only one output; this falls well short of the ideal in which every input bit affects every output bit. However, the other half is changed in the next round and the F function can be designed so that small changes in its inputs (half-block or round key) produce large output changes. Within a few rounds, a Feistel cipher can have excellent overall avalanche properties.
The hard part of Feistel cipher design is of course the F function. Design goals include efficiency, easy implementation, and good avalanche properties. Also, it is critically important that the F-function be highly non-linear. All other operations in a Feistel cipher are linear and a cipher without enough non-linearity is weak; see the next section.
=== Non-linearity ===
To be secure, '''every cipher must contain non-linear operations'''. If all operations in a cipher were linear &mdash; in any algebraic system, with the attacker making the choice of system and allowed to try as many as he likes &mdash; then the cipher could be reduced to a system of linear equations. Any system of [[simultaneous linear equations]], in any algebra, can be solved straightforwardly if the number of equations matches or exceeds the number of variables. The attacker need only plug in known plaintext/ciphertext pairs until that condition holds, then solve for the key.
For example, for a cipher with 64-bit blocks and a 128-bit key, the attacker could write 64 equations each expressing one output bit in terms of 64 inputs and 128 key bits. Plug in a known plaintext/ciphertext pair and only the key bits remain as variables. He has 64 equations in 128 variables, not a soluble system. However, if he has a second known pair, that gives him a ''different'' set of 64 equations with the same 128 key bits as variables. The total system is now 128 equations in 128 variables. ''If the equations are all linear, this is soluble by standard techniques''. However, he also has the option of plugging in a third known pair to get a system with 192 equations in 128 variables if that is easier to solve, or going even further if that helps.
If the key schedule causes difficulties for him, he has the option of bypassing it. Instead of solving for the 128-bit master key, he can try to solve for all the round keys, 512 to 1024 bits in typical block ciphers. This requires more known plaintext/ciphertext pairs and the number of equations becomes distinctly unwieldy, but if all the equations are linear then the system is still, at least in theory, straightforwardly soluble. Finding the round keys breaks the cipher just as finding the master key would; an attacker can try either or both.
The attacker can also try [[linear cryptanalysis]]; if he can find a good linear ''approximation'' for the round function and has enough known plaintext/ciphertext pairs, then this will break the cipher.
What makes these attacks impractical is a combination of the sheer size of the system of equations used and non-linearity in the relations involved. In any algebra, solving a system of ''linear'' equations is more-or-less straightforward provided there are more equations than variables. However, solving ''non-linear'' systems of equations is far harder so the cipher designer strives to introduce [[non-linearity]] to the system. Combined with good avalanche properties and enough rounds, this makes both direct algebraic analysis and [[linear cryptanalysis]] prohibitively difficult. There are several ways to add non-linearity; some ciphers rely on only one while others use several.
One method is '''mixing operations from different algebras'''. If the cipher relies only on Boolean operations, the cryptanalyst can try to attack using Boolean algebra; if it uses only arithmetic operations, he can try normal algebra. If it uses both, he has a problem. Of course arithmetic operations can be expressed in Boolean algebra or vice versa, but the expressions are inconveniently (for the cryptanalyst!) complex and non-linear whichever way he tries it.
For example, in the CAST-128 or Blowfish F function, it is necessary to combine four 32-bit words into one. This is not done with a straightforward x = a+b+c+d or x=a^b^c^d but instead with something like x = (a+b)^(c-d) in one round and x = (a^b)+(c^d) in another. On most computers this costs no more, but it makes the analyst's job harder.
Other operations can also be used, albeit at higher costs. [[#IDEA | IDEA]] uses multiplication modulo 2<sup>16</sup>+1 and [[#AES | AES]] does matrix multiplications in a field.
Rotations, also called '''circular shifts''', on words or registers are non-linear in normal algebra, though they are easily described in Boolean algebra. Some ciphers such as GOST use the same rotation by a constant amount in every round; it is possible to use different constant rotations in different rounds. CAST-128 uses a key-dependent rotation in the F function. [[Ron Rivest]] used data-dependent rotations in [[RC-5]] and [[RC-6]].
A general operation for introducing non-linearity is the substitution box or '''S-box'''; see following section.
=== S-boxes ===
S-boxes or '''substitution boxes''' are look-up tables. The basic operation involved is a = sbox[b] which, at least for reasonable sizes of a and b, is easily done on any computer.
There is an extensive literature on the design of good S-boxes, much of it emphasizing achieving high non-linearity though other criteria are also used. See this online [http://www.ciphersbyritter.com/RES/SBOXDESN.HTM  literature survey] and references below.
S-boxes are described as m*n or m by n, with m representing the number of input bits and n the number of output bits. For example, DES uses 6 by 4 S-boxes. The storage requirement for an m*n S-box is 2<sup>m</sup>*n bits, so large values of m are problematic. Values up to eight are common; going much beyond that would be expensive.
S-boxes are often used in the S-layer of an [[#Substitution-permutation networks | SP Network]]. In this application, the S-box must have an inverse to be used in decryption. It must therefore have the same number of bits for input and output; only n*n S-boxes can be used. Another common application is in the F function of a [[#Feistel structure | Feistel cipher]]. Since the F function need not be reversible, there is no need to construct an inverse s-box for decryption and S-boxes of any size may be used. With either an SP network or a Feistel construction, non-linear S-boxes and enough rounds give a highly non-linear cipher.
In early Feistel ciphers, [[#DES | DES]] and [[#GOST | GOST]], the F function is essentially one round of an [[#Substitution-permutation networks | SP Network]]. These ciphers  use eight 6*4 or 4*4 S-boxes to get 32 bits of S-box output. Those bits, reordered by a simple transformation, become the 32-bit output of the F function. Avalanche properties are less than ideal since each output bit depends only on the inputs to one S-box. The output transformation compensates for this, ensuring that the output from one S-box in one round affects several in the next round, so that good avalanche is achieved after a few rounds.
Later Feistel ciphers use bigger S-boxes and do not use S-box bits directly as F function output. For example, [[#Blowfish | Blowfish]] and [[#CAST | CAST-128]] use four 8*32 S-boxes. The 32-bit input is XORed with the round key then split into four bytes and each byte is passed through a different S-box, giving four 32-bit results. Those results are then combined (non-linearly) to get the 32-bit F function output. Such an F function has ideal avalanche properties &mdash; all output bits depend on all input bits and all key bits. No output transformation is required. Of course, one may be used anyway; CAST-128 has a key-dependent rotation.
==== S-boxes as a model of other things ====
S-boxes may be used in analysis even when they are not actually used in the cipher. Any operation whose output is fully determined by its inputs can be described by an S-box; concatenate all inputs into an index, look that index up, get the output.
For example, the multiplication in [[#IDEA | IDEA]] has two inputs and one output, all 16-bit, so it can be modeled as a 32*16 S-box. In an academic paper, one might look at this as an S-box in order to apply standard tools for measuring non-linearity, or to compare it with other ciphers that do use S-boxes. A well-funded cryptanalyst might actually build the S-box (8 gigabytes of memory) either as a step in analysis or to speed up an attack.
In theory, larger components, or even the whole cipher, can be modeled in the same way. For the F function in a Feistel cipher, the inputs are only half a block and a round key; this gives an 80*32 or 64*32 S-box, much too big for an attacker to actually build but perhaps usable in theoretical work. Try to model anything bigger &mdash; a whole cipher, a round of a non-Feistel cipher, or multiple rounds of a Feistel cipher &mdash; and S-box dimensions become astronomical. Consider [[#AES | AES]] with 128-bit blocks and (the minimum) 128-bit key size; this can be modeled as a 256*128 S-box, an array with 2<sup>256</sup> entries, but the  model is unlikely to be useful.
== Pre-AES block ciphers ==
=== DES ===
The [[Data Encryption Standard]], DES, is among the the best known and most thoroughly analysed block ciphers. It was invented by [[IBM]], and was made a US government standard for non-classified government data and for regulated industries such as banking, in the late 70s. From then until about the turn of the century, it was very widely used. However, it is now considered obsolete; its 56-bit key size makes it highly vulnerable to a [[brute force]] attack, given modern computers. As a standard, it has been replaced by [[#AES | AES]].
Some applications still use [[#Triple DES | Triple DES]], a variant which applies DES three times with two or three different keys; see next section.
DES operates on 64-bit blocks and takes a 56-bit key. It is a [[Feistel cipher]] with 16 rounds and a 48-bit round key for each round, To generate the round keys, the 56-bit key is split into two 28-bit halves and those halves are circularly shifted after each round by one or two bits. Then 48 bits from them are selected and permuted to form the round key.
DES uses eight S-boxes, each 6 bits in and 4 out. The F function works as follows:
expand the 32-bit input to 48 bits, simply by copying some bits twice
XOR with the 48-bit round key
split the result into 8 6-bit chunks
pass each chunk through a different S-box, giving 32 output bits
permute the output bits
The permutation ensures rapid avalanche; a one-bit change in key affects one S-box; a one-bit change in the input block affects one or two S-boxes. With the permutation, changing the output of one S-box affects several in the next round. After a few rounds, the effect spreads to the entire output.
Every new [[cryptanalysis | cryptanalytic]] technique invented since DES became a standard has been tested against DES. None of them have broken it completely, but two &mdash; [[differential cryptanalysis]] and [[linear cryptanalysis]] &mdash; give attacks theoretically significantly better than brute force. This does not appear to have much practical importance since both require enormous numbers of known plaintexts and since DES has been repeatedly broken by brute force anyway. All the older publicly known cryptanalytic techniques have also been tried, or at least considered, for use against DES; none of them work.
The generation of block ciphers which followed DES in the 80s and 90s &mdash; such as GOST, Blowfish, CAST-128 and IDEA (see below for all) &mdash; nearly all used 64-bit blocks, like DES, but all used 128-bit or longer keys for better resistance to [[brute force]]. Many of the techniques used came from DES and some of the design principles came from analysis of DES.
In 2002, DES was replaced as a US government standard by the [[#AES | Advanced Encryption Standard]] which uses 128-bit blocks and takes 128, 192 or 256-bit keys.
==== DES is not secure ====
DES can no longer be considered secure because its 56-bit key is simply too short. It is vulnerable to a [[brute force]] search of the whole key space, either by large collections of general-purpose machines or even more quickly by specialized hardware. Of course this also applies to any other cipher with only a 56-bit key.
In 1998, the [http://www.eff.org Electronic Frontier Foundation] built a DES-cracking machine. It can find a DES key in an average of a few days' search. The details of all this, including complete code listings and complete plans for the machine, have been published in "Cracking DES" <ref>{{cite book
| author = Electronic Frontier Foundation
| title = Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design
| publisher = Electronic Frontier Foundation
| url = http://cryptome.org/cracking-des/cracking-des.htm
| isbn = ISBN: 1-56592-520-3 
| date = 1998 }}</ref>
That machine cost just over $200,000 to design and build in 1998. [[Moore's Law]] is that machines get faster (or cheaper, for the same speed) by roughly a factor of two every 18 months. At that rate, the cost in 2007, 9 years later, should be down to $200,000/2<sup>9/1.5</sup> = $3125, and a quarter of that by 2010. Such estimates are far from exact; we cannot say with any precision what such a cracker would cost today. However, we can say with certainty that DES should no longer be used to protect valuable data.
Before the definitive EFF effort, DES had been cracked several times by people using many machines. See this [http://www.distributed.net/pressroom/DESII-1-PR.html press release] for example. A major corporation, university, or government department could break DES by using spare cycles on their existing collection of computers, by dedicating a group of otherwise surplus machines to the problem, or by combining the two approaches. It might take them weeks or months, rather than the days required for the EFF machine, but they could do it.
==== Variations on DES ====
DES is vulnerable to [[brute force]] attack because of its small key. However, it has withstood decades of intensive analysis with no catastrophic flaws found, so it appears to be basically a remarkably solid design. Various people have therefore sought ways to achieve larger key size while retaining the basic DES algorithm.
[[Ron Rivest]] proposed '''DES-X''' or DESX [http://www.rsa.com/rsalabs/node.asp?id=2232], essentially DES with whitening. 64 bits of key material are XORed into the plaintext before encryption, and 64 more into the ciphertext afterward. With the 56 bits of DES key, the gives 184 total keys bits so the cipher is safe from brute force attacks. Encryption overheads are only a tiny bit more than DES; the cost of the XORs. Analysis <ref>{{cite paper
| author = Joe Kilian and Phillip Rogaway
| title = How to protect DES against exhaustive key search
| journal = Advances in Cryptology - Crypto '96
| publisher = Springer-Verlag
| date = 1996
| pages = 252–267
| url = http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/desx.ps }}</ref> of resistance to [[linear cryptanalysis]] and [[differential cryptanalysis]] shows that it is better than DES against these attacks, but not hugely so.
Another approach is to use '''independent round keys'''. DES has 16 48-bit round keys, a total of 768 bits of keying material, but in normal DES they are all derived from the 56-bit main key. Use 768 independent key bits and the cipher is obviously resistant to brute force, one proposal was '''G-DES''' or Generalised DES <ref name="gdes">{{ cite paper
| author = Andreas Pfitzmann and Ralf Amann
| title = More Efficient Software Implementations of Generalized DES
| journal = Computers & Security,
| year = 1990
| volume = 12
| pages = 477-500 }}</ref>. However, Schneier at al. [http://www.schneier.com/paper-key-schedule.pdf] demonstrate that the technique has weaknesses.
=== Triple DES ===
Another way to derive a stronger cipher from DES is to apply DES multiple times with different keys.
Just applying DES twice, '''double DES''', is '''ineffective'''. Using two 56-bit keys, one might expect an attacker to have to do 2<sup>112</sup> work to break it. In fact, only 2<sup>57</sup> work is required with a  [[meet-in-the-middle attack]], though a large amount of memory is also required. That is, double DES is only four times stronger than DES, which can be broken by [[brute force]] with 2<sup>55</sup> encryptions.
'''Triple DES''', sometimes written 3DES, is '''effective'''. Apply DES three times with two or three different keys. This is also vulnerable to a meet-in-the-middle attack, but the work factor for that attack is 2<sup>112</sup>. That provides adequate protection for many applications, and no better attack is known.
Triple DES can be somewhat slow compared to other ciphers. It requires three DES encryptions per block. DES was designed for hardware implementation and includes some operations which are difficult in software. For new applications, a newer cipher such as [[#AES | AES]] will generally be both faster and more secure; Triple DES provides only 2<sup>112</sup> strength against the best known attack, meet-in-the-middle. AES is resistant to that attack and gives 2<sup>128</sup> or more against the best known attack on it, brute force.
Triple DES is, however, still widely deployed in legacy applications. Consider a bank with several thousand ATM machines, with built-in hardware or well-tested software for triple DES. Changing those will certainly be expensive and will entail some risk of bugs in the new system; it may not be worth it.
Triple DES can be done with three keys, two keys or just one key, though the one-key variant should never be used. In all cases, the order of operations is EDE or encrypt-decrypt-encrypt.
The three-key variant is widely used; for example RFC 2451 specifies it for use in [[IPsec]].
In the two-key variant the first and third keys are the same. This gives a saving in key storage and key transmission overheads; only 112 bits are required rather than 168. This is not significant in most applications. 3DES with three keys has only 2<sup>112</sup> strength against a meet-in-the-middle attack, so it is possible that the two key version, with 2<sup>112</sup> against either brute force or meet-in-the-middle, is just as strong.
The one-key variant is a "worst of both worlds" solution, the overheads of triple DES (three times those of DES) with the security of DES (inadequate against brute force attacks). The only possible reason for doing this would be if one of the communicating systems only supported DES while the other had only triple DES. By using single-key triple DES on one end, you could get the two to encrypt their communications, albeit not securely.
=== GOST ===
The GOST cipher, and the related GOST hash algorithm, were standards in the [[Soviet Union]].
The GOST cipher <ref> schneier </ref> resembles DES in many ways; it is an iterated block cipher with a Feistel structure using eight s-boxes in the F function; each s-box produces four bits of output and these are combined to produce the 32-bit output. However, it differs from DES in other ways. There is no expansion from 32 bits to 48, so s-box inputs are only four bits rather than six, and there is no permutation of the output bits, only an 11-bit circular shift; these differences make GOST easier to implement in software than DES. However, they may also weaken the cipher; GOST compensates by increasing the number of rounds to 32 rather than DES's 16.
GOST also uses a 256-bit key which makes it, unlike DES, thoroughly resistant to [[brute force]] attacks.
=== CAST ===
The original work on CAST was in [[Carlisle Adams]]' PhD thesis <ref>{{cite paper
| author = C. M. Adams
| title = A Formal and Practical Design Procedure for Substitution-Permutation Network Cryptosystems
| publisher = Department of Electrical Engineering, Queen's University
| date = 1990 }}</ref>. A well-known paper is "Constructing Symmetric Ciphers using the CAST Design Procedure".  <ref>{{cite paper
| author = C. M. Adams
| title = Constructing Symmetric Ciphers using the CAST Design Procedure
| journal = Designs, Codes and Cryptography
| publisher = Springer Netherlands
| date = November 1997
| url = http://jya.com/cast.html
}}</ref>. There is also a [http://www.patentstorm.us/patents/5825886.html US patent] on some of the techniques.
One objective of the design procedure is to produce ciphers provably immune to both [[linear cryptanalysis]] and [[differential cryptanalysis]] <ref>{{ cite paper
| author = H.M. Heys and S.E. Tavares
| title = On the Security of the CAST Encryption Algorithm
| journal = Canadian Conference on Electrical & Computer Engineering
| date = September 1994 }}</ref>. These are the only known techniques that break [[#DES| DES]] with less effort than brute force; more generally, they are the most powerful known attacks against block ciphers. Both, however, require large numbers of known or chosen plaintexts. A cipher that has adequate key size to prevent brute force and is immune to those attacks is resistant to the best known [[cryptanalysis | cryptanalytic]] methods.
The procedure, taking linear cryptanalysis as our example and abbreviating it LC, runs as follows:
from properties of the F function, especially the S-boxes, derive a maximum m on the quality of any linear approximation to a single round
consider r, the number of rounds, as a variable
write an expression for e, the effort required to break the cipher by LC, in terms of r and m
find the minimum r such that e exceeds the effort for brute force, making LC ''impractical''
write an expression for c, the number of chosen plaintexts required, also in terms of r and m
(the required number of known plaintexts is >= that, so we can ignore it)
find the minimum r such that c exceeds the number of ''possible'' plaintexts, 2<sup>blocksize</sup>, making LC ''impossible''
A similar approach applied to differentials gives values for r that make differential cryptanalysis impractical or impossible. Choose the actual number of rounds so that, at a minimum, both attacks are impractical. Ideally, make both impossible, then add a safety factor.
CAST ciphers are Feistel ciphers using large S-boxes, usually 8*32 rather than the 6*4 of DES. They are primarily designed for software implementation, rather than the 1970s hardware DES was designed for, so looking up a full computer word at a time makes sense. An 8*32 S-box takes one K byte of storage; several can be used on a modern machine without difficulty. The S-boxes are constructed with [[bent functions]] as their columns and overall non-linearity and other desirable traits carefully optimised. A paper on generating them is Mister & Adams "Practical S-box Design" <ref>{{cite paper
| author = S. Mister, C. Adams
| title = Practical S-Box Design
| journal = Selected Areas in Cryptography (SAC '96)
| date = August, 1996
| pages = 61-76 }}</ref>.
The original CAST cipher <ref> schneier 334</ref> was a Feistel cipher with 64-bit blocks, a 64-bit key, 8 rounds with 16-bit round keys, and six 8*32 S-boxes. For the F function, split the 32-bit input into 4 bytes and the round key into 2 bytes. Run each of the 6 bytes through a different S-box to get 6 32-bit outputs. Combine those using XOR. 
=== CAST-128 ===
'''CAST-128''', also called CAST5, is the best-known and most widely used CAST cipher. It replaced [[#IDEA | IDEA]] in [[PGP]] in version 3.0 and is specified in all versions of the OpenPGP standard, including the current RFC 4880, [[Nortel]] and their spin-off [[Entrust]] also used it in several products; Adams worked for both companies.
CAST-128  is a Feistel cipher with 64-bit blocks and 16 rounds. Key sizes from 40 to 128 bits are supported; 128 is almost invariably used. There are eight 8*32 S-boxes, four used in the key schedule and the other four in actual encryption. Round keys are 37 bits.
The F function XORs the input with 32 bits of round key, splits the result into bytes and runs each byte through a different S-box to get four 32-bit results. Those are combined non-linearly with different functions in different rounds, things like x = (a+b)^(c-d). Finally, the output is given a rotation controlled by the other 5 round key bits.
A CAST-128 specification is in RFC 2144. The cipher is freely available for any use.
A descendant named [[#CAST-256 | CAST-256]] was an AES candidate.
=== Blowfish ===
'''Blowfish''' was designed by [[Bruce Schneier]] and the cipher has a [http://www.schneier.com/blowfish.html home page].
It is a Feistel cipher with 64-bit blocks and 16 rounds. Supported key sizes are 32 to 448 bits; at least 128 is recommended. The F function XORs the input with the 32-bit round key, splits the result into bytes and runs each byte through a different S-box to get four 32-bit results. Those are combined non-linearly with x = ((a+b)^c)+d.
Blowfish S-boxes are key-dependent, randomly generated at cipher setup time. For some applications, Blowfish key setup is inconveniently expensive.
The cipher is freely available for any use.
=== IDEA ===
IDEA <ref name=idea>{{cite paper
| author = X. Lai
| title = On the Design and Security of Block Ciphers
| journal = ETH Series in Information Processing, v. 1
| publisher = Hartung-Gorre Verlag
| date = 1992
}}</ref> is the '''International Data Encryption Algorithm''', a European standard. It is a iterated block cipher, but does not have a Feistel structure. Block size is 64 bits, key 128. No S-boxes are used.
IDEA achieves non-linearity by mixing operations from three different algebraic systems. All operations have 16-bit words as both input and output. Two are just bitwise XOR and addition modulo 2<sup>16</sup>. The third is basically multiplication, modulo 2<sup>16</sup>+1, but with some additional code so the "x*0 yields zero for all x" case does not weaken the cipher.
To see how this works, consider this multiplication table modulo 5:
    0  1  2  3  4
0  0  0  0  0  0
1  0  1  2  3  4
2  0  2  4  1  3
3  0  3  1  4  2
4  0  4  3  2  1
Note that, ignoring multiplications by zero, every column and every row is a permutation of the set (1,2,3,4). This is true for any prime modulus.
Our inputs are 2-bit numbers (0,1,2,3). We map them to (4,1,2,3) and then multiply them modulo 5; all multiplications use the non-zero part of the table. Results are in (1,2,3,4), which we map back to (1,2,3,0) so we get 2-bit output.
C code for IDEA multiplication of 2-bit numbers (range 0-3) would be:
#define NBITS 2
#define MAX (1<<NBITS)
#define MOD (MAX+1)
unsigned idea_multiply(unsigned x, unsigned y)
{
    unsigned z ;
    // make sure inputs are in range
    x %= MAX ;
    y %= MAX ;
    // adjust the range
    // avoid multiplying by zero
    if( x == 0 ) x = MAX ;
    if( y == 0 ) y = MAX ;
    // calculate the result
    // see table above
    z = (x*y) % MOD ;
    // adjust it
    // avoid returning MAX
    if( z == MAX ) z = 0 ;
    return( z ) ;
}
Change NBITS to 16 and you have real IDEA multiplication, operating on 16-bit quantities. This works correctly because MOD is then the prime 2<sup>16</sup>+1. On a 32-bit processor, you need to add a bit of extra code to avoid having MAX*MAX overflow a 32-bit register, but that is the only special case.
This operation is highly non-linear and has good avalanche properties; every output bit depends on all the inputs. It is not nearly as cheap as addition or XOR, but it is reasonably fast on a modern 32-bit or larger CPU. In most environments it will be more expensive than S-box lookups but in some, such as an embedded processor with limited cache, it may be cheaper. In any case, IDEA uses only 8 rounds so it can afford a moderately expensive operation in the round function.
=== RC5 ===
RC5, '''Rivest Cipher 5''' was from [[Ron Rivest]]. It was the first well-known cipher to make extensive use of '''data-dependent rotations''' to achieve non-linearity.
RFC 2040 gives an RC5 specification for Internet use.
Its descendant [[#RC6 | RC6]], also using data-dependent rotations, was an AES finalist. [[RSA Laboratories]] have a page describing [http://www.rsa.com/rsalabs/node.asp?id=2251 both ciphers].
=== TEA ===
The '''Tiny Encryption Algorithm''', or '''TEA''' <ref> {{cite paper
| title =  TEA, a Tiny Encryption Algorithm
| author = David J. Wheeler, Roger M. Needham
| url = http://www.cl.cam.ac.uk/ftp/users/djw3/tea.ps
| date = 1994 }}</ref> is a cipher designed for small size and easy software implementation. It is a Feistel cipher with 64-bit blocks, a 128-bit key, 32 rounds and a very simple round function using only 32-bit addition, bitwise XOR and shifts.
It has a [http://143.53.36.235:8080/tea.htm home page].
== AES candidates ==
Starting in the late 90s, the US [[National Institute of Standards and Technology]] ran a [[AES contest |contest]] to find a block cipher to replace DES. The requirements specified a block cipher with 128-bit block size and support for 128, 192 or 256-bit keys. Evaluation criteria included security, performance on a range of platforms from 8-bit CPUs (e.g. in smart cards) up, and ease of implementation in both software and hardware.
Fifteen submissions meeting basic criteria were received, not just from the US but from many other countries as well. After about a year of analysis and testing, and two conferences, the field was narrowed to five finalists &mdash; [[#Twofish | Twofish]], [[#MARS | MARS]], [[#Serpent | Serpent]],  [[#RC6 | RC6]], and  [[#AES | Rjindael]]. All finalists and some other candidates are described below.
In October 2002, they announced [http://www.nist.gov/public_affairs/releases/g00-176.htm] the winner &mdash; '''Rijndael''' (pronounced approximately "rhine doll"), from two Belgian designers. Rijndael then became the [[Advanced Encryption Standard]] or AES.
=== AES ===
The [[Advanced Encryption Standard]] or '''AES''' is the algorithm formerly known as '''Rijndael'''.
It is an iterated block cipher which does not use the Feistel structure. It encrypts 128-bit blocks with a 128, 192 or 256-bit key. Non-linearity is obtained by mixing operations from different algebraic groups.
The number of rounds varies with key size: 10 for 128-bit keys, 12 for 192-bit keys and 14 for 256-bit keys.
The NIST page on AES [http://csrc.nist.gov/archive/aes/rijndael/wsdindex.html] has much detail.
=== Twofish ===
[[Twofish]]  was an AES finalist cipher from [[Bruce Schneier]]'s company [[Counterpane]]. The cipher has a [http://www.schneier.com/twofish.html home page] which includes a link to the main design paper <ref>{{ cite paper
| title = Twofish: A 128-Bit Block Cipher
| author = Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson
| conference = First Advanced Encryption Standard (AES) Conference
| url = http://www.counterpane.com/twofish.pdf
| date = 1998}}</ref>.
Like all AES candidates, it uses 128-bit blocks and supports key sizes of 128, 192 or 256 bits.
=== Serpent ===
'''Serpent''' was an AES finalist cipher from an international team &mdash; [[Ross Anderson]], [[Eli Biham]] and [[Lars Knudsen]]. The cipher [http://www.cl.cam.ac.uk/~rja14/serpent.html home page] has extensive information.
Like all AES candidates, it uses 128-bit blocks and supports key sizes of 128, 192 or 256 bits.
Serpent is an SP network with 32 rounds. It uses eight 4 by 4 s-boxes, but unlike other ciphers it does not use them all in each round. Instead each rounds uses eight copies of the same s-box, but each of the eight s-boxes is used in four different rounds,
=== RC6 ===
'''RC6''' was an AES finalist cipher designed by [[Ron Rivest]]. Like all AES candidates, it uses 128-bit blocks and supports key sizes of 128, 192 or 256 bits.
Like [[#RC5 | RC5]], RC6 made extensive use of data-dependent rotations. [[RSA Laboratories]] have a page describing [http://www.rsa.com/rsalabs/node.asp?id=2251 both ciphers].
=== MARS ===
'''MARS'''  was an AES finalist cipher from [[IBM]]. Like all AES candidates, it uses 128-bit blocks and supports key sizes of 128, 192 or 256 bits.
The cipher has a [http://domino.research.ibm.com/comm/research_projects.nsf/pages/security.mars.html home page] and is now freely available.
=== CAST 256 ===
'''CAST-256''' was an AES candidate cipher; it did not make it into the finals. Like all AES candidates, it uses 128-bit blocks and supports key sizes of 128, 192 or 256 bits.
It is a Feistel-like cipher extended to four 32-bit sub-blocks instead of the two sub-blocks used in CAST-128 for 64-bit blocks. Each round takes one 32-bit sub-block as input and alters one 32-bit sub-block;  48 rounds are used. The F function and S-boxes are from [[#CAST-128 CAST-128]].
A CAST-256 specification is in RFC 2612. The cipher is freely available for any use.
=== Hasty Pudding ===
The '''Hasty Pudding''' cipher (HPC), from [[Rich Schroeppel]] was, in some ways, the most interesting of the AES candidates. It did not make it into the finals.
Hasty Pudding is a '''variable size block cipher'''; blocks can be any size the application requires. It therefore might be ideal for things like encrypting disk blocks. Also, quoting the home page "Arbitrary sets, such as dates, or the printable subset of ascii, or the 20-bit primes, can be encrypted to themselves." Key size is also variable; any integer number of bits.
The cipher has a [http://www.cs.arizona.edu/~rcs/hpc/ home page] and is freely available for any use.
== Block cipher modes ==
Various '''modes of operation''' for block cipher usage were originally defined for DES in a US [[Federal Information Processing Standard]] (FIPS) <ref>{{cite paper | title = FIPS 81: DES Modes of Operation | date = December 1980 | url = http://www.itl.nist.gov/fipspubs/fip81.htm}}</ref>. The most recent [[NIST]] recommendations are in "Recommendation for Block Cipher Modes of Operation" <ref>{{cite paper | title = Recommendation for Block Cipher Modes of Operation | publisher = National Institute for Standards & Technology | date = 2001 | url = http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf }}</ref>
These modes can be applied to any block cipher.
=== Electronic Code Book, ECB ===
In '''Electronic Code Book''' mode, the cipher is just applied to each block of plaintext independently.
The disadvantage is that the same plaintext block always encrypts to the same ciphertext; this gives an enemy some information. ECB is therefore '''generally not used'''.
=== Cipher Block Chaining, CBC ===
In '''cipher block chaining''' mode, the ciphertext output from the previous block is XORed into the plaintext before encryption. Encryption of block n is then:
  c<sub>n</sub> = encrypt( p<sub>n</sub> XOR c<sub>n-1</sub>)
For this to work for n=1, an '''initialisation vector''' (IV) must be provided to act as c<sub>0</sub>. This need not be secret, but it must be different for each message and should be random. If the same IV is repeatedly used, then if two or more messages start with the same text, they will encrypt identically for the first block or the first few blocks. This is an unnecessary weakness; using unique IVs is therefore standard practice.
CBC mode makes the encryption of any block depend on all blocks previously encrypted. A bit error in an encrypted block, such as might be caused by line noise, will cause the decryption of that block and the next to be garbled, but later blocks will not be affected. CBC is self-recovering against bit-flipping errors. However, loss of synchronisation is fatal; if even a single bit is dropped or added, then the affected block and all that follow it will be garbled. Authentication of the packet or message can prevent such problems if decryption is only applied to data that has passed authentication,
Cipher block chaining is much the most '''widely used mode'''. [[IPsec]] specifies it as the only permitted mode. [[PGP]] and [[TLS]] use it as well.
=== Cipher feedback, CFB ===
=== Output Feedback, OFB ===
=== Counter, CTR ===
In counter mode, a counter is encrypted to generate a series of pseudo-random output blocks. It can be used to create a [[pseudorandom number generator]] or a [[stream cipher]]; if the block cipher is secure and is keyed and re-keyed appropriately, these will be secure as well.,
Counter mode is used in the Yarrow <ref>{{cite paper
| title = Yarrow-160: Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator
| author = J. Kelsey, B. Schneier, and N. Ferguson
| conference = Selected Areas in Cryptography, SAC '99
| url = http://www.schneier.com/yarrow.html
| date = 1999 }}</ref> random number generator. They demonstrate an attack after 2<sup>keysize/3</sup> outputs, so any use of counter mode must be re-keyed before that.
==References==
{{reflist|2}}

Revision as of 10:57, 26 October 2008

Adequate key size

Any cipher can be broken by a brute force attack if its key size is inadequate. Current block ciphers all use at least 128-bit keys to protect against this; many support larger keys as well. For a block cipher, the cost of brute force increases as 2keysize-1. For discussion, see the symmetric ciphers section of the "brute force attacks" article.

Retrieved from "https://citizendium.org/wiki/index.php?title=Block_cipher&oldid=528854"