PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Tue, 31 Jan 2012 00:31:48 UTC
Security Articles from
Wikipedia
Articles
Advanced Encryption Standard 1
Block cipher 10
Block cipher modes of operation 13
Certificate authority 24
CMAC 27
Cryptographic hash function 29
Diffie–Hellman key exchange 35
Digital signature 42
Digital Signature Algorithm 50
HMAC 53
HTTP Secure 57
IPsec 62
Kerberos (protocol) 70
Key distribution center 74
Message authentication code 76
Needham–Schroeder protocol 78
Pretty Good Privacy 82
Public key certificate 90
Public key infrastructure 94
Public-key cryptography 98
RSA (algorithm) 109
S/MIME 118
Secure Electronic Transaction 121
Secure Shell 123
Security service (telecommunication) 129
SHA-1 134
Stream cipher 143
Symmetric-key algorithm 149
Transport Layer Security 150
X.509 166
References
Article Sources and Contributors 175
Article Licenses
Advanced Encryption Standard
AES
The SubBytes step, one of four stages in a round of AES
General
Designers Vincent Rijmen, Joan Daemen
First published 1998
Derived from Square
Successors Anubis, Grand Cru
Certification AES winner, CRYPTREC, NESSIE, NSA
Cipher detail
Key sizes 128, 192 or 256 bits[1]
Block sizes 128 bits[2]
Structure Substitution-permutation network
Rounds 10, 12 or 14 (depending on key size)
Best public cryptanalysis
All known attacks are computationally infeasible. For AES-128, the key can be recovered with a computational complexity of 2126.1 using bicliques. For biclique attacks on AES-192 and AES-256, the computational complexities of 2189.7 and 2254.4 respectively apply. Related-key attacks can break AES-192 and AES-256 with complexities 2176 and 299.5, respectively.
Advanced Encryption Standard (AES) is a specification for the encryption of electronic data. It has been adopted
by the U.S. government and is now used worldwide. It supersedes DES.[3] The algorithm described by AES is a
symmetric-key algorithm, meaning the same key is used for both encrypting and decrypting the data.
In the United States of America, AES was announced by National Institute of Standards and Technology (NIST) as U.S. FIPS PUB 197 (FIPS 197) on November 26, 2001 after a five-year standardization process in which fifteen competing designs were presented and evaluated before it was selected as the most suitable (see Advanced Encryption Standard process for more details). It became effective as a Federal government standard on May 26, 2002 after approval by the Secretary of Commerce. It is available in many different encryption packages. AES is the first publicly accessible and open cipher approved by the National Security Agency (NSA) for top secret information (see Security of AES, below).
Originally called Rijndael, the cipher was developed by two Belgian cryptographers, Joan Daemen and Vincent
Advanced Encryption Standard 2 is a play on the names of the two inventors.
Strictly speaking, AES is the name of the standard, and the algorithm described is a (restricted) variant of Rijndael. However, in practice the algorithm is also referred to as "AES" (a case of totum pro parte).
Description of the cipher
AES is based on a design principle known as a substitution-permutation network. It is fast in both software and
hardware.[6] Unlike its predecessor, DES, AES does not use a Feistel network.
AES has a fixed block size of 128 bits and a key size of 128, 192, or 256 bits, whereas Rijndael can be specified with block and key sizes in any multiple of 32 bits, with a minimum of 128 bits. The blocksize has a maximum of 256 bits, but the keysize has no theoretical maximum.
AES operates on a 4×4 column-major order matrix of bytes, termed the state (versions of Rijndael with a larger
block size have additional columns in the state). Most AES calculations are done in a special finite field.
The AES cipher is specified as a number of repetitions of transformation rounds that convert the input plaintext into the final output of ciphertext. Each round consists of several processing steps, including one that depends on the encryption key. A set of reverse rounds are applied to transform ciphertext back into the original plaintext using the same encryption key.
High-level description of the algorithm
1. KeyExpansion—round keys are derived from the cipher key using Rijndael's key schedule
2.
2. Initial Round
1. AddRoundKey—each byte of the state is combined with the round key using bitwise xor 3.
3. Rounds
1. SubBytes—a non-linear substitution step where each byte is replaced with another according to a lookup table.
2. ShiftRows—a transposition step where each row of the state is shifted cyclically a certain number of steps. 3. MixColumns—a mixing operation which operates on the columns of the state, combining the four bytes in
each column. 4.
4. AddRoundKey
4. Final Round (no MixColumns)
1. 1. SubBytes 2. 2. ShiftRows 3. 3. AddRoundKey
The
SubBytes
step
In the SubBytes step, each byte in the state is replaced with its entry in a fixed 8-bit lookup table, S; bij = S(aij).
In the SubBytes step, each byte in
the matrix is updated using an 8-bit substitution box, the Rijndael S-box. This operation provides the non-linearity in the cipher. The S-box used is derived from the multiplicative
inverse over GF(28), known to have
good non-linearity properties. To avoid attacks based on simple algebraic properties, the S-box is constructed by combining the inverse function with an invertible affine transformation. The S-box is also chosen to avoid any fixed
points (and so is a derangement), and also any opposite fixed points.
The
ShiftRows
step
In the ShiftRows step, bytes in each row of the state are shifted cyclically to the left. The number of places each byte is shifted differs for each row.
The ShiftRows step operates on the rows of the state; it cyclically shifts the bytes in each row by a certain offset. For AES, the first row is left unchanged. Each byte of the second row is shifted one to the left. Similarly, the third and fourth rows are shifted by offsets of two and three respectively. For the block of size 128 bits and 192 bits the shifting pattern is the same. In this way, each column of the output
state of the ShiftRows step is composed of bytes from each column of the input state. (Rijndael variants with a
larger block size have slightly different offsets). In the case of the 256-bit block, the first row is unchanged and the
shifting for second, third and fourth row is 1 byte, 3 bytes and 4 bytes respectively—this change only applies for the
Advanced Encryption Standard 4
The
MixColumns
step
In the MixColumns step, each column of the state is multiplied with a fixed polynomial c(x).
In the MixColumns step, the four
bytes of each column of the state are combined using an invertible linear
transformation. The MixColumns
function takes four bytes as input and outputs four bytes, where each input byte affects all four output bytes.
Together with ShiftRows,
MixColumns provides diffusion in the cipher.
During this operation, each column is multiplied by the known matrix that for the 128 bit key is
The multiplication operation is defined as: multiplication by 1 means leaving unchanged, multiplication by 2 means shifting byte to the left and multiplication by 3 means shifting to the left and then performing xor with the initial unshifted value. After shifting, a conditional xor with 0x1B should be performed if the shifted value is larger than 0xFF.
In more general sense, each column is treated as a polynomial over GF(28) and is then multiplied modulo x4+1 with
a fixed polynomial c(x) = 0x03 · x3 + x2 + x + 0x02. The coefficients are displayed in their hexadecimal equivalent
of the binary representation of bit polynomials from GF(2)[x]. The MixColumns step can also be viewed as a
multiplication by a particular MDS matrix in a finite field. This process is described further in the article Rijndael mix columns.
The
AddRoundKey
step
In the AddRoundKey step, each byte of the state is combined with a byte of the round subkey using the XOR operation (⊕).
In the AddRoundKey step, the
subkey is combined with the state. For each round, a subkey is derived from the main key using Rijndael's key schedule; each subkey is the same size as the state. The subkey is added by combining each byte of the state with the corresponding byte of the subkey using bitwise XOR.
Optimization of the cipher
On systems with 32-bit or larger words, it is possible to speed up execution of
this cipher by combining SubBytes
and ShiftRows with MixColumns, and transforming them into a sequence of table lookups. This requires four 256-entry 32-bit tables, which utilizes a
total of four kilobytes (4096 bytes) of memory—one kilobyte for each table. A round can now be done with 16 table
lookups and 12 32-bit exclusive-or operations, followed by four 32-bit exclusive-or operations in the
AddRoundKey step.[7]
If the resulting four kilobyte table size is too large for a given target platform, the table lookup operation can be performed with a single 256-entry 32-bit (i.e. 1 kilobyte) table by the use of circular rotates.
Using a byte-oriented approach, it is possible to combine the SubBytes, ShiftRows, and MixColumns steps
into a single round operation.[8]
Security
Until May 2009, the only successful published attacks against the full AES were side-channel attacks on some specific implementations. The National Security Agency (NSA) reviewed all the AES finalists, including Rijndael, and stated that all of them were secure enough for U.S. Government non-classified data. In June 2003, the U.S. Government announced that AES may be used to protect classified information:
The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition
and use."[9]
AES has 10 rounds for 128-bit keys, 12 rounds for 192-bit keys, and 14 rounds for 256-bit keys. By 2006, the best
Advanced Encryption Standard 6
Known attacks
For cryptographers, a cryptographic "break" is anything faster than a brute force—performing one trial decryption
for each key (see Cryptanalysis). Thus, an attack against a 256-bit-key AES requiring 2200 operations (compared to
2256 possible keys) would be considered a break, even though 2200 operations would still take far longer than the age
of the universe to complete. The largest successful publicly-known brute force attack against any block-cipher
encryption has been against a 64-bit RC5 key by distributed.net.[11]
AES has a fairly simple algebraic description.[12] In 2002, a theoretical attack, termed the "XSL attack", was
announced by Nicolas Courtois and Josef Pieprzyk, purporting to show a weakness in the AES algorithm due to its
simple description.[13] Since then, other papers have shown that the attack as originally presented is unworkable; see
XSL attack on block ciphers.
During the AES process, developers of competing algorithms wrote of Rijndael, "...we are concerned about [its]
use...in security-critical applications."[14] However, at the end of the AES process, Bruce Schneier, a developer of the
competing algorithm Twofish, wrote that while he thought successful academic attacks on Rijndael would be developed someday, "I do not believe that anyone will ever discover an attack that will allow someone to read
Rijndael traffic."[15]
On July 1, 2009, Bruce Schneier blogged[16] about a related-key attack on the 192-bit and 256-bit versions of AES,
discovered by Alex Biryukov and Dmitry Khovratovich,[17] which exploits AES's somewhat simple key schedule
and has a complexity of 2119. In December 2009 it was improved to 299.5. This is a follow-up to an attack discovered
earlier in 2009 by Alex Biryukov, Dmitry Khovratovich, and Ivica Nikolić, with a complexity of 296 for one out of
every 235 keys.[18] Another attack was blogged by Bruce Schneier[19] on July 30, 2009 and released as a preprint[20]
on August 3, 2009. This new attack, by Alex Biryukov, Orr Dunkelman, Nathan Keller, Dmitry Khovratovich, and
Adi Shamir, is against AES-256 that uses only two related keys and 239 time to recover the complete 256-bit key of a
9-round version, or 245 time for a 10-round version with a stronger type of related subkey attack, or 270 time for an
11-round version. 256-bit AES uses 14 rounds, so these attacks aren't effective against full AES.
In November 2009, the first known-key distinguishing attack against a reduced 8-round version of AES-128 was
released as a preprint.[21] This known-key distinguishing attack is an improvement of the rebound or the
start-from-the-middle attacks for AES-like permutations, which view two consecutive rounds of permutation as the
application of a so-called Super-Sbox. It works on the 8-round version of AES-128, with a time complexity of 248,
and a memory complexity of 232.
In July 2010 Vincent Rijmen published an ironic paper on "chosen-key-relations-in-the-middle" attacks on
AES-128.[22]
The first key-recovery attacks on full AES due to Andrey Bogdanov, Dmitry Khovratovich, and Christian
Rechberger were published in 2011.[23] The attack is based on bicliques and is faster than brute force by a factor of
about four. The key is recovered from AES-128 in operations. For AES-192 and AES-256, and
operations are needed, respectively.
Side-channel attacks
Side-channel attacks do not attack the underlying cipher and so have nothing to do with its security as described here, but attack implementations of the cipher on systems which inadvertently leak data. There are several such known attacks on certain implementations of AES.
In April 2005, D.J. Bernstein announced a cache-timing attack that he used to break a custom server that used
OpenSSL's AES encryption.[24] The attack required over 200 million chosen plaintexts.[25] The custom server was
designed to give out as much timing information as possible (the server reports back the number of machine cycles
taken by the encryption operation); however, as Bernstein pointed out, "reducing the precision of the server’s
round-trip timings based on its local clock, and compensates for the increased noise by averaging over a larger
number of samples." [24]
In October 2005, Dag Arne Osvik, Adi Shamir and Eran Tromer presented a paper demonstrating several
cache-timing attacks against AES.[26] One attack was able to obtain an entire AES key after only 800 operations
triggering encryptions, in a total of 65 milliseconds. This attack requires the attacker to be able to run programs on the same system or platform that is performing AES.
In December 2009 an attack on some hardware implementations was published that used differential fault analysis
and allows recovery of key with complexity of .[27]
In November 2010 Endre Bangerter, David Gullasch and Stephan Krenn published a paper which described a practical approach to a "near real time" recovery of secret keys from AES-128 without the need for either cipher text or plaintext. The approach also works on AES-128 implementations that use compression tables, such as
OpenSSL.[28] Like some earlier attacks this one requires the ability to run arbitrary code on the system performing
the AES encryption. [29]
NIST/CSEC validation
The Cryptographic Module Validation Program (CMVP) is operated jointly by the United States Government's National Institute of Standards and Technology (NIST) Computer Security Division and the Communications Security Establishment (CSE) of the Government of Canada. The use of validated cryptographic modules is not required by the United States Government for unclassified uses of cryptography. The Government of Canada also recommends the use of FIPS 140 validated cryptographic modules in unclassified applications of its departments. Although NIST publication 197 ("FIPS 197") is the unique document that covers the AES algorithm, vendors typically approach the CMVP under FIPS 140 and ask to have several algorithms (such as Triple DES or SHA1) validated at the same time. Therefore, it is rare to find cryptographic modules that are uniquely FIPS 197 validated and NIST itself does not generally take the time to list FIPS 197 validated modules separately on its public web site. Instead, FIPS 197 validation is typically just listed as an "FIPS approved: AES" notation (with a specific FIPS 197 certificate number) in the current list of FIPS 140 validated cryptographic modules.
The Cryptographic Algorithm Validation Program (CAVP)[30] allows for independent validation of the correct implementation of the AES algorithm at a reasonable cost. Successful validation results in being listed on the NIST validations page. This testing is a pre-requisite for the FIPS 140-2 module validation described below.
FIPS 140-2 validation is challenging to achieve both technically and fiscally.[31] There is a standardized battery of
tests as well as an element of source code review that must be passed over a period of a few weeks. The cost to
perform these tests through an approved laboratory can be significant (e.g., well over $30,000 US)[31] and does not
include the time it takes to write, test, document and prepare a module for validation. After validation, modules must be re-submitted and re-evaluated if they are changed in any way. This can vary from simple paperwork updates if the security functionality did not change to a more substantial set of re-testing if the security functionality was impacted by the change.
Advanced Encryption Standard 8
Test vectors
Test vectors are a set of known ciphers for a given input and key. NIST distributes the reference of AES test vectors
as AES Known Answer Test (KAT) Vectors (in ZIP format) [32].
Performance
High speed and low RAM requirements were criteria of the AES selection process. Thus AES performs well on a wide variety of hardware, from 8-bit smart cards to high-performance computers.
On a Pentium Pro, AES encryption requires 18 clock cycles / byte,[33] equivalent to a throughput of about 11 MiB/s
for a 200 MHz processor. On a Pentium M 1.7 GHz throughput is about 60 MiB/s.
Notes
[1][1] Key sizes of 128, 160, 192, 224, and 256 bits are supported by the Rijndael algorithm, but only the 128, 192, and 256-bit key sizes are specified in the AES standard.
[2]
[2] Block sizes of 128, 160, 192, 224, and 256 bits are supported by the Rijndael algorithm, but only the 128-bit block size is specified in the AES standard.
[3] Westlund, Harold B. (2002). "NIST reports measurable success of Advanced Encryption Standard" (http://www.findarticles.com/p/ articles/mi_m0IKZ/is_3_107?pnum=2&opg=90984479). Journal of Research of the National Institute of Standards and Technology. . [4] John Schwartz (October 3, 2000). "U.S. Selects a New Encryption Technique" (http://www.nytimes.com/2000/10/03/business/
technology-us-selects-a-new-encryption-technique.html). New York Times. . [5] "'Rijndael' pronunciation" (http://rijndael.info/audio/rijndael_pronunciation.wav). .
[6] Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson, Tadayoshi Kohno, Mike Stay (May 2000). "The Twofish Team’s Final Comments on AES Selection" (http://www.schneier.com/paper-twofish-final.pdf). .
[7] "Efficient software implementation of AES on 32-bit platforms". (http://www.springerlink.com/index/UVX5NQGNN55VK199.pdf) Lecture Notes in Computer Science: 2523. 2003
[8] http://code.google.com/p/byte-oriented-aes
[9] Lynn Hathaway (June 2003). "National Policy on the Use of the Advanced Encryption Standard (AES) to Protect National Security Systems and National Security Information" (http://csrc.nist.gov/groups/ST/toolkit/documents/aes/CNSS15FS.pdf) (PDF). . Retrieved
2011-02-15.
[10] John Kelsey, Stefan Lucks, Bruce Schneier, Mike Stay, David Wagner, and Doug Whiting, Improved Cryptanalysis of Rijndael, Fast Software Encryption, 2000 pp213–230 (http://www.schneier.com/paper-rijndael.html)
[11] Ou, George (April 30, 2006). "Is encryption really crackable?" (http://www.webcitation.org/5rocpRxhN). Ziff-Davis. Archived from the original (http://www.zdnet.com/blog/ou/is-encryption-really-crackable/204) on August 7, 2010. . Retrieved August 7, 2010.
[12] "Sean Murphy" (http://www.isg.rhul.ac.uk/~sean/). University of London. . Retrieved 2008-11-02.
[13] Bruce Schneier. "AES News, Crypto-Gram Newsletter, September 15, 2002" (http://www.schneier.com/crypto-gram-0209.html). . Retrieved 2007-07-27.
[14] Niels Ferguson, Richard Schroeppel, Doug Whiting (2001). "A simple algebraic representation of Rijndael" (http://www.macfergus.com/ pub/rdalgeq.html) (PDF/PostScript). Proceedings of Selected Areas in Cryptography, 2001, Lecture Notes in Computer Science.
Springer-Verlag. pp. 103–111. . Retrieved 2006-10-06.
[15] Bruce Schneier, AES Announced (http://www.schneier.com/crypto-gram-0010.html), October 15, 2000
[16] Bruce Schneier (2009-07-01). "New Attack on AES" (http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html).
Schneier on Security, A blog covering security and security technology. . Retrieved 2010-03-11.
[17] Biryukov, Alex; Khovratovich, Dmitry (2009-12-04). "Related-key Cryptanalysis of the Full AES-192 and AES-256" (http://eprint.iacr. org/2009/317). . Retrieved 2010-03-11.
[18] Nikolić, Ivica (2009). "Distinguisher and Related-Key Attack on the Full AES-256". Advances in Cryptology - CRYPTO 2009. Springer Berlin / Heidelberg. pp. 231–249. doi:10.1007/978-3-642-03356-8_14. ISBN 978-3-642-03355-1.
[19] Bruce Schneier (2009-07-30). "Another New AES Attack" (http://www.schneier.com/blog/archives/2009/07/another_new_aes.html).
Schneier on Security, A blog covering security and security technology. . Retrieved 2010-03-11.
[20] Alex Biryukov; Orr Dunkelman; Nathan Keller; Dmitry Khovratovich; Adi Shamir (2009-08-19). "Key Recovery Attacks of Practical Complexity on AES Variants With Up To 10 Rounds" (http://eprint.iacr.org/2009/374). . Retrieved 2010-03-11.
[21] Henri Gilbert; Thomas Peyrin (2009-11-09). "Super-Sbox Cryptanalysis: Improved Attacks for AES-like permutations" (http://eprint.iacr. org/2009/531). . Retrieved 2010-03-11.
[22] Vincent Rijmen (2010). "Practical-Titled Attack on AES-128 Using Chosen-Text Relations" (http://eprint.iacr.org/2010/337.pdf). . [23] Andrey Bogdanov, Dmitry Khovratovich, and Christian Rechberger (2011). "Biclique Cryptanalysis of the Full AES" (http://research.
[24] "Index of formal scientific papers" (http://cr.yp.to/papers.html#cachetiming). Cr.yp.to. . Retrieved 2008-11-02.
[25] Bruce Schneier. "AES Timing Attack" (http://www.schneier.com/blog/archives/2005/05/aes_timing_atta_1.html). . Retrieved 2007-03-17.
[26] Dag Arne Osvik1; Adi Shamir2 and Eran Tromer2 (2005-11-20) (PDF). Cache Attacks and Countermeasures: the Case of AES (http:// www.wisdom.weizmann.ac.il/~tromer/papers/cache.pdf). . Retrieved 2008-11-02.
[27] Dhiman Saha, Debdeep Mukhopadhyay, Dipanwita RoyChowdhury (PDF). A Diagonal Fault Attack on the Advanced Encryption Standard
(http://eprint.iacr.org/2009/581.pdf). . Retrieved 2009-12-08.
[28] Endre Bangerter, David Gullasch and Stephan Krenn (2010). "Cache Games – Bringing Access-Based Cache Attacks on AES to Practice" (http://eprint.iacr.org/2010/594.pdf). .
[29] http://news.ycombinator.com/item?id=1937902 [30] http://csrc.nist.gov/groups/STM/cavp/index.html
[31] OpenSSL's Notes about FIPS certification (http://openssl.org/docs/fips/fipsnotes.html) [32] http://csrc.nist.gov/groups/STM/cavp/documents/aes/KAT_AES.zip
[33] "Performance Comparisons of the AES submissions" (http://www.schneier.com/paper-aes-performance.pdf) (PDF). 1999-02-01. . Retrieved 2010-12-28.
References
• Nicolas Courtois, Josef Pieprzyk, "Cryptanalysis of Block Ciphers with Overdefined Systems of Equations".
pp267–287, ASIACRYPT 2002.
•• Joan Daemen, Vincent Rijmen, "The Design of Rijndael: AES - The Advanced Encryption Standard." Springer, 2002. ISBN 3-540-42580-2.
• Christof Paar, Jan Pelzl, "The Advanced Encryption Standard" (http://wiki.crypto.rub.de/Buch/
sample_chapters.php), Chapter 4 of "Understanding Cryptography, A Textbook for Students and Practitioners".
(companion web site contains online lectures on AES), Springer, 2009.
External links
• Reference implementation and derived code (http://embeddedsw.net/Cipher_Reference_Home.html)
• FIPS PUB 197: the official AES standard (http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf) (PDF
file)
• AES algorithm archive information - (old, unmaintained) (http://csrc.nist.gov/archive/aes/rijndael/wsdindex.
html)
• Animation of the AES encryption process (http://www.formaestudio.com/rijndaelinspector/)
• Fully Functional Animation of the AES encryption process and key expansion (128 bits) - based on the work of
Enrique Zabala (previous link) (http://blog.ultrassecreto.com/wp-content/uploads/2009/06/projetofinal.
html)
• Stick Figure Guide to AES (http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html), a
layman introduction to cryptography and AES.
• AES encryption is cracked (http://www.theinquirer.net/inquirer/news/2102435/aes-encryption-cracked/)
• An in-depth description of the Advanced Encryption Standard and the maths behind it. C implementation
provided. (http://www.x-n2o.com/aes-explained/)
• Accelerating AES in software by using custom instructions (http://www.ensilica.com/pdfs/
A_study_of_aes_and_its_efficient_implementation_on_eSi_RISC_r1.0.pdf) (PDF file)
Block cipher 10
Block cipher
In cryptography, a block cipher is a symmetric key cipher operating on fixed-length groups of bits, called blocks,
with an unvarying transformation. A block cipher encryption algorithm might take (for example) a 128-bit block of plaintext as input, and output a corresponding 128-bit block of ciphertext. The exact transformation is controlled
using a second input — the secret key. Decryption is similar: the decryption algorithm takes, in this example, a
128-bit block of ciphertext together with the secret key, and yields the original 128-bit block of plain text.
A message longer than the block size (128 bits in the above example) can still be encrypted with a block cipher by breaking the message into blocks and encrypting each block individually. However, in this method all blocks are encrypted with the same key, which degrades security (because each repetition in the plaintext becomes a repetition in the ciphertext). To overcome this issue, modes of operation are used to make encryption probabilistic. Some modes of operation, despite the fact that their underlying implementation is a block cipher, allow the encryption of individual bits. The resulting cipher is called a stream cipher.
An early and highly influential block cipher design was the Data Encryption Standard (DES), developed at IBM and published as a standard in 1977. A successor to DES, the Advanced Encryption Standard (AES), was adopted in 2001.
Generalities
A block cipher consists of two paired algorithms, one for encryption, E, and the other for decryption, E−1. Both
algorithms accept two inputs: an input block of size n bits and a key of size k bits, yielding an n-bit output block. For
any one fixed key, decryption is the inverse function of encryption, so that
for any block M and key K. M is termed the plaintext and C the ciphertext.
For each key K, EK is a permutation (a bijective mapping) over the set of input blocks. Each key selects one
permutation from the possible set of .
The block size, n, is typically 64 or 128 bits, although some ciphers have a variable block size. 64 bits was the most
common length until the mid-1990s, when new designs began to switch to the longer 128-bit length. One of several modes of operation is generally used along with a padding scheme to allow plaintexts of arbitrary lengths to be encrypted. Each mode has different characteristics in regard to error propagation, ease of random access and
vulnerability to certain types of attack. Typical key sizes (k) include 40,[1] 56,[1] 64, 80, 128,[1] 192 and 256, 512,
1024, 2048, 4096 bits. As of 2011, 128 bits is normally taken as the minimum key length needed to prevent brute force attacks. For creating ciphers with arbitrary block sizes (or on domains that aren't powers of two) see Format-preserving encryption.
Iterated block ciphers
Most block ciphers are constructed by repeatedly applying a simpler function. This approach is known as iterated
block cipher (see also product cipher). Each iteration is termed a round, and the repeated function is termed the
round function; anywhere between 4 to 32 rounds are typical.
Usually, the round function R takes different round keys Ki as second input, which are derived from the original key:
where is the plaintext and the ciphertext, with r being the round number.
Frequently, key whitening is used in addition to this. At the beginning and the end, the data is modified with key material (often with XOR, but simple arithmetic operations like adding and subtracting are also used):
Many block ciphers can be categorised as Feistel networks, or, as more general substitution-permutation networks. Arithmetic operations, logical operations (especially XOR), S-boxes and various permutations are all frequently used as components.
History
Lucifer is generally considered to be the first civilian block cipher, developed at IBM in the 1970s based on work done by Horst Feistel. A revised version of the algorithm was adopted as a US government FIPS standard, the DES. It was chosen by the US National Bureau of Standards (NBS) after a public invitation for submissions and some internal changes by NBS (and, potentially, the NSA). DES was publicly released in 1976 and has been widely used. DES was designed to, among other things, resist a certain cryptanalytic attack known to the NSA and rediscovered by IBM, though unknown publicly until rediscovered again and published by Eli Biham and Adi Shamir in the late 1980s. The technique is called differential cryptanalysis and remains one of the few general attacks against block ciphers; linear cryptanalysis is another, but may have been unknown even to the NSA, prior to its publication by Mitsuru Matsui. DES prompted a large amount of other work and publications in cryptography and cryptanalysis in the open community and it inspired many new cipher designs.
DES has a block size of 64 bits and a key size of 56 bits. 64-bit blocks became common in block cipher designs after DES. Key length depended on several factors, including government regulation. Many observers in the 1970s commented that the 56-bit key length used for DES was too short. As time went on, its inadequacy became apparent, especially after a special purpose machine designed to break DES was demonstrated in 1998 by the Electronic Frontier Foundation. A variant of DES, Triple DES, triple-encrypts blocks with either two different keys (2 key TDES, resulting in a 112-bit keys and 80-bit security) or three keys (3 key TDES, resulting in a 168-bit key and 112-bit security). It was widely adopted as a replacement. As of 2011, the three-key version is still considered secure, though National Institute of Standards and Technology(NIST) standards no longer permit the use of the two-key version in new applications, due to its 80 bit security level.
DES has been superseded as a United States Federal Standard by the AES, adopted by National Institute of Standards and Technology (NIST) in 2001 after a 5-year public competition. The cipher was developed by two
Belgian cryptographers, Joan Daemen and Vincent Rijmen, and submitted under the name Rijndael. AES has a block
size of 128 bits and three possible key sizes, 128, 192 and 256 bits. The US Government permits the use of AES to protect classified information in systems approved by NSA.
Cryptanalysis
In addition to linear and differential cryptanalysis, there is a growing catalog of attacks: truncated differential cryptanalysis, partial differential cryptanalysis, integral cryptanalysis, which encompasses square and integral attacks, slide attacks, boomerang attacks, the XSL attack, impossible differential cryptanalysis and algebraic attacks. For a new block cipher design to have any credibility, it must demonstrate evidence of security against known attacks.
Tweakable block ciphers
M. Liskov, R. Rivest, and D. Wagner have described a generalized version of block ciphers called "tweakable" block
ciphers. A tweakable block cipher accepts a second input called the tweak along with its usual plaintext or ciphertext
input. The tweak, along with the key, selects the permutation computed by the cipher. If changing tweaks is sufficiently lightweight (compared with a usually fairly expensive key setup operation), then some interesting new operation modes become possible. The disk encryption theory article describes some of these modes.
Block cipher 12
Block ciphers and other cryptographic primitives
Block ciphers can be used to build other cryptographic primitives. For these other primitives to be cryptographically secure care has to be taken to build them the right way.
Stream ciphers can be built using block ciphers. OFB-mode and CTR mode are block modes that turn a block cipher into a stream cipher.
Cryptographic hash functions can be built using block ciphers. See one-way compression function for descriptions of several such methods. The methods resemble the block cipher modes of operation usually used for encryption. Just as block ciphers can be used to build hash functions, hash functions can be used to build block ciphers. Examples of such block ciphers are SHACAL, BEAR and LION.
Cryptographically secure pseudorandom number generators (CSPRNGs) can be built using block ciphers.
Secure pseudorandom permutations of arbitrarily sized finite sets can be constructed with block ciphers; see Format-Preserving Encryption.
Message authentication codes (MACs) are often built from block ciphers. CBC-MAC, OMAC and PMAC are such MACs.
Authenticated encryption is also built from block ciphers. It means to both encrypt and MAC at the same time. That is to both provide confidentiality and authentication. CCM, EAX, GCM and OCB are such authenticated encryption modes.
References
[1] Blaze, Matt; Diffie, Whitefield; Rivest, Ronald L.; Schneier, Bruce; Shimomura, Tsutomu; Thompson, Eric; Wiener, Michael (January 1996). "Minimal key lengths for symmetric ciphers to provide adequate commercial security" (http://www.fortify.net/related/cryptographers. html). Fortify. . Retrieved 14 October 2011.
• M. Liskov, R. Rivest, and D. Wagner, "Tweakable Block Ciphers", Crypto 2002 PDF (http://www.cs.colorado.
edu/~jrblack/class/csci7000/f03/papers/tweak-crypto02.pdf).
External links
• A list of many symmetric algorithms, the majority of which are block ciphers. (http://www.users.zetnet.co.uk/
hopwood/crypto/scan/cs.html)
• The block cipher lounge (http://www.mat.dtu.dk/people/Lars.R.Knudsen/bc.html)
Block cipher modes of operation
In cryptography, modes of operation is the procedure of enabling the repeated and secure use of a block cipher
under a single key.[1][2] A block cipher by itself allows encryption only of a single data block of the cipher's block
length. When targeting a variable-length message, the data must first be partitioned into separate cipher blocks. Typically, the last block must also be extended to match the cipher's block length using a suitable padding scheme. A mode of operation describes the process of encrypting each of these blocks, and generally uses randomization based
on an additional input value, often called an initialization vector, to allow doing so safely.[1]
Modes of operation have primarily been defined for encryption and authentication.[1][3] Historically, encryption
modes have been studied extensively in regard to their error propagation properties under various scenarios of data modification. Later development regarded integrity protection as an entirely separate cryptographic goal from encryption. Some modern modes of operation combine encryption and authentication in an efficient way, and are
known as authenticated encryption modes.[2]
While modes of operation are commonly associated with symmetric encryption,[2] they may also be applied to
public-key encryption primitives such as RSA in principle (though in practice public-key encryption of longer
messages is generally realized using hybrid encryption).[1]
History and standardization
The earliest modes of operation, ECB, CBC, OFB, and CFB (see below for all), date back to 1981 and were
specified in FIPS 81 [4], DES Modes of Operation. In 2001, NIST revised its list of approved modes of operation by
including AES as a block cipher and adding CTR mode in SP800-38A [5], Recommendation for Block Cipher Modes
of Operation. Finally, in January, 2010, NIST added XTS-AES in SP800-38E [6], Recommendation for Block Cipher
Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. Other confidentiality modes exist
which have not been approved by NIST. For example, CTS is ciphertext stealing mode and available in many popular cryptographic libraries.
ECB, CBC, OFB, CFB, CTR, and XTS modes only provide confidentiality; to ensure an encrypted message is not accidentally modified or maliciously tampered requires a separate message authentication code such as CBC-MAC. The cryptographic community recognized the need for dedicated integrity assurances and NIST responded with
HMAC, CMAC, and GMAC. HMAC was approved in 2002 as FIPS 198 [7], The Keyed-Hash Message
Authentication Code (HMAC), CMAC was released in 2005 under SP800-38B [8], Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Authentication, and GMAC was formalized in 2007 under
SP800-38D [9], Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
After observing that compositing a confidentiality mode with an authenticity mode could be difficult and error prone, the cryptographic community began to supply modes which combined confidentiality and data integrity into a single cryptographic primitive. The modes are referred to as authenticated encryption, AE or authenc. Examples of authenc
modes are CCM (SP800-38C [10]), GCM (SP800-38D [9]), CWC, EAX, IAPM, and OCB.
Modes of operation are nowadays defined by a number of national and internationally recognized standards bodies. The most influential source is the US NIST. Other notable standards organizations include the ISO, the IEC, the IEEE, the national ANSI, and the IETF.
Block cipher modes of operation 14
Initialization vector (IV)
An initialization vector (IV) is a block of bits that is used by several modes to randomize the encryption and hence to produce distinct ciphertexts even if the same plaintext is encrypted multiple times, without the need for a slower re-keying process.
An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages. For OFB and CTR, reusing an IV completely destroys security. In CBC mode, the IV must, in addition, be unpredictable at encryption time; in particular, the (previously) common practice of re-using the last ciphertext block of a message as the IV for the next message is insecure (for example, this method was used by SSL 2.0). If an attacker knows the IV (or the previous block of ciphertext) before he specifies the next plaintext, he can check his guess about plaintext of some block that was encrypted with the same key before (this is known as the TLS
CBC IV attack).[11]
As a special case, if the plaintexts are always small enough to fit into a single block (with no padding), then with
some modes (ECB, CBC, PCBC), re-using an IV will leak only whether two plaintexts are equal. This can be useful
in cases where one wishes to be able to test for equality without decrypting or separately storing a hash.
Padding
A block cipher works on units of a fixed size (known as a block size), but messages come in a variety of lengths. So
some modes (namely ECB and CBC) require that the final block be padded before encryption. Several padding schemes exist. The simplest is to add null bytes to the plaintext to bring its length up to a multiple of the block size, but care must be taken that the original length of the plaintext can be recovered; this is so, for example, if the plaintext is a C style string which contains no null bytes except at the end. Slightly more complex is the original DES method, which is to add a single one bit, followed by enough zero bits to fill out the block; if the message ends on a block boundary, a whole padding block will be added. Most sophisticated are CBC-specific schemes such as ciphertext stealing or residual block termination, which do not cause any extra ciphertext, at the expense of some additional complexity. Schneier and Ferguson suggest two possibilities, both simple: append a byte with value 128
(hex 80), followed by as many zero bytes as needed to fill the last block, or pad the last block with n bytes all with
value n.
CFB, OFB and CTR modes do not require any special measures to handle messages whose lengths are not multiples of the block size, since the modes work by XORing the plaintext with the output of the block cipher. The last partial block of plaintext is XORed with the first few bytes of the last keystream block, producing a final ciphertext block that is the same size as the final partial plaintext block. This characteristic of stream ciphers makes them suitable for applications that require the encrypted ciphertext data to be the same size as the original plaintext data, and for applications that transmit data in streaming form where it is inconvenient to add padding bytes.
Electronic codebook (ECB)
The simplest of the encryption modes is the electronic codebook (ECB) mode. The message is divided into blocks
and each block is encrypted separately.
The disadvantage of this method is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus, it does not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all. A striking example of the degree to which ECB can leave plaintext data patterns in the ciphertext is shown below; a pixel-map version of the image on the left was encrypted with ECB mode to create the center image, versus a non-ECB mode for the right image.
Original Encrypted using ECB mode Modes other than ECB result in pseudo-randomness
The image on the right is how the image might appear encrypted with CBC, CTR or any of the other more secure
Block cipher modes of operation 16 ensure that the image has been securely encrypted; many kinds of insecure encryption have been developed which would produce output just as 'random-looking'.
ECB mode can also make protocols without integrity protection even more susceptible to replay attacks, since each
block gets decrypted in exactly the same way. For example, the Phantasy Star Online: Blue Burst online video game
uses Blowfish in ECB mode. Before the key exchange system was cracked leading to even easier methods, cheaters repeated encrypted "monster killed" message packets, each an encrypted Blowfish block, to illegitimately gain experience points quickly.
Cipher-block chaining (CBC)
Cipher-block chaining (CBC) mode of operation was invented by IBM in 1976.[12] In CBC mode, each block of
plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block is dependent on all plaintext blocks processed up to that point. Also, to make each message unique, an initialization vector must be used in the first block.
If the first block has index 1, the mathematical formula for CBC encryption is
while the mathematical formula for CBC decryption is
CBC has been the most commonly used mode of operation. Its main drawbacks are that encryption is sequential (i.e., it cannot be parallelized), and that the message must be padded to a multiple of the cipher block size. One way to handle this last issue is through the method known as ciphertext stealing. Note that a one-bit change in a plaintext or IV affects all following ciphertext blocks.
Decrypting with the incorrect IV causes the first block of plaintext to be corrupt but subsequent plaintext blocks will be correct. This is because a plaintext block can be recovered from two adjacent blocks of ciphertext. As a
consequence, decryption can be parallelized. Note that a one-bit change to the ciphertext causes complete corruption
of the corresponding block of plaintext, and inverts the corresponding bit in the following block of plaintext, but the rest of the blocks remain intact.
Propagating cipher-block chaining (PCBC)
The propagating cipher-block chaining [13] or plaintext cipher-block chaining[14] mode was designed to cause small
changes in the ciphertext to propagate indefinitely when decrypting, as well as when encrypting.
Encryption and decryption algorithms are as follows:
PCBC is used in Kerberos v4 and WASTE, most notably, but otherwise is not common. On a message encrypted in PCBC mode, if two adjacent ciphertext blocks are exchanged, this does not affect the decryption of subsequent
Block cipher modes of operation 18
Cipher feedback (CFB)
The cipher feedback (CFB) mode, a close relative of CBC, makes a block cipher into a self-synchronizing stream
cipher. Operation is very similar; in particular, CFB decryption is almost identical to CBC encryption performed in reverse:
This simplest way of using CFB described above is not any more self-synchronizing than other cipher modes like CBC. If a whole blocksize of ciphertext is lost both CBC and CFB will synchronize, but losing only a single byte or bit will permanently throw off decryption. To be able to synchronize after the loss of only a single byte or bit, a single byte or bit must be encrypted at a time. CFB can be used this way when combined with a shift register as the input for the block cipher.
To use CFB to make a self-synchronizing stream cipher that will synchronize for any multiple of x bits lost, start by initializing a shift register the size of the block size with the initialization vector. This is encrypted with the block cipher, and the highest x bits of the result are XOR'ed with x bits of the plaintext to produce x bits of ciphertext. These x bits of output are shifted into the shift register, and the process repeats with the next x bits of plaintext. Decryption is similar, start with the initialization vector, encrypt, and XOR the high bits of the result with x bits of
the ciphertext to produce x bits of plaintext. Then shift the x bits of the ciphertext into the shift register. This way of
proceeding is known as CFB-8 or CFB-1 (according to the size of the shifting).[16]
In notation, where Si is the ith state of the shift register, a << x is a shifted up x bits, head(a, x) is the x highest bits of
a and n is number of bits of IV:
If x bits are lost from the ciphertext, the cipher will output incorrect plaintext until the shift register once again equals a state it held while encrypting, at which point the cipher has resynchronized. This will result in at most one blocksize of output being garbled.
Like CBC mode, changes in the plaintext propagate forever in the ciphertext, and encryption cannot be parallelized. Also like CBC, decryption can be parallelized. When decrypting, a one-bit change in the ciphertext affects two plaintext blocks: a one-bit change in the corresponding plaintext block, and complete corruption of the following plaintext block. Later plaintext blocks are decrypted normally.
CFB shares two advantages over CBC mode with the stream cipher modes OFB and CTR: the block cipher is only ever used in the encrypting direction, and the message does not need to be padded to a multiple of the cipher block size (though ciphertext stealing can also be used to make padding unnecessary).
Output feedback (OFB)
The output feedback (OFB) mode makes a block cipher into a synchronous stream cipher. It generates keystream
blocks, which are then XORed with the plaintext blocks to get the ciphertext. Just as with other stream ciphers, flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location. This property allows many error correcting codes to function normally even when applied before encryption.
Block cipher modes of operation 20
Each output feedback block cipher operation depends on all previous ones, and so cannot be performed in parallel. However, because the plaintext or ciphertext is only used for the final XOR, the block cipher operations may be performed in advance, allowing the final step to be performed in parallel once the plaintext or ciphertext is available. It is possible to obtain an OFB mode keystream by using CBC mode with a constant string of zeroes as input. This can be useful, because it allows the usage of fast hardware implementations of CBC mode for OFB mode encryption. Using OFB mode with a partial block as feedback like CFB mode reduces the average cycle length by a factor of or more. A mathematical model proposed by Davies and Parkin and substantiated by experimental results showed that only with full feedback an average cycle length near to the obtainable maximum can be achieved. For
Counter (CTR)
Note: CTR mode (CM) is also known as integer counter mode (ICM) and segmented integer counter (SIC)
mode
Like OFB, counter mode turns a block cipher into a stream cipher. It generates the next keystream block by encrypting successive values of a "counter". The counter can be any function which produces a sequence which is guaranteed not to repeat for a long time, although an actual counter is the simplest and most popular. The usage of a simple deterministic input function used to be controversial; critics argued that "deliberately exposing a
cryptosystem to a known systematic input represents an unnecessary risk."[19] By now, CTR mode is widely
accepted, and problems resulting from the input function are recognized as a weakness of the underlying block
cipher instead of the CTR mode.[20] Nevertheless, there are specialized attacks like a Hardware Fault Attack that is
based on the usage of a simple counter function as input.[21]
CTR mode has similar characteristics to OFB, but also allows a random access property during decryption. CTR mode is well suited to operation on a multi-processor machine where blocks can be encrypted in parallel.
Furthermore, it does not suffer from the short-cycle problem that can affect OFB.[22]
Note that the nonce in this graph is the same thing as the initialization vector (IV) in the other graphs. The IV/nonce and the counter can be combined together using any lossless operation (concatenation, addition, or XOR) to produce the actual unique counter block for encryption.
Block cipher modes of operation 22
Error propagation
Before the widespread use of message authentication codes and authenticated encryption, it was common to discuss the "error propagation" properties as a selection criterion for a mode of operation. It might be observed, for example, that a one-block error in the transmitted ciphertext would result in a one-block error in the reconstructed plaintext for ECB mode encryption, while in CBC mode such an error would affect two blocks.
Some felt that such resilience was desirable in the face of random errors (e.g., line noise), while others argued that error correcting increased the scope for attackers to maliciously tamper with a message.
However, when proper integrity protection is used, such an error will result (with high probability) in the entire message being rejected. If resistance to random error is desirable, error-correcting codes should be applied to the ciphertext before transmission.
Authenticated encryption
A number of modes of operation have been designed to combine confidentiality and authentication in a single
cryptographic primitive. Examples of such modes are XCBC,[23] IACBC, IAPM,[24] OCB, EAX, CWC, CCM, and
GCM. Authenticated encryption modes are classified as single pass modes or double pass modes. Unfortunately for the cryptographic user community, many of the single pass authenticated encryption algorithms (such as OCB mode) are patent encumbered.
In addition, some modes also allow for the authentication of unencrypted associated data, and these are called AEAD (Authenticated-Encryption with Associated-Data) schemes. For example, EAX mode is a double pass AEAD scheme while OCB mode is single pass.
Other modes and other cryptographic primitives
Many more modes of operation for block ciphers have been suggested. Some have been accepted, fully described (even standardized), and are in use. Others have been found insecure, and should never be used. Still others don't categorize as confidentiality, authenticity, or authenticated encryption - for example Key Feedback Mode (KFM) and AES-hash.
NIST maintains a list of proposed modes for block ciphers at Modes Development [25].[26][16]
Disk encryption often uses special purpose modes specifically designed for the application. Tweakable narrow-block encryption modes (LRW, XEX, and XTS) and wide-block encryption modes (CMC and EME) are designed to securely encrypt sectors of a disk. (See disk encryption theory)
Block ciphers can also be used in other cryptographic protocols. They are generally used in modes of operation similar to the block modes described here. As with all protocols, to be cryptographically secure, care must be taken to build them correctly.
There are several schemes which use a block cipher to build a cryptographic hash function. See one-way compression function for descriptions of several such methods.
Cryptographically secure pseudorandom number generators (CSPRNGs) can also be built using block ciphers. Message authentication codes (MACs) are often built from block ciphers. CBC-MAC, OMAC and PMAC are examples.
Authenticated encryption also uses block ciphers as components. It means to both encrypt and MAC at the same time. That is to both provide confidentiality and authentication. IAPM, CCM, CWC, EAX, GCM and OCB are such authenticated encryption modes.
References
[1] Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone (1996). Handbook of Applied Cryptography (http://www.cacr.math. uwaterloo.ca/hac/). CRC Press. ISBN 0-8493-8523-7. .
[2] "Block Cipher Modes" (http://csrc.nist.gov/groups/ST/toolkit/BCM/index.html). NIST Computer Security Resource Center. . [3] "FIPS 81: DES Modes of Operation" (http://www.itl.nist.gov/fipspubs/fip81.htm). NIST Computer Security Resource Center. . [4] http://www.itl.nist.gov/fipspubs/fip81.htm
[5] http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf [6] http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf [7] http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf
[8] http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf [9] http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
[10] http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf
[11] B. Moeller (May 20, 2004), Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures (http://www.openssl.org/~bodo/ tls-cbc.txt),
[12]
[12] William F. Ehrsam, Carl H. W. Meyer, John L. Smith, Walter L. Tuchman, "Message verification and transmission error detection by block chaining", US Patent 4074066, 1976
[13] http://www.iks-jena.de/mitarb/lutz/security/cryptfaq/q84.html
[14] Kaufman, C., Perlman, R., & Speciner, M (2002). Network Security. Upper Saddle River, NJ: Prentice Hall. Page 319 (2nd Ed.) [15] Kohl, J. "The Use of Encryption in Kerberos for Network Authentication", Proceedings, Crypto '89, 1989; published by Springer-Verlag;
http://dsns.csie.nctu.edu.tw/research/crypto/HTML/PDF/C89/35.PDF
[16] NIST: Recommendation for Block Cipher Modes of Operation (http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf) [17] D. W. Davies and G. I. P. Parkin. The average cycle size of the key stream in output feedback encipherment. In Advances in Cryptology,
Proceedings of CRYPTO 82, pages 263–282, 1982 [18] http://www.crypto.rub.de/its_seminar_ws0809.html
[19] Robert R. Jueneman. Analysis of certain aspects of output feedback mode. In Advances in Cryptology, Proceedings of CRYPTO 82, pages 99–127, 1982.
[20]
[20] Helger Lipmaa, Phillip Rogaway, and David Wagner. Comments to NIST concerning AES modes of operation: CTR-mode encryption. 2000 [21] R. Tirtea and G. Deconinck. Specifications overview for counter mode of operation. security aspects in case of faults. In Electrotechnical
Conference, 2004. MELECON 2004. Proceedings of the 12th IEEE Mediterranean, pages 769–773 Vol.2, 2004. [22] http://www.quadibloc.com/crypto/co040601.htm
[23]
[23] Virgil D. Gligor, Pompiliu Donescu, "Fast Encryption and Authentication: XCBC Encryption and XECB Authentication Modes". Proc. Fast Software Encryption, 2001: 92-108.
[24]
[24] Charanjit S. Jutla, "Encryption Modes with Almost Free Message Integrity", Proc. Eurocrypt 2001, LNCS 2045, May 2001. [25] http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
Certificate authority 24
Certificate authority
In cryptography, a certificate authority, or certification authority, (CA) is an entity that issues digital certificates.
The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate. CAs are characteristic of many public key infrastructure (PKI) schemes.
Commercial CAs charge to issue certificates that will automatically be trusted by most web browsers (Mozilla maintains a list of at least 36 trusted root CAs, though multiple commercial CAs or their resellers may share the
same trusted root).[1] The number of web browsers and other devices and applications that trust a particular
certificate authority is referred to as ubiquity.
Aside from commercial CAs, some providers issue digital certificates to the public at no cost. Large institutions or government entities may have their own CAs.
Domain Validation
The commercial CAs that issue the bulk of certificates that clients trust for email servers and public HTTPS servers typically use a technique called "domain validation" to authenticate the recipient of the certificate. Domain validation involves sending an email containing an authentication token or link, to an email address that is known to be administratively responsible for the domain. This could be the technical contact email address listed in the domain's WHOIS entry, or an administrative email like postmaster@ or root@ the domain. The theory behind domain validation is that only the legitimate owner of a domain would be able to read emails sent to these administrative addresses.
Domain validation suffers from certain structural security limitations. In particular, it is always vulnerable to attacks that allow an adversary to observe the domain validation emails that CAs send. These can include attacks against the DNS, TCP, or BGP protocols (which lack the cryptographic protections of TLS/SSL), or the compromise of routers. Such attacks are possible either on the network near a CA, or near the victim domain itself.
Some Certificate Authorities offer Extended Validation (EV) certificates as a more rigorous alternative to domain validated certificates. One limitation of EV as solution to the weaknesses of domain validation is that attackers could still obtain a domain validated certificate for the victim domain, and deploy it during an attack; if that occurred, the only difference observable to the victim user would be a blue HTTPS address bar rather than a green one. Few users would be likely to recognise this difference as indicative of an attack being in progress.
Domain validation implementations have also sometimes been a source of security vulnerabilities. In one instance,
security researchers showed that attackers could obtain certificates for webmail sites because a CA was willing to
use an email address like [email protected] for domain.com, but not all webmail systems had
reserved the "SSLCertificates" username to prevent attackers from registering it [2].
Issuing a certificate
A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the CA's certificates. CAs use a variety of standards and tests to do so. In essence, the Certificate Authority is responsible for saying "yes, this person is who they say they are, and we, the CA, verify that".
If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain public key does indeed belong to whoever is identified in the certificate.
Example
Public-key cryptography can be used to encrypt data communicated between two parties. This can typically happen when a user logs on to any site that implements the HTTP Secure protocol. In this example let us suppose that the user logs on to his bank's homepage www.bank.example to do online banking. When the user opens www.bank.example homepage, he receives a public key along with all the data that his web-browser displays. When the user enters some information to the bank's page and submits the page (sends the information back to the bank) then the data the user has entered to the page will be encrypted by his web browser using the public key that was issued by www.bank.example. The key that can be used to decrypt the information is called the private key and it is only known to the bank. Therefore, even if someone can access the (encrypted) data that was communicated from the user to www.bank.example, the (unencrypted) data that the user has entered can only be decrypted by the bank, as only the bank knows the private key.
This mechanism is only safe if the user can be sure that it is the bank that he sees in his web browser. If the user types in www.bank.example, but his communication is hi-jacked and a fake web-site (that pretends to be the bank web-site) sends the page information back to the user's browser, the fake web-page can send a fake public key to the user. The user will fill the form with his personal data and will submit the page which will be encrypted by the fake public key. The fake web-page will get access to the user's data since the fake web-page owns the fake private key. A certificate authority is an organization that stores public keys and their owners and every party in a communication trusts this organization. When the user's web browser receives the public key from www.bank.example it can contact the certificate authority to ask whether the public key does really belong to www.bank.example. Since www.bank.example uses a public key that the certification authority certifies, a fake www.bank.example can only use the same public key. Since the fake www.bank.example does not know the corresponding private key, it cannot decrypt the user's answer.
Subversion of CA
If the CA can be subverted, then the security of the entire system is lost for each user for whom the CA is attesting a link between a public key and an identity.
For example, suppose an attacker, Eve, manages to get a CA to issue to her a certificate that claims to represent Alice. That is, the certificate would publicly state that it represents Alice, and might include other information about Alice. Some of the information about Alice, such as her employer name, might be true, increasing the certificate's credibility. Eve, however, would have the all-important private key associated with the certificate. Eve could then use the certificate to send digitally signed email to Bob, tricking Bob into believing that the email was from Alice. Bob might even respond with encrypted email, believing that it could only be read by Alice, when Eve is actually able to decrypt it using the private key.
A notable case of CA subversion like this occurred in 2001, when the certificate authority VeriSign issued two certificates to a person claiming to represent Microsoft. The certificates have the name "Microsoft Corporation", so could be used to spoof someone into believing that updates to Microsoft software came from Microsoft when they actually did not. The fraud was detected in early 2001. Microsoft and VeriSign took steps to limit the impact of the
problem.[3][4]
In 2011 fraudulent certificates were obtained from Comodo and DigiNotar[5][6], allegedly by Iranian hackers. There
Certificate authority 26
Security
The problem of assuring correctness of match between data and entity when the data are presented to the CA (perhaps over an electronic network), and when the credentials of the person/company/program asking for a certificate are likewise presented, is difficult. This is why commercial CAs often use a combination of authentication techniques including leveraging government bureaus, the payment infrastructure, third parties' databases and services, and custom heuristics. In some enterprise systems, local forms of authentication such as Kerberos can be used to obtain a certificate which can in turn be used by external relying parties. Notaries are required in some cases to personally know the party whose signature is being notarized; this is a higher standard than is reached by many
CAs. According to the American Bar Association outline on Online Transaction Management [8], the primary points
of US Federal and State statutes enacted regarding digital signatures has been to "prevent conflicting and overly burdensome local regulation and to establish that electronic writings satisfy the traditional requirements associated with paper documents." Further the US E-Sign statute and the suggested UETA code help ensure that:
1.
1. a signature, contract or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form; and
2.
2. a contract relating to such transaction may not be denied legal effect, validity or enforceability solely because an electronic signature or electronic record was used in its formation.
In large-scale deployments, Alice may not be familiar with Bob's certificate authority (perhaps they each have a
different CA server), so Bob's certificate may also include his CA's public key signed by a different CA2, which is
presumably recognizable by Alice. This process typically leads to a hierarchy or mesh of CAs and CA certificates.
Providers
Worldwide, the certificate authority business is fragmented, with national or regional providers dominating their home market. This is because many uses of digital certificates, such as for legally binding digital signatures, are linked to local law, regulations, and accreditation schemes for certificate authorities.
However, the market for SSL certificates, a kind of certificate used for website security, is largely held by a small number of multinational companies. This market has significant barriers to entry since new providers must undergo
annual security audits (such as WebTrust [9] for Certification Authorities) to be included in the list of web browser
trusted authorities. More than 50 root certificates are trusted in the most popular web browser versions. A 2009
market share report from Net Craft [10] as of January of that year determined that VeriSign and its acquisitions
(which include Thawte and Geotrust) have a 47.5% share of the certification services provider market, followed by GoDaddy (23.4%), and Comodo (15.44%).
Open source implementations
There exist several open source implementations of certificate authority software. Common to all is that they provide the necessary services to issue, revoke and manage digital certificates.
Some well known open source implementations are: •• EJBCA
•• OpenCA
• OpenSSL, which is really an SSL/TLS library, but comes with tools allowing its use as a simple certificate authority.
•• gnoMint
• DogTag [11]
