Security Articles from Wikipedia

Transcription

Security Articles from
Wikipedia
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
Contents
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
Image Sources, Licenses and Contributors
179
Article Licenses
License
180
1
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
[1]
128, 192 or 256 bits
Block sizes
128 bits
Structure
Substitution-permutation network
Rounds
10, 12 or 14 (depending on key size)
[2]
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
Rijmen, and submitted by them to the AES selection process.[4] The name Rijndael (Dutch pronunciation: [ˈrɛindaːl][5])
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. Initial Round
1. AddRoundKey—each byte of the state is combined with the round key using bitwise xor
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. AddRoundKey
4. Final Round (no MixColumns)
1. SubBytes
2. ShiftRows
3. AddRoundKey
2
The SubBytes step
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
In the SubBytes step, each byte in the state is replaced with its entry in a fixed 8-bit
invertible affine transformation. The
lookup table, S; bij = S(aij).
S-box is also chosen to avoid any fixed
points (and so is a derangement), and also any opposite fixed points.
The ShiftRows step
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.
In the ShiftRows step, bytes in each row of the state are shifted cyclically to the left.
For the block of size 128 bits and 192
The number of places each byte is shifted differs for each row.
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
Rijndael cipher when used with a 256-bit block, as AES does not use 256-bit blocks.
3
4
The MixColumns step
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
In the MixColumns step, each column of the state is multiplied with a fixed
polynomial c(x).
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, 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,
In the AddRoundKey step, each byte of the state is combined with a byte of the round
and transforming them into a sequence
subkey using the XOR operation (⊕).
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
known attacks were on 7 rounds for 128-bit keys, 8 rounds for 192-bit keys, and 9 rounds for 256-bit keys.[10]
5
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
timestamps, or eliminating them from the server’s responses, does not stop the attack: the client simply uses
6
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.
7
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] 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] 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.
microsoft. com/ en-us/ projects/ cryptanalysis/ aesbc. pdf). .
8
[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. .
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)
• AES VHDL implementation (pipelined and iterative) (http://www.isaakian.com/VHDL_page.html)
9
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):
Block cipher
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.
11
Block cipher
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)
• What is a block cipher? (http://www.rsa.com/rsalabs/node.asp?id=2168) from RSA FAQ
12
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.
13
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.
14
15
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
modes—indistinguishable from random noise. Note that the random appearance of the image on the right does not
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.
16
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
blocks.[15] For this reason, PCBC is not used in Kerberos v5.
17
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
18
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.
Because of the symmetry of the XOR operation, encryption and decryption are exactly the same:
19
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
this reason, support for truncated feedback was removed from the specification of OFB.[17][18]
20
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.
21
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.
22
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] 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] 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] Virgil D. Gligor, Pompiliu Donescu, "Fast Encryption and Authentication: XCBC Encryption and XECB Authentication Modes". Proc. Fast
Software Encryption, 2001: 92-108.
[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
[26] NIST: Modes Development (http:/ / csrc. nist. gov/ groups/ ST/ toolkit/ BCM/ modes_development. html)
23
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".
24
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
is evidence that the fraudulent DigiNotar certificates were used in a man-in-the-middle attack in Iran.[7]
25
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. 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. 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]
• XCA [12]
26
References
[1] https:/ / spreadsheets. google. com/ pub?key=ttwCVzDVuWzZYaDosdU6e3w& single=true& gid=0& output=html, List of Trusted Root
Certificate Authorities, 2/10/2010.
[2] http:/ / www. defcon. org/ images/ defcon-17/ dc-17-presentations/ defcon-17-zusman-hacking_pki. pdf
[3] Verisign, Inc. (31 January 2001). "Jan 2001 - Advisory from VeriSign, Inc." (http:/ / www. verisign. com/ support/ advisories/
authenticodefraud. html). . Retrieved 2008-12-02.
[4] Microsoft, Inc. (February 21, 2007). "Microsoft Security Bulletin MS01-017: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing
Hazard" (http:/ / support. microsoft. com/ kb/ 293818). . Retrieved 2011-Nov-09.
[5] Bright, Peter (28 March 2011). "Independent Iranian hacker claims responsibility for Comodo hack" (http:/ / arstechnica. com/ security/ news/
2011/ 03/ independent-iranian-hacker-claims-responsibility-for-comodo-hack. ars). Ars Technica. . Retrieved 1 September 2011.
[6] Bright, Peter (30 August 2011). "Another fraudulent certificate raises the same old questions about certificate authorities" (http:/ / arstechnica.
com/ security/ news/ 2011/ 08/ earlier-this-year-an-iranian. ars). Ars Technica. . Retrieved 1 September 2011.
[7] Fraudulent DigiNotar Certificate Usage (http:/ / www. theregister. co. uk/ 2011/ 09/ 06/ diginotar_audit_damning_fail/ ) Retrieved 7
September 2011.
[8] http:/ / www. abanet. org/ rppt/ meetings_cle/ 2002/ 2002spring/ RealProperty/ Thursday/ TechnologyandtheRealEstate/
OnlineTransactionManagement. pdf
[9] http:/ / www. webtrust. org/
[10] http:/ / news. netcraft. com/ ssl-sample-report/ CMatch/ certs
[11] http:/ / pki. fedoraproject. org/ wiki/ PKI_Main_Page
[12] http:/ / xca. hohnstaedt. de
External links
• Certificate authorities (http://www.dmoz.org/Computers/Security/Public_Key_Infrastructure/PKIX/
Tools_and_Services/Third_Party_Certificate_Authorities//) at the Open Directory Project
• Certificate Authority Reviews (http://www.sslshopper.com/certificate-authority-reviews.html)
• Certificate Authorities by Country (http://www.tractis.com/countries)
CMAC
In cryptography, CMAC (Cipher-based MAC)SP800-38B is a block cipher-based message authentication code
algorithm. It may be used to provide assurance of the authenticity and, hence, the integrity of binary data. This mode
of operation fixes security deficiencies of CBC-MAC (CBC-MAC is secure only for fixed-length messages).
The core of the CMAC algorithm is a variation of CBC-MAC that Black and Rogaway proposed and analyzed under
the name XCBCBR2 and submitted to NIST.BR1 The XCBC algorithm efficiently addresses the security deficiencies
of CBC-MAC, but requires three keys. Iwata and Kurosawa proposed an improvement of XCBC and named the
resulting algorithm One-Key CBC-MAC (OMAC) in their papers.IK2IK1 They later submitted OMAC1IK3, a
refinement of OMAC, and additional security analysis.IK4 The OMAC algorithm reduces the amount of key material
required for XCBC. CMAC is equivalent to OMAC1.
To generate an ℓ-bit CMAC tag (t) of a message (m) using a b-bit block cipher (E) and a secret key (k), one first
generates two b-bit sub-keys (k1 and k2) using the following algorithm (this is equivalent to multiplication by x and
x2 in a finite field GF(2b)). Let ≪ signify a standard left-shift operator:
1. Calculate a temporary value k0 = Ek(0).
2. If msb(k0) = 0, then k1 = k0 ≪ 1, else k1 = (k0 ≪ 1) ⊕ C; where C is a certain constant that depends only on b.
(Specifically, C is the non-leading coefficients of the lexicographically first irreducible degree-b binary
polynomial with the minimal number of ones.)
3. If msb(k1) = 0, then k2 = k1 ≪ 1, else k2 = (k1 ≪ 1) ⊕ C.
As a small example, suppose b = 4, C = 00112, and k0 = Ek(0) = 01012. Then k1 = 10102 and k2 = 0100 ⊕ 0011 =
01112.
27
CMAC
The CMAC tag generation process is as follows:
1. Divide message into b-bit blocks m = m1 ∥ … ∥ mn−1 ∥ mn′ where m1, …, mn−1 are complete blocks. (The empty
message is treated as 1 incomplete block.)
2. If mn′ is a complete block then mn = k1 ⊕ mn′ else mn = k2 ⊕ (mn′∥ 10…02).
3. Let c0 = 00…02.
4. For i = 1,…, n, calculate ci = Ek(ci−1 ⊕ mi).
5. Output t = msbℓ(cn).
The verification process is as follows:
1. Use the above algorithm to generate the tag.
2. Check that the generated tag is equal to the received tag.
References
• NIST, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, Special
Publication 800-38B [8].
• J. Black, P. Rogaway, A Suggestion for Handling Arbitrary-Length Messages with the CBC MAC, available from
NIST [1].
• J. Black, P. Rogaway, CBC MACs for arbitrary-length messages: The three-key constructions, Advances in
Cryptology—Crypto 2000.
• T. Iwata, K. Kurosawa, OMAC: One-Key CBC MAC, available from NIST [2].
• T. Iwata, K. Kurosawa, OMAC: One-Key CBC MAC, Fast Software Encryption 2003.
• T. Iwata, K. Kurosawa, OMAC: One-Key CBC MAC—Addendum, available from NIST [2].
• T. Iwata, K. Kurosawa, Stronger Security Bounds for OMAC, TMAC, and XCBC, available from NIST [3].
External links
• RFC 4493 The AES-CMAC Algorithm
• RFC 4494 The AES-CMAC-96 Algorithm and Its Use with IPsec
• RFC 4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random
Function-128 (AES-CMAC-PRF-128)
References
[1] http:/ / csrc. nist. gov/ CryptoToolkit/ modes/ workshop1/
[2] http:/ / csrc. nist. gov/ groups/ ST/ toolkit/ BCM/ documents/ proposedmodes/
[3] http:/ / csrc. nist. gov/ groups/ ST/ toolkit/ BCM/ comments. html
28
29
A cryptographic hash function is a
hash function that it can be defined as
a deterministic procedure that takes an
arbitrary block of data and returns a
fixed-size
bit
string,
the
(cryptographic) hash value, such that
an accidental or intentional change to
the data will change the hash value.
The data to be encoded is often called
the "message," and the hash value is
sometimes called the message digest
or simply digest.
The ideal cryptographic hash function
has four main or significant properties:
A cryptographic hash function (specifically, SHA-1) at work. Note that even small
• it is easy (but not necessarily quick)
changes in the source input (here in the word "over") drastically change the resulting
to compute the hash value for any
output, by the so-called avalanche effect.
given message
• it is infeasible to generate a message that has a given hash
• it is infeasible to modify a message without changing the hash
• it is infeasible to find two different messages with the same hash
Cryptographic hash functions have many information security applications, notably in digital signatures, message
authentication codes (MACs), and other forms of authentication. They can also be used as ordinary hash functions,
to index data in hash tables, for fingerprinting, to detect duplicate data or uniquely identify files, and as checksums to
detect accidental data corruption. Indeed, in information security contexts, cryptographic hash values are sometimes
called (digital) fingerprints, checksums, or just hash values, even though all these terms stand for functions with
rather different properties and purposes.
Properties
Most cryptographic hash functions are designed to take a string of any length as input and produce a fixed-length
hash value.
A cryptographic hash function must be able to withstand all known types of cryptanalytic attack. As a minimum, it
must have the following properties:
• Preimage resistance
Given a hash
it should be difficult to find any message
such that
. This concept is
related to that of one-way function. Functions that lack this property are vulnerable to preimage attacks.
• Second-preimage resistance
Given an input
it should be difficult to find another input
— where
— such that
. This property is sometimes referred to as weak collision resistance, and
functions that lack this property are vulnerable to second-preimage attacks.
• Collision resistance
It should be difficult to find two different messages
and
such that
. Such
a pair is called a cryptographic hash collision. This property is sometimes referred to as strong collision
30
resistance. It requires a hash value at least twice as long as that required for preimage-resistance, otherwise
collisions may be found by a birthday attack.
These properties imply that a malicious adversary cannot replace or modify the input data without changing its
digest. Thus, if two strings have the same digest, one can be very confident that they are identical.
A function meeting these criteria may still have undesirable properties. Currently popular cryptographic hash
functions are vulnerable to length-extension attacks: given
and
but not
, by choosing a suitable
an attacker can calculate
where
denotes concatenation. This property can be used to break naive
authentication schemes based on hash functions. The HMAC construction works around these problems.
Ideally, one may wish for even stronger conditions. It should be impossible for an adversary to find two messages
with substantially similar digests; or to infer any useful information about the data, given only its digest. Therefore, a
cryptographic hash function should behave as much as possible like a random function while still being deterministic
and efficiently computable.
Checksum algorithms, such as CRC32 and other cyclic redundancy checks, are designed to meet much weaker
requirements, and are generally unsuitable as cryptographic hash functions. For example, a CRC was used for
message integrity in the WEP encryption standard, but an attack was readily discovered which exploited the linearity
of the checksum.
Degree of difficulty
In cryptographic practice, “difficult” generally means “almost certainly beyond the reach of any adversary who must
be prevented from breaking the system for as long as the security of the system is deemed important.” The meaning
of the term is therefore somewhat dependent on the application, since the effort that a malicious agent may put into
the task is usually proportional to his expected gain. However, since the needed effort usually grows very quickly
with the digest length, even a thousand-fold advantage in processing power can be neutralized by adding a few dozen
bits to the latter.
In some theoretical analyses “difficult” has a specific mathematical meaning, such as not solvable in asymptotic
polynomial time. Such interpretations of difficulty are important in the study of provably secure cryptographic hash
functions but do not usually have a strong connection to practical security. For example, an exponential time
algorithm can sometimes still be fast enough to make a feasible attack. Conversely, a polynomial time algorithm
(e.g. one that requires n20 steps for n-digit keys) may be too slow for any practical use.
Illustration
An illustration of the potential use of a cryptographic hash is as follows: Alice poses a tough math problem to Bob,
and claims she has solved it. Bob would like to try it himself, but would yet like to be sure that Alice is not bluffing.
Therefore, Alice writes down her solution, appends a random nonce, computes its hash and tells Bob the hash value
(whilst keeping the solution and nonce secret). This way, when Bob comes up with the solution himself a few days
later, Alice can prove that she had the solution earlier by revealing the nonce to Bob. (This is an example of a simple
commitment scheme; in actual practice, Alice and Bob will often be computer programs, and the secret would be
something less easily spoofed than a claimed puzzle solution).
Applications
Verifying the integrity of files or messages
An important application of secure hashes is verification of message integrity. Determining whether any changes
have been made to a message (or a file), for example, can be accomplished by comparing message digests calculated
before, and after, transmission (or any other event).
For this reason, most digital signature algorithms only confirm the authenticity of a hashed digest of the message to
be "signed." Verifying the authenticity of a hashed digest of the message is considered proof that the message itself
is authentic.
A related application is password verification. Passwords are usually not stored in cleartext, for obvious reasons, but
instead in digest form. To authenticate a user, the password presented by the user is hashed and compared with the
stored hash.
File or data identifier
A message digest can also serve as a means of reliably identifying a file; several source code management systems,
including Git, Mercurial and Monotone, use the sha1sum of various types of content (file content, directory trees,
ancestry information, etc.) to uniquely identify them. Hashes are used to identify files on peer-to-peer filesharing
networks. For example, in an ed2k link, an MD4-variant hash is combined with the file size, providing sufficient
information for locating file sources, downloading the file and verifying its contents. Magnet links are another
example. Such file hashes are often the top hash of a hash list or a hash tree which allows for additional benefits.
One of the main applications of a hash function is to allow the fast look-up of a data in a hash table. Being hash
functions of a particular kind, cryptographic hash functions lend themselves well to this application too.
However, compared with standard hash functions, cryptographic hash functions tend to be much more expensive
computationally. For this reason, they tend to be used in contexts where it is necessary for users to protect
themselves against the possibility of forgery (the creation of data with the same digest as the expected data) by
potentially malicious participants.
Pseudorandom generation and key derivation
Hash functions can also be used in the generation of pseudorandom bits, or to derive new keys or passwords from a
single, secure key or password.
Hash functions based on block ciphers
There are several methods to use a block cipher to build a cryptographic hash function, specifically a one-way
compression function.
The methods resemble the block cipher modes of operation usually used for encryption. All well-known hash
functions, including MD4, MD5, SHA-1 and SHA-2 are built from block-cipher-like components designed for the
purpose, with feedback to ensure that the resulting function is not bijective. SHA-3 finalists include functions with
block-cipher-like components (e.g., Skein, BLAKE) and functions based on other designs (e.g., JH, Keccak).
A standard block cipher such as AES can be used in place of these custom block ciphers; that might be useful when
an embedded system needs to implement both encryption and hashing with minimal code size or hardware area.
However, that approach can have costs in efficiency and security. The ciphers in hash functions are built for hashing:
they use large keys and blocks, can efficiently change keys every block, and have been designed and vetted for
resistance to related-key attacks. General-purpose ciphers tend to have different design goals. In particular, AES has
key and block sizes that make it nontrivial to use to generate long hash values; AES encryption becomes less
efficient when the key changes each block; and related-key attacks make it potentially less secure for use in a hash
31
function than for encryption.
Merkle–Damgård construction
A hash function must be able to
process an arbitrary-length message
into a fixed-length output. This can be
achieved by breaking the input up into
a series of equal-sized blocks, and
operating on them in sequence using a
one-way compression function. The
compression function can either be
specially designed for hashing or be
built from a block cipher. A hash
The Merkle–Damgård hash construction.
function
built
with
the
Merkle–Damgård construction is as
resistant to collisions as is its compression function; any collision for the full hash function can be traced back to a
collision in the compression function.
The last block processed should also be unambiguously length padded; this is crucial to the security of this
construction. This construction is called the Merkle–Damgård construction. Most widely used hash functions,
including SHA-1 and MD5, take this form.
The construction has certain inherent flaws, including length-extension and generate-and-paste attacks, and cannot
be parallelized. As a result, many entrants in the current NIST hash function competition are built on different,
sometimes novel, constructions.
Use in building other cryptographic primitives
Hash functions can be used to build other cryptographic primitives. For these other primitives to be
cryptographically secure, care must be taken to build them correctly.
Message authentication codes (MACs) (also called keyed hash functions) are often built from hash functions.
HMAC is such a MAC.
Just as block ciphers can be used to build hash functions, hash functions can be used to build block ciphers.
Luby-Rackoff constructions using hash functions can be provably secure if the underlying hash function is secure.
Also, many hash functions (including SHA-1 and SHA-2) are built by using a special-purpose block cipher in a
Davies-Meyer or other construction. That cipher can also be used in a conventional mode of operation, without the
same security guarantees. See SHACAL, BEAR and LION.
Pseudorandom number generators (PRNGs) can be built using hash functions. This is done by combining a (secret)
random seed with a counter and hashing it.
Some hash functions, such as Skein, Keccak, and RadioGatún output an arbitrarily long stream and can be used as a
stream cipher, and stream ciphers can also be built from fixed-length digest hash functions. Often this is done by first
building a cryptographically secure pseudorandom number generator and then using its stream of random bytes as
keystream. SEAL is a stream cipher that uses SHA-1 to generate internal tables, which are then used in a keystream
generator more or less unrelated to the hash algorithm. SEAL is not guaranteed to be as strong (or weak) as SHA-1.
32
Concatenation of cryptographic hash functions
Concatenating outputs from multiple hash functions provides collision resistance as good as the strongest of the
algorithms included in the concatenated result. For example, older versions of TLS/SSL use concatenated MD5 and
SHA-1 sums; that ensures that a method to find collisions in one of the functions doesn't allow forging traffic
protected with both functions.
For Merkle-Damgård hash functions, the concatenated function is as collision-resistant as its strongest component,[1]
but not more collision-resistant.[2] Joux[3] noted that 2-collisions lead to n-collisions: if it is feasible to find two
messages with the same MD5 hash, it is effectively no more difficult to find as many messages as the attacker
desires with identical MD5 hashes. Among the n messages with the same MD5 hash, there is likely to be a collision
in SHA-1. The additional work needed to find the SHA-1 collision (beyond the exponential birthday search) is
polynomial. This argument is summarized by Finney [4]. A more current paper and full proof of the security of such
a combined construction gives a clearer and more complete explanation of the above.[5]
Cryptographic hash algorithms
There is a long list of cryptographic hash functions, although many have been found to be vulnerable and should not
be used. Even if a hash function has never been broken, a successful attack against a weakened variant thereof may
undermine the experts' confidence and lead to its abandonment. For instance, in August 2004 weaknesses were found
in a number of hash functions that were popular at the time, including SHA-0, RIPEMD, and MD5. This has called
into question the long-term security of later algorithms which are derived from these hash functions — in particular,
SHA-1 (a strengthened version of SHA-0), RIPEMD-128, and RIPEMD-160 (both strengthened versions of
RIPEMD). Neither SHA-0 nor RIPEMD are widely used since they were replaced by their strengthened versions.
As of 2009, the two most commonly used cryptographic hash functions are MD5 and SHA-1. However, MD5 has
been broken; an attack against it was used to break SSL in 2008.[6]
The SHA-0 and SHA-1 hash functions were developed by the NSA. In February 2005, a successful attack on SHA-1
was reported, finding collisions in about 269 hashing operations, rather than the 280 expected for a 160-bit hash
function. In August 2005, another successful attack on SHA-1 was reported, finding collisions in 263 operations.
Theoretical weaknesses of SHA-1 exist as well,[7][8] suggesting that it may be practical to break within years. New
applications can avoid these problems by using more advanced members of the SHA family, such as SHA-2, or
using techniques such as randomized hashing[9][10] that do not require collision resistance.
However, to ensure the long-term robustness of applications that use hash functions, there is a competition to design
a replacement for SHA-2, which will be given the name SHA-3 and become a FIPS standard around 2012.[11]
Some of the following algorithms are used often in cryptography; consult the article for each specific algorithm for
more information on the status of each algorithm. Note that this list does not include candidates in the current NIST
hash function competition. For additional hash functions see the box at the bottom of the page.
33
34
Algorithm
Output size (bits)
Internal
state size
Block
size
Length
size
Word
size
Collision attacks
(complexity)
GOST
256
256
256
256
32
Yes ( 2105
HAVAL
256/224/192/160/128
256
1,024
64
32
Yes
MD2
128
384
128
-
32
Yes ( 263.3
MD4
128
128
512
64
32
Yes ( 3
MD5
128
128
512
64
32
Yes ( 220.96
PANAMA
256
8,736
256
-
32
Yes
RadioGatún
Up to 608/1,216 (19
words)
58 words
3 words
-
1–64
With flaws ( 2352 or
[19]
2704
)
RIPEMD
128
128
512
64
32
Yes ( 218
RIPEMD-128/256
128/256
128/256
512
64
32
No
RIPEMD-160/320
160/320
160/320
512
64
32
No
SHA-0
160
160
512
64
32
Yes ( 233.6
SHA-1
160
160
512
64
32
Yes ( 251
SHA-256/224
256/224
256
512
64
32
No
No
SHA-512/384
512/384
512
1,024
128
64
No
No
Tiger(2)-192/160/128
192/160/128
192
512
64
64
WHIRLPOOL
512
512
512
256
8
[12]
)
Yes ( 2192
[12]
[13]
Yes ( 273
[14]
)
[15]
)
[17]
)
)
)
Yes ( 270.4
[16]
Yes ( 2123.4
[18]
)
)
[13]
)
[20]
)
[21]
Yes ( 262:19
No
Preimage attacks
(complexity)
No
)
[22]
)
Yes ( 2184.3
[16]
)
No
Note: The internal state here means the "internal hash sum" after each compression of a data block. Most hash
algorithms also internally use some additional variables such as length of the data compressed so far since that is
needed for the length padding in the end. See the Merkle-Damgård construction for details.
References
[1] Note that any two messages that collide the concatenated function also collide each component function, by the nature of concatenation. For
example, if concat(sha1(message1), md5(message1)) == concat(sha1(message2), md5(message2)) then sha1(message1) == sha1(message2)
and md5(message1)==md5(message2). The concatenated function could have other problems that the strongest hash lacks -- for example, it
might leak information about the message when the strongest component does not, or it might be detectably nonrandom when the strongest
component is not -- but it can't be less collision-resistant.
[2] More generally, if an attack can produce a collision in one hash function's internal state, attacking the combined construction is only as
difficult as a birthday attack against the other function(s). For the detailed argument, see the Joux and Finney references that follow.
[3] Antoine Joux. Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions. LNCS 3152/2004, pages 306-316 Full text
(http:/ / www. springerlink. com/ index/ DWWVMQJU0N0A3UGJ. pdf).
[4] http:/ / article. gmane. org/ gmane. comp. encryption. general/ 5154
[5] Jonathan J. Hoch and Adi Shamir (2008-02-20). On the Strength of the Concatenated Hash Combiner when all the Hash Functions are Weak
(http:/ / eprint. iacr. org/ 2008/ 075. pdf). .
[6] Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger, MD5 considered
harmful today: Creating a rogue CA certificate (http:/ / www. win. tue. nl/ hashclash/ rogue-ca/ ), accessed March 29, 2009
[7] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu, Finding Collisions in the Full SHA-1 (http:/ / people. csail. mit. edu/ yiqun/
SHA1AttackProceedingVersion. pdf)
[8] Bruce Schneier, Cryptanalysis of SHA-1 (http:/ / www. schneier. com/ blog/ archives/ 2005/ 02/ cryptanalysis_o. html) (summarizes Wang et
al. results and their implications)
[9] Shai Halevi, Hugo Krawczyk, Update on Randomized Hashing (http:/ / csrc. nist. gov/ groups/ ST/ hash/ documents/
HALEVI_UpdateonRandomizedHashing0824. pdf)
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
Shai Halevi and Hugo Krawczyk, Randomized Hashing and Digital Signatures (http:/ / www. ee. technion. ac. il/ ~hugo/ rhash/ )
NIST.gov - Computer Security Division - Computer Security Resource Center (http:/ / csrc. nist. gov/ groups/ ST/ hash/ sha-3/ index. html)
http:/ / www. springerlink. com/ content/ 2514122231284103/
http:/ / www. springerlink. com/ content/ n5vrtdha97a2udkx/
http:/ / eprint. iacr. org/ 2008/ 089. pdf
http:/ / www. springerlink. com/ content/ v6526284mu858v37/
http:/ / springerlink. com/ content/ d7pm142n58853467/
http:/ / eprint. iacr. org/ 2008/ 515
http:/ / www. springerlink. com/ content/ 3810jp9730369045/
http:/ / www. springerlink. com/ content/ u762587644802p38/
Further reading
• Bruce Schneier. Applied Cryptography. John Wiley & Sons, 1996. ISBN 0-471-12845-7.
• Christof Paar, Jan Pelzl, "Hash Functions" (http://wiki.crypto.rub.de/Buch/movies.php), Chapter 11 of
"Understanding Cryptography, A Textbook for Students and Practitioners". (companion web site contains online
cryptography course that covers hash functions), Springer, 2009.
Diffie–Hellman key exchange
Diffie–Hellman key exchange (D–H)[1] is a specific method of exchanging keys. It is one of the earliest practical
examples of key exchange implemented within the field of cryptography. The Diffie–Hellman key exchange method
allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an
insecure communications channel. This key can then be used to encrypt subsequent communications using a
symmetric key cipher.
The scheme was first published by Whitfield Diffie and Martin Hellman in 1976, although it later emerged that it
had been separately invented a few years earlier within GCHQ, the British signals intelligence agency, by Malcolm
J. Williamson but was kept classified. In 2002, Hellman suggested the algorithm be called Diffie–Hellman–Merkle
key exchange in recognition of Ralph Merkle's contribution to the invention of public-key cryptography (Hellman,
2002).
Although Diffie–Hellman key agreement itself is an anonymous (non-authenticated) key-agreement protocol, it
provides the basis for a variety of authenticated protocols, and is used to provide perfect forward secrecy in
Transport Layer Security's ephemeral modes (referred to as EDH or DHE depending on the cipher suite).
History of the protocol
The Diffie–Hellman key agreement was invented in 1976 during a collaboration between Whitfield Diffie and
Martin Hellman and was the first practical method for establishing a shared secret over an unprotected
communications channel. Ralph Merkle's work on public key distribution was an influence. John Gill suggested
application of the discrete logarithm problem. It had first been invented by Malcolm Williamson of GCHQ in the UK
some years previously, but GCHQ chose not to make it public until 1997, by which time it had no influence on
research in academia.
The method was followed shortly afterwards by RSA, another implementation of public key cryptography using
asymmetric algorithms.
In 2002, Martin Hellman wrote:
35
DiffieHellman key exchange
The system...has since become known as Diffie–Hellman key exchange. While that system was first
described in a paper by Diffie and me, it is a public key distribution system, a concept developed by
Merkle, and hence should be called 'Diffie–Hellman–Merkle key exchange' if names are to be
associated with it. I hope this small pulpit might help in that endeavor to recognize Merkle's equal
contribution to the invention of public key cryptography. [2]
U.S. Patent 4,200,770 [3], now expired, describes the algorithm and credits Hellman, Diffie, and Merkle as inventors.
Description
Diffie–Hellman establishes a shared secret that can be used for secret communications by exchanging data over a
public network. The following diagram illustrates the general idea of the key exchange:
Here is an explanation which includes the encryption's mathematics:
The simplest, and original, implementation of the protocol uses the multiplicative group of integers modulo p, where
p is prime and g is primitive root mod p. Here is an example of the protocol, with non-secret values in blue, and
secret values in boldface red:
36
37
Alice
Secret Public
a
p, g
a
p, g, A
a
p, g, A
a, s
Bob
Calculates
Sends
Calculates
Public Secret
p,g
ga mod p = A
p, g, A, B Ba mod p = s
b
A
p, g
B
b
gb mod p = B p, g, A, B
b
Ab mod p = s p, g, A, B
b, s
1. Alice and Bob agree to use a prime number p=23 and base g=5.
2. Alice chooses a secret integer a=6, then sends Bob A = ga mod p
• A = 56 mod 23
• A = 15,625 mod 23
• A=8
3. Bob chooses a secret integer b=15, then sends Alice B = gb mod p
• B = 515 mod 23
• B = 30,517,578,125 mod 23
• B = 19
4. Alice computes s = B a mod p
• s = 196 mod 23
• s = 47,045,881 mod 23
• s=2
5. Bob computes s = A b mod p
• s = 815 mod 23
• s = 35,184,372,088,832 mod 23
• s=2
6. Alice and Bob now share a secret: s = 2. This is because 6*15 is the same as 15*6. So somebody who had known
both these private integers might also have calculated s as follows:
•
•
•
•
•
s = 56*15 mod 23
s = 515*6 mod 23
s = 590 mod 23
s = 807,793,566,946,316,088,741,610,050,849,573,099,185,363,389,551,639,556,884,765,625 mod 23
s=2
Both Alice and Bob have arrived at the same value, because (ga)b and (gb)a are equal mod p. Note that only a, b and
gab = gba mod p are kept secret. All the other values – p, g, ga mod p, and gb mod p – are sent in the clear. Once
Alice and Bob compute the shared secret they can use it as an encryption key, known only to them, for sending
messages across the same open communications channel. Of course, much larger values of a, b, and p would be
needed to make this example secure, since it is easy to try all the possible values of gab mod 23. There are only 23
possible integers as the result of mod 23. If p were a prime of at least 300 digits, and a and b were at least 100 digits
long, then even the best algorithms known today could not find a given only g, p, gb mod p and ga mod p, even using
all of mankind's computing power. The problem is known as the discrete logarithm problem. Note that g need not be
large at all, and in practice is usually either 2 or 5.
Here's a more general description of the protocol:
1. Alice and Bob agree on a finite cyclic group G and a generating element g in G. (This is usually done long before
the rest of the protocol; g is assumed to be known by all attackers.) We will write the group G multiplicatively.
2. Alice picks a random natural number a and sends ga to Bob.
38
3. Bob picks a random natural number b and sends gb to Alice.
4. Alice computes (gb)a.
5. Bob computes (ga)b.
Both Alice and Bob are now in possession of the group element gab, which can serve as the shared secret key. The
values of (gb)a and (ga)b are the same because groups are power associative. (See also exponentiation.)
In order to decrypt a message m, sent as mgab, Bob (or Alice) must first compute (gab)-1, as follows:
Bob knows |G|, b, and ga. A result from group theory establishes that from the construction of G, x|G| = 1 for all x in
G.
Bob then calculates (ga)|G|-b = ga(|G|-b) = ga|G|-ab = ga|G|g-ab = (g|G|)ag-ab=1ag-ab=g-ab=(gab)-1.
When Alice sends Bob the encrypted message, mgab, Bob applies (gab)-1 and recovers mgab(gab)-1 = m(1) = m.
Chart
Here is a chart to help simplify who knows what. (Eve is an eavesdropper—she watches what is sent between Alice
and Bob, but she does not alter the contents of their communications.)
• Let s = shared secret key. s = 2
• Let g = public base. g = 5
•
•
•
•
•
Let p = public (prime) number. p = 23
Let a = Alice's private key. a = 6
Let A = Alice's public key. A = ga mod p = 8
Let b = Bob's private key. b = 15
Let B = Bob's public key. B = gb mod p = 19
Alice
knows
p = 23
Bob
doesn't know
b=?
knows
p = 23
Eve
doesn't know
a=?
knows
doesn't know
p = 23
a=?
base g = 5
b=?
base g = 5
base g = 5
a=6
b = 15
A = 56 mod 23 = 8
B = 515 mod 23 = 19
A = 5a mod 23 = 8
B = 5b mod 23 = 19
A = 5a mod 23 = 8
B = 5b mod 23 = 19
s = 196 mod 23 = 2
s = 815 mod 23 = 2
s = 19a mod 23
s = 8b mod 23 = 2
s = 19a mod 23 = 2
s = 8b mod 23
s = 196 mod 23 = 8b mod 23
s = 815 mod 23 = 19a mod 23
s = 19a mod 23 = 8b mod 23
s=2
s=2
s=?
Note: It should be difficult for Alice to solve for Bob's private key or for Bob to solve for Alice's private key. If it is
not difficult for Alice to solve for Bob's private key (or vice versa), Eve may simply substitute her own private /
public key pair, plug Bob's public key into her private key, produce a fake shared secret key, and solve for Bob's
private key (and use that to solve for the shared secret key. Eve may attempt to choose a public / private key pair that
will make it easy for her to solve for Bob's private key). A demonstration of Diffie-Hellman (using numbers too
small for practical use) is given here [4]
39
Operation with more than two parties
Diffie-Hellman key agreement is not limited to negotiating a key shared by only two participants. Any number of
users can take part in an agreement by performing iterations of the agreement protocol and exchanging intermediate
data (which does not itself need to be kept secret). For example, Alice, Bob, and Carol could participate in a
Diffie-Hellman agreement as follows, with all operations taken to be modulo :
1. The parties agree on the algorithm parameters
2. The parties generate their private keys, named
3. Alice computes
4.
5.
6.
7.
8.
9.
Bob computes
Carol computes
Bob computes
Carol computes
Alice computes
Carol computes
and .
, , and
.
and sends it to Bob.
and sends it to Carol.
and uses it as her secret.
and sends it to Carol.
and sends it to Alice.
and uses it as her secret.
and sends it to Alice.
10. Alice computes
and sends it to Bob.
11. Bob computes
and uses it as his secret.
An eavesdropper has been able to see
,
,
,
,
, and
, but cannot use any combination of these
to reproduce
.
To extend this mechanism to larger groups, two basic principles must be followed:
• Starting with an “empty” key consisting only of
, the secret is made by raising the current value to every
participant’s private exponent once, in any order (the first such exponentiation yields the participant’s own public
key).
• Any intermediate value (having up to
exponents applied, where
is the number of participants in the
group) may be revealed publicly, but the final value (having had all
exponents applied) constitutes the shared
secret and hence must never be revealed publicly. Thus, each user must obtain their copy of the secret by applying
their own private key last (otherwise there would be no way for the last contributor to communicate the final key
to its recipient, as that last contributor would have turned the key into the very secret the group wished to protect).
These principles leave open various options for choosing in which order participants contribute to keys. The simplest
and most obvious solution is to arrange the
participants in a circle and have
keys rotate around the circle,
until eventually every key has been contributed to by all
has contributed to
participants (ending with its owner) and each participant
keys (ending with their own). However, this requires that every participant perform
modular exponentiations.
By choosing a more optimal order, and relying on the fact that keys can be duplicated, it is possible to reduce the
number of modular exponentiations performed by each participant to
using a divide-and-conquer-style
approach, given here for eight participants:
1. Participants A, B, C, and D each perform one exponentiation, yielding
H. In return, participants A, B, C, and D receive
.
2. Participants A and B each perform one exponentiation, yielding
; this value is sent to E, F, G, and
, which they send to C and D, while C
and D do the same, yielding
, which they send to A and B.
3. Participant A performs an exponentiation, yielding
, which it sends to B; similarly, B sends
to A. C and D do similarly.
4. Participant A performs one final exponentiation, yielding the secret
same to get
; again, C and D do similarly.
5. Participants E through H simultaneously perform the same operations using
, while B does the
as their starting point.
Upon completing this algorithm, all participants will possess the secret
40
, but each participant will have
performed only four modular exponentiations, rather than the eight implied by a simple circular arrangement.
Security
The protocol is considered secure against eavesdroppers if G and g are chosen properly. The eavesdropper ("Eve")
would have to solve the Diffie–Hellman problem to obtain gab. This is currently considered difficult. An efficient
algorithm to solve the discrete logarithm problem would make it easy to compute a or b and solve the
Diffie–Hellman problem, making this and many other public key cryptosystems insecure.
The order of G should be prime or have a large prime factor to prevent use of the Pohlig–Hellman algorithm to
obtain a or b. For this reason, a Sophie Germain prime q is sometimes used to calculate p=2q+1, called a safe prime,
since the order of G is then only divisible by 2 and q. g is then sometimes chosen to generate the order q subgroup of
G, rather than G, so that the Legendre symbol of ga never reveals the low order bit of a.
If Alice and Bob use random number generators whose outputs are not completely random and can be predicted to
some extent, then Eve's task is much easier.
The secret integers a and b are discarded at the end of the session. Therefore, Diffie–Hellman key exchange by itself
trivially achieves perfect forward secrecy because no long-term private keying material exists to be disclosed.
In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the
communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish
two distinct Diffie–Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as
Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed
between them. A method to authenticate the communicating parties to each other is generally needed to prevent this
type of attack. Variants of Diffie-Hellman, such as STS, may be used instead to avoid these types of attacks.
Other uses
Password-authenticated key agreement
When Alice and Bob share a password, they may use a password-authenticated key agreement (PAKE) form of
Diffie–Hellman to prevent man-in-the-middle attacks. One simple scheme is to make the generator g the password.
A feature of these schemes is that an attacker can only test one specific password on each iteration with the other
party, and so the system provides good security with relatively weak passwords. This approach is described in ITU-T
Recommendation X.1035, which is used by the G.hn home networking standard.
Public Key
It is also possible to use Diffie–Hellman as part of a public key infrastructure. Alice's public key is simply
. To send her a message Bob chooses a random b, and then sends Alice
(un-encrypted)
together with the message encrypted with symmetric key
. Only Alice can decrypt the message
because only she has a. A preshared public key also prevents man-in-the-middle attacks.
In practice, Diffie–Hellman is not used in this way, with RSA being the dominant public key algorithm. This is
largely for historical and commercial reasons, namely that RSA created a Certificate Authority that became Verisign.
Diffie–Hellman cannot be used to sign certificates, although the ElGamal and DSA signature algorithms are related
to it. However, it is related to MQV, STS and the IKE component of the IPsec protocol suite for securing Internet
Protocol communications.
Notes
[1] Synonyms of Diffie–Hellman key exchange include:
• Diffie–Hellman key agreement
• Diffie–Hellman key establishment
• Diffie–Hellman key negotiation
• Exponential key exchange
• Diffie–Hellman protocol
• Diffie–Hellman handshake
[2] http:/ / www. comsoc. org/ livepubs/ ci1/ public/ anniv/ pdfs/ hellman. pdf
[3] http:/ / www. google. com/ patents?vid=4,200,770
[4] http:/ / buchananweb. co. uk/ security02. aspx
References
• Dieter Gollmann (2006). Computer Security Second Edition West Sussex, England: John Wiley & Sons, Ltd.
• The possibility of Non-Secret digital encryption (http://cryptocellar.web.cern.ch/cryptocellar/cesg/possnse.
pdf) J. H. Ellis, January 1970.
• Non-Secret Encryption Using a Finite Field (http://www.cesg.gov.uk/publications/media/secenc.pdf) MJ
Williamson, January 21, 1974.
• Thoughts on Cheaper Non-Secret Encryption (http://www.fi.muni.cz/usr/matyas/lecture/paper3.pdf) MJ
Williamson, August 10, 1976.
• New Directions in Cryptography (http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.9720) W.
Diffie and M. E. Hellman, IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976, pp: 644–654.
• Cryptographic apparatus and method (http://www.google.com/patents?vid=4200770) Martin E. Hellman,
Bailey W. Diffie, and Ralph C. Merkle, U.S. Patent #4,200,770, 29 April 1980
• The History of Non-Secret Encryption (http://www.cesg.gov.uk/site/publications/media/ellis.pdf) JH Ellis
1987 (28K PDF file) ( HTML version (http://www.jya.com/ellisdoc.htm))
• The First Ten Years of Public-Key Cryptography (http://cr.yp.to/bib/1988/diffie.pdf) Whitfield Diffie,
Proceedings of the IEEE, vol. 76, no. 5, May 1988, pp: 560–577 (1.9MB PDF file)
• Menezes, Alfred; van Oorschot, Paul; Vanstone, Scott (1997). Handbook of Applied Cryptography Boca Raton,
Florida: CRC Press. ISBN 0-8493-8523-7. ( Available online (http://www.cacr.math.uwaterloo.ca/hac/))
• Singh, Simon (1999) The Code Book: the evolution of secrecy from Mary Queen of Scots to quantum
cryptography New York: Doubleday ISBN 0-385-49531-5
• An Overview of Public Key Cryptography (http://dx.doi.org/10.1109/MCOM.2002.1006971) Martin E.
Hellman, IEEE Communications Magazine, May 2002, pp:42–49. (123kB PDF file)
External links
• Oral history interview with Martin Hellman (http://www.cbi.umn.edu/oh/display.phtml?id=353), Charles
Babbage Institute, University of Minnesota. Leading cryptography scholar Martin Hellman discusses the
circumstances and fundamental insights of his invention of public key cryptography with collaborators Whitfield
Diffie and Ralph Merkle at Stanford University in the mid-1970s.
• RFC 2631 – Diffie–Hellman Key Agreement Method E. Rescorla June 1999.
• Summary of ANSI X9.42: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography (http://csrc.
nist.gov/encryption/kms/summary-x9-42.pdf) (64K PDF file) ( Description of ANSI 9 Standards (http://
www.rsasecurity.com/rsalabs/node.asp?id=2306))
• Diffie–Hellman Key Exchange – A Non-Mathematician’s Explanation (http://docs.google.com/viewer?a=v&
pid=sites&srcid=bmV0aXAuY29tfGhvbWV8Z3g6NTA2NTM0YmNhZjRhZDYzZQ) by Keith Palmgren
• Crypt::DH (http://search.cpan.org/search?query=Crypt::DH&mode=module) Perl module from CPAN
• Hands-on Diffie–Hellman demonstration (http://ds9a.nl/tmp/dh.html)
41
• C implementation using GNU Multiple Precision Arithmetic Library (http://oldpiewiki.yoonkn.com/cgi-bin/
moin.cgi/DiffieHellmanKeyExchange)
• Diffie Hellman in 2 lines of Perl (http://www.cypherspace.org/adam/rsa/perl-dh.html) (using dc)
• Smart Account Management (SAcct) (http://code.google.com/p/sacct/) (using DH key exchange to derive
session key)
• Talk by Martin Hellman in 2007, Google video (http://video.google.com/
videoplay?docid=8991737124862867507)
Digital signature
A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a
digital message or document. A valid digital signature gives a recipient reason to believe that the message was
created by a known sender, and that it was not altered in transit. Digital signatures are commonly used for software
distribution, financial transactions, and in other cases where it is important to detect forgery or tampering.
Explanation
Digital signatures are often used to implement electronic signatures, a broader term that refers to any electronic data
that carries the intent of a signature,[1] but not all electronic signatures use digital signatures.[2][3][4] In some
countries, including the United States, India,[5] and members of the European Union, electronic signatures have legal
significance. However, laws concerning electronic signatures do not always make clear whether they are digital
cryptographic signatures in the sense used here, leaving the legal definition, and so their importance, somewhat
confused.
Digital signatures employ a type of asymmetric cryptography. For messages sent through a nonsecure channel, a
properly implemented digital signature gives the receiver reason to believe the message was sent by the claimed
sender. Digital signatures are equivalent to traditional handwritten signatures in many respects; properly
implemented digital signatures are more difficult to forge than the handwritten type. Digital signature schemes in the
sense used here are cryptographically based, and must be implemented properly to be effective. Digital signatures
can also provide non-repudiation, meaning that the signer cannot successfully claim they did not sign a message,
while also claiming their private key remains secret; further, some non-repudiation schemes offer a time stamp for
the digital signature, so that even if the private key is exposed, the signature is valid nonetheless. Digitally signed
messages may be anything representable as a bitstring: examples include electronic mail, contracts, or a message
sent via some other cryptographic protocol.
42
Digital signature
43
Definition
A digital signature scheme typically
consists of three algorithms:
• A key generation algorithm that
selects a private key uniformly at
random from a set of possible
private keys. The algorithm outputs
the private key and a corresponding
public key.
• A signing algorithm that, given a
message and a private key, produces
a signature.
• A signature verifying algorithm
that, given a message, public key
and a signature, either accepts or
rejects the message's claim to
authenticity.
Diagram showing how a simple digital signature is applied and then verified
Two main properties are required. First, a signature generated from a fixed message and fixed private key should
verify the authenticity of that message by using the corresponding public key. Secondly, it should be
computationally infeasible to generate a valid signature for a party who does not possess the private key.
History
In 1976, Whitfield Diffie and Martin Hellman first described the notion of a digital signature scheme, although they
only conjectured that such schemes existed.[6][7] Soon afterwards, Ronald Rivest, Adi Shamir, and Len Adleman
invented the RSA algorithm, which could be used to produce primitive digital signatures[8] (although only as a
proof-of-concept—"plain" RSA signatures are not secure[9]). The first widely marketed software package to offer
digital signature was Lotus Notes 1.0, released in 1989, which used the RSA algorithm.
To create RSA signature keys, generate an RSA key pair containing a modulus N that is the product of two large
primes, along with integers e and d such that e d ≡ 1 (mod φ(N)), where φ is the Euler phi-function. The signer's
public key consists of N and e, and the signer's secret key contains d.
To sign a message m, the signer computes σ ≡ md (mod N). To verify, the receiver checks that σe ≡ m (mod N).
As noted earlier, this basic scheme is not very secure. To prevent attacks, one can first apply a cryptographic hash
function to the message m and then apply the RSA algorithm described above to the result. This approach can be
proven secure in the so-called random oracle model.
Other digital signature schemes were soon developed after RSA, the earliest being Lamport signatures,[10] Merkle
signatures (also known as "Merkle trees" or simply "Hash trees"),[11] and Rabin signatures.[12]
In 1988, Shafi Goldwasser, Silvio Micali, and Ronald Rivest became the first to rigorously define the security
requirements of digital signature schemes.[13] They described a hierarchy of attack models for signature schemes,
and also present the GMR signature scheme, the first that can be proven to prevent even an existential forgery
against a chosen message attack.[13]
Most early signature schemes were of a similar type: they involve the use of a trapdoor permutation, such as the RSA
function, or in the case of the Rabin signature scheme, computing square modulo composite n. A trapdoor
permutation family is a family of permutations, specified by a parameter, that is easy to compute in the forward
direction, but is difficult to compute in the reverse direction without already knowing the private key. However, for
Digital signature
every parameter there is a "trapdoor" (private key) which when known, easily decrypts the message. Trapdoor
permutations can be viewed as public-key encryption systems, where the parameter is the public key and the
trapdoor is the secret key, and where encrypting corresponds to computing the forward direction of the permutation,
while decrypting corresponds to the reverse direction. Trapdoor permutations can also be viewed as digital signature
schemes, where computing the reverse direction with the secret key is thought of as signing, and computing the
forward direction is done to verify signatures. Because of this correspondence, digital signatures are often described
as based on public-key cryptosystems, where signing is equivalent to decryption and verification is equivalent to
encryption, but this is not the only way digital signatures are computed.
Used directly, this type of signature scheme is vulnerable to a key-only existential forgery attack. To create a
forgery, the attacker picks a random signature σ and uses the verification procedure to determine the message m
corresponding to that signature.[14] In practice, however, this type of signature is not used directly, but rather, the
message to be signed is first hashed to produce a short digest that is then signed. This forgery attack, then, only
produces the hash function output that corresponds to σ, but not a message that leads to that value, which does not
lead to an attack. In the random oracle model, this hash-and-decrypt form of signature is existentially unforgeable,
even against a chosen-message attack.[7]
There are several reasons to sign such a hash (or message digest) instead of the whole document.
• For efficiency: The signature will be much shorter and thus save time since hashing is generally much faster than
signing in practice.
• For compatibility: Messages are typically bit strings, but some signature schemes operate on other domains
(such as, in the case of RSA, numbers modulo a composite number N). A hash function can be used to convert an
arbitrary input into the proper format.
• For integrity: Without the hash function, the text "to be signed" may have to be split (separated) in blocks small
enough for the signature scheme to act on them directly. However, the receiver of the signed blocks is not able to
recognize if all the blocks are present and in the appropriate order.
Notions of security
In their foundational paper, Goldwasser, Micali, and Rivest lay out a hierarchy of attack models against digital
signatures[13]:
1. In a key-only attack, the attacker is only given the public verification key.
2. In a known message attack, the attacker is given valid signatures for a variety of messages known by the attacker
but not chosen by the attacker.
3. In an adaptive chosen message attack, the attacker first learns signatures on arbitrary messages of the attacker's
choice.
They also describe a hierarchy of attack results[13]:
1.
2.
3.
4.
A total break results in the recovery of the signing key.
A universal forgery attack results in the ability to forge signatures for any message.
A selective forgery attack results in a signature on a message of the adversary's choice.
An existential forgery merely results in some valid message/signature pair not already known to the adversary.
The strongest notion of security, therefore, is security against existential forgery under an adaptive chosen message
attack.
44
Digital signature
Uses of digital signatures
As organizations move away from paper documents with ink signatures or authenticity stamps, digital signatures can
provide added assurances of the evidence to provenance, identity, and status of an electronic document as well as
acknowledging informed consent and approval by a signatory. The United States Government Printing Office (GPO)
publishes electronic versions of the budget, public and private laws, and congressional bills with digital signatures.
Universities including Penn State, University of Chicago, and Stanford are publishing electronic student transcripts
with digital signatures.
Below are some common reasons for applying a digital signature to communications:
Authentication
Although messages may often include information about the entity sending a message, that information may not be
accurate. Digital signatures can be used to authenticate the source of messages. When ownership of a digital
signature secret key is bound to a specific user, a valid signature shows that the message was sent by that user. The
importance of high confidence in sender authenticity is especially obvious in a financial context. For example,
suppose a bank's branch office sends instructions to the central office requesting a change in the balance of an
account. If the central office is not convinced that such a message is truly sent from an authorized source, acting on
such a request could be a grave mistake.
Integrity
In many scenarios, the sender and receiver of a message may have a need for confidence that the message has not
been altered during transmission. Although encryption hides the contents of a message, it may be possible to change
an encrypted message without understanding it. (Some encryption algorithms, known as nonmalleable ones, prevent
this, but others do not.) However, if a message is digitally signed, any change in the message after signature will
invalidate the signature. Furthermore, there is no efficient way to modify a message and its signature to produce a
new message with a valid signature, because this is still considered to be computationally infeasible by most
cryptographic hash functions (see collision resistance).
Non-repudiation
Non-repudiation, or more specifically non-repudiation of origin, is an important aspect of digital signatures. By this
property an entity that has signed some information cannot at a later time deny having signed it. Similarly, access to
the public key only does not enable a fraudulent party to fake a valid signature.
Additional security precautions
Putting the private key on a smart card
All public key / private key cryptosystems depend entirely on keeping the private key secret. A private key can be
stored on a user's computer, and protected by a local password, but this has two disadvantages:
• the user can only sign documents on that particular computer
• the security of the private key depends entirely on the security of the computer
A more secure alternative is to store the private key on a smart card. Many smart cards are designed to be
tamper-resistant (although some designs have been broken, notably by Ross Anderson and his students). In a typical
digital signature implementation, the hash calculated from the document is sent to the smart card, whose CPU
encrypts the hash using the stored private key of the user, and then returns the encrypted hash. Typically, a user must
activate his smart card by entering a personal identification number or PIN code (thus providing two-factor
authentication). It can be arranged that the private key never leaves the smart card, although this is not always
45
Digital signature
implemented. If the smart card is stolen, the thief will still need the PIN code to generate a digital signature. This
reduces the security of the scheme to that of the PIN system, although it still requires an attacker to possess the card.
A mitigating factor is that private keys, if generated and stored on smart cards, are usually regarded as difficult to
copy, and are assumed to exist in exactly one copy. Thus, the loss of the smart card may be detected by the owner
and the corresponding certificate can be immediately revoked. Private keys that are protected by software only may
be easier to copy, and such compromises are far more difficult to detect.
Using smart card readers with a separate keyboard
Entering a PIN code to activate the smart card commonly requires a numeric keypad. Some card readers have their
own numeric keypad. This is safer than using a card reader integrated into a PC, and then entering the PIN using that
computer's keyboard. Readers with a numeric keypad are meant to circumvent the eavesdropping threat where the
computer might be running a keystroke logger, potentially compromising the PIN code. Specialized card readers are
also less vulnerable to tampering with their software or hardware and are often EAL3 certified.
Other smart card designs
Smart card design is an active field, and there are smart card schemes which are intended to avoid these particular
problems, though so far with little security proofs.
Using digital signatures only with trusted applications
One of the main differences between a digital signature and a written signature is that the user does not "see" what he
signs. The user application presents a hash code to be encrypted by the digital signing algorithm using the private
key. An attacker who gains control of the user's PC can possibly replace the user application with a foreign
substitute, in effect replacing the user's own communications with those of the attacker. This could allow a malicious
application to trick a user into signing any document by displaying the user's original on-screen, but presenting the
attacker's own documents to the signing application.
To protect against this scenario, an authentication system can be set up between the user's application (word
processor, email client, etc.) and the signing application. The general idea is to provide some means for both the user
app and signing app to verify each other's integrity. For example, the signing application may require all requests to
come from digitally signed binaries.
WYSIWYS
Technically speaking, a digital signature applies to a string of bits, whereas humans and applications "believe" that
they sign the semantic interpretation of those bits. In order to be semantically interpreted the bit string must be
transformed into a form that is meaningful for humans and applications, and this is done through a combination of
hardware and software based processes on a computer system. The problem is that the semantic interpretation of bits
can change as a function of the processes used to transform the bits into semantic content. It is relatively easy to
change the interpretation of a digital document by implementing changes on the computer system where the
document is being processed. From a semantic perspective this creates uncertainty about what exactly has been
signed. WYSIWYS (What You See Is What You Sign) [15] means that the semantic interpretation of a signed
message cannot be changed. In particular this also means that a message cannot contain hidden information that the
signer is unaware of, and that can be revealed after the signature has been applied. WYSIWYS is a desirable
property of digital signatures that is difficult to guarantee because of the increasing complexity of modern computer
systems.
46
Digital signature
Digital signatures vs. ink on paper signatures
An ink signature could be replicated from one document to another by copying the image manually or digitally, but
to have credible signature copies that can resist some scrutiny is a significant manual or technical skill, and to
produce ink signature copies that resist professional scrutiny is very difficult.
Digital signatures cryptographically bind an electronic identity to an electronic document and the digital signature
cannot be copied to another document. Paper contracts sometimes have the ink signature block on the last page, and
the previous pages may be replaced after a signature is applied. Digital signatures can be applied to an entire
document, such that the digital signature on the last page will indicate tampering if any data on any of the pages have
been altered, but this can also be achieved by signing with ink all pages of the contract.
Additionally, most digital certificates provided by certificate authorities to end users to sign documents can be
obtained by at most gaining access to a victim's email inbox.
Important paper documents are signed in ink with all involved parties meeting in person, with additional
identification forms other than the actual presence (like driver's licence, passports, fingerprints, etc.), and most
usually with the presence of a respected notary that knows the involved parties, the signing often happens in a
building which has security cameras and other forms of identification and physical security. The security that is
added by these type of ink on paper signatures cannot be currently matched by digital only signatures.
Some digital signature algorithms
• RSA-based signature schemes, such as RSA-PSS
• DSA and its elliptic curve variant ECDSA
• ElGamal signature scheme as the predecessor to DSA, and variants Schnorr signature and Pointcheval–Stern
signature algorithm
• Rabin signature algorithm
• Pairing-based schemes such as BLS
• Undeniable signatures
• Aggregate signature - a signature scheme that supports aggregation: Given n signatures on n messages from n
users, it is possible to aggregate all these signatures into a single signature whose size is constant in the number of
users. This single signature will convince the verifier that the n users did indeed sign the n original messages.
The current state of use — legal and practical
Digital signature schemes share basic prerequisites that— regardless of cryptographic theory or legal provision—
they need to have meaning:
Quality algorithms
Some public-key algorithms are known to be insecure, practicable attacks against them having been
discovered.
Quality implementations
An implementation of a good algorithm (or protocol) with mistake(s) will not work.
The private key must remain private
if it becomes known to any other party, that party can produce perfect digital signatures of anything
whatsoever.
The public key owner must be verifiable
A public key associated with Bob actually came from Bob. This is commonly done using a public key
infrastructure and the public key
user association is attested by the operator of the PKI (called a certificate
47
Digital signature
authority). For 'open' PKIs in which anyone can request such an attestation (universally embodied in a
cryptographically protected identity certificate), the possibility of mistaken attestation is non trivial.
Commercial PKI operators have suffered several publicly known problems. Such mistakes could lead to
falsely signed, and thus wrongly attributed, documents. 'closed' PKI systems are more expensive, but less
easily subverted in this way.
Users (and their software) must carry out the signature protocol properly.
Only if all of these conditions are met will a digital signature actually be any evidence of who sent the message, and
therefore of their assent to its contents. Legal enactment cannot change this reality of the existing engineering
possibilities, though some such have not reflected this actuality.
Legislatures, being importuned by businesses expecting to profit from operating a PKI, or by the technological
avant-garde advocating new solutions to old problems, have enacted statutes and/or regulations in many jurisdictions
authorizing, endorsing, encouraging, or permitting digital signatures and providing for (or limiting) their legal effect.
The first appears to have been in Utah in the United States, followed closely by the states Massachusetts and
California. Other countries have also passed statutes or issued regulations in this area as well and the UN has had an
active model law project for some time. These enactments (or proposed enactments) vary from place to place, have
typically embodied expectations at variance (optimistically or pessimistically) with the state of the underlying
cryptographic engineering, and have had the net effect of confusing potential users and specifiers, nearly all of whom
are not cryptographically knowledgeable. Adoption of technical standards for digital signatures have lagged behind
much of the legislation, delaying a more or less unified engineering position on interoperability, algorithm choice,
key lengths, and so on what the engineering is attempting to provide.
See also: ABA digital signature guidelines
Industry standards
Some industries have established common interoperability standards for the use of digital signatures between
members of the industry and with regulators. These include the Automotive Network Exchange for the automobile
industry and the SAFE-BioPharma Association for the healthcare industry.
Using separate key pairs for signing and encryption
In several countries, a digital signature has a status somewhat like that of a traditional pen and paper signature, like
in the EU digital signature legislation [16]. Generally, these provisions mean that anything digitally signed legally
binds the signer of the document to the terms therein. For that reason, it is often thought best to use separate key
pairs for encrypting and signing. Using the encryption key pair, a person can engage in an encrypted conversation
(e.g., regarding a real estate transaction), but the encryption does not legally sign every message he sends. Only
when both parties come to an agreement do they sign a contract with their signing keys, and only then are they
legally bound by the terms of a specific document. After signing, the document can be sent over the encrypted link.
If a signing key is lost or compromised, it can be revoked to mitigate any future transactions. If an encryption key is
lost, a backup or key escrow should be utilized to continue viewing encrypted content. Signing keys should never be
backed up or escrowed.
48
Digital signature
Notes
[1] US ESIGN Act of 2000 (http:/ / frwebgate. access. gpo. gov/ cgi-bin/ getdoc. cgi?dbname=106_cong_public_laws& docid=f:publ229. 106.
pdf)
[2] The University of Virginia (http:/ / www. itc. virginia. edu/ virginia. edu/ fall00/ digsigs/ home. html)
[3] State of WI (http:/ / enterprise. state. wi. us/ home/ strategic/ esig. htm)
[4] National Archives of Australia (http:/ / www. naa. gov. au/ recordkeeping/ er/ Security/ 6-glossary. html)
[5] The Information Technology Act, 2000 (http:/ / www. dot. gov. in/ Acts/ itbill2000. pdf). .
[6] "New Directions in Cryptography", IEEE Transactions on Information Theory, IT-22(6):644–654, Nov. 1976.
[7] " Signature Schemes and Applications to Cryptographic Protocol Design (http:/ / theory. lcs. mit. edu/ ~cis/ theses/ anna-phd. pdf)", Anna
Lysyanskaya, PhD thesis, MIT, 2002.
[8] Rivest, R.; A. Shamir; L. Adleman (1978). "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" (http:/ / theory. lcs.
mit. edu/ ~rivest/ rsapaper. pdf). Communications of the ACM 21 (2): 120–126. doi:10.1145/359340.359342. .
[9] For example any integer r "signs" m=re and the product s1s2 of any two valid signatures s1, s2 of m1, m2 is a valid signature of the product
m1m2.
[10] "Constructing digital signatures from a one-way function.", Leslie Lamport, Technical Report CSL-98, SRI International, Oct. 1979.
[11] "A certified digital signature", Ralph Merkle, In Gilles Brassard, ed., Advances in Cryptology – CRYPTO '89, vol. 435 of Lecture Notes in
Computer Science, pp. 218–238, Spring Verlag, 1990.
[12] "Digitalized signatures as intractable as factorization." Michael O. Rabin, Technical Report MIT/LCS/TR-212, MIT Laboratory for
Computer Science, Jan. 1979
[13] "A digital signature scheme secure against adaptive chosen-message attacks.", Shafi Goldwasser, Silvio Micali, and Ronald Rivest. SIAM
Journal on Computing, 17(2):281–308, Apr. 1988.
[14] "Modern Cryptography: Theory & Practice", Wenbo Mao, Prentice Hall Professional Technical Reference, New Jersey, 2004, pg. 308.
ISBN 0-13-066943-1
[15] A. Jøsang, D. Povey and A. Ho. "What You See is Not Always What You Sign". Proceedings of the Australian Unix User Group
Symposium (AUUG2002), Melbourne, September 2002. PDF (http:/ / www. unik. no/ people/ josang/ papers/ JPH2002-AUUG. pdf)
[16] http:/ / europa. eu/ legislation_summaries/ information_society/ l24118_en. htm
Books dealing with crytography
• J. Katz and Y. Lindell, "Introduction to Modern Cryptography" (Chapman & Hall/CRC Press, 2007)
Books dealing with the law that are global in scope
• Stephen Mason, Electronic Signatures in Law (3rd edition, Cambridge University Press, 2012);
• Lorna Brazell, Electronic Signatures and Identities Law and Regulation (2nd edn, London: Sweet & Maxwell,
2008);
• Dennis Campbell, editor, E-Commerce and the Law of Digital Signatures (Oceana Publications, 2005).
Books dealing with the law: Netherlands
• M. H. M Schellenkens, Electronic Signatures Authentication Technology from a Legal Perspective, (TMC Asser
Press, 2004).
Books dealing with the law: United States of America
• Jeremiah S. Buckley, John P. Kromer, Margo H. K. Tank, and R. David Whitaker, The Law of Electronic
Signatures (3rd Edition, West Publishing, 2010).
For translations of electronic signature cases from the globe into English, see the Digital Evidence and Electronic
Signature Law Review (http://www.deaeslr.org/).
49
The Digital Signature Algorithm (DSA) is a United States Federal Government standard or FIPS for digital
signatures. It was proposed by the National Institute of Standards and Technology (NIST) in August 1991 for use in
their Digital Signature Standard (DSS), specified in FIPS 186,[1] adopted in 1993. A minor revision was issued in
1996 as FIPS 186-1.[2] The standard was expanded further in 2000 as FIPS 186-2 and again in 2009 as FIPS 186-3.[3]
DSA is covered by U.S. Patent 5231668 [4], filed July 26, 1991, and attributed to David W. Kravitz,[5] a former NSA
employee. This patent was given to "The United States of America as represented by the Secretary of Commerce,
Washington, D.C." and the NIST has made this patent available worldwide royalty-free.[6] Dr. Claus P. Schnorr
claims that his U.S. Patent 4995082 [7] (expired) covered DSA; this claim is disputed.[8] DSA is a variant of the
ElGamal Signature Scheme.
Key generation
Key generation has two phases. The first phase is a choice of algorithm parameters which may be shared between
different users of the system, while the second phase computes public and private keys for a single user.
Parameter generation
• Choose an approved cryptographic hash function H. In the original DSS, H was always SHA-1, but the stronger
SHA-2 hash functions are approved for use in the current DSS. The hash output may be truncated to the size of a
key pair.
• Decide on a key length L and N. This is the primary measure of the cryptographic strength of the key. The original
DSS constrained L to be a multiple of 64 between 512 and 1024 (inclusive). NIST 800-57[9] recommends lengths
of 2048 (or 3072) for keys with security lifetimes extending beyond 2010 (or 2030), using correspondingly longer
N. FIPS 186-3[3] specifies L and N length pairs of (1024,160), (2048,224), (2048,256), and (3072,256).
• Choose an N-bit prime q. N must be less than or equal to the hash output length.
• Choose an L-bit prime modulus p such that p–1 is a multiple of q.
• Choose g, a number whose multiplicative order modulo p is q. This may be done by setting g = h(p–1)/q mod p for
some arbitrary h (1 < h < p−1), and trying again with a different h if the result comes out as 1. Most choices of h
will lead to a usable g; commonly h=2 is used.
The algorithm parameters (p, q, g) may be shared between different users of the system.
Per-user keys
Given a set of parameters, the second phase computes private and public keys for a single user:
• Choose x by some random method, where 0 < x < q.
• Calculate y = gx mod p.
• Public key is (p, q, g, y). Private key is x.
There exist efficient algorithms for computing the modular exponentiations h(p–1)/q mod p and gx mod p, such as
exponentiation by squaring.
50
Signing
Let H be the hashing function and m the message:
•
•
•
•
•
•
Generate a random per-message value k where 0 < k < q
Calculate r = (gk mod p) mod q
In the unlikely case that r = 0, start again with a different random k
Calculate s = (k−1(H(m) + x·r)) mod q
In the unlikely case that s = 0, start again with a different random k
The signature is (r, s)
The first two steps amount to creating a new per-user key. The modular exponentiation here is the most
computationally expensive part of the signing operation, and it may be computed before the message hash is known.
The modular inverse k−1 mod q is the second most expensive part, and it may also be computed before the message
hash is known. It may be computed using the extended Euclidean algorithm or using Fermat's little theorem as
kq−2 mod q.
Verifying
• Reject the signature if 0 < r < q or 0 < s < q is not satisfied.
•
•
•
•
•
Calculate w = s−1 mod q
Calculate u1 = H(m)·w mod q
Calculate u2 = r·w mod q
Calculate v = ((gu1·yu2) mod p) mod q
The signature is valid if v = r
DSA is similar to the ElGamal signature scheme.
Correctness of the algorithm
The signature scheme is correct in the sense that the verifier will always accept genuine signatures. This can be
shown as follows:
First, if g = h(p − 1)/q mod p it follows that gq ≡ hp − 1 ≡ 1 (mod p) by Fermat's little theorem. Since g > 1 and q is
prime, g must have order q.
The signer computes
Thus
Since g has order q (mod p) we have
Finally, the correctness of DSA follows from
51
Sensitivity
With DSA, the entropy, secrecy and uniqueness of the random signature value k is critical. It is so critical that
violating any one of those three requirements can reveal your entire private key to an attacker.[10] Using the same
value twice (even while keeping k secret), using a predictable value, or leaking even a few bits of k in each of several
signatures, is enough to break DSA.[11]
References
[1] FIPS-186 (http:/ / www. itl. nist. gov/ fipspubs/ fip186. htm), the first version of the official DSA specification.
[2] FIPS-186-1 (http:/ / www. mozilla. org/ projects/ security/ pki/ nss/ fips1861. pdf), the first revision to the official DSA specification.
[3] FIPS-186-3 (http:/ / csrc. nist. gov/ publications/ fips/ fips186-3/ fips_186-3. pdf), the third and current revision to the official DSA
specification.
[4] http:/ / www. google. com/ patents?vid=5231668
[5] Dr. David W. Kravitz (http:/ / www. motorola. com/ mot/ doc/ 6/ 6221_MotDoc. htm)
[6] Werner Koch. DSA and patents (http:/ / lists. gnupg. org/ pipermail/ gnupg-devel/ 1997-December/ 014123. html)
[8] Minutes of the Sept. 94 meeting of the Computer System Security and Privacy Advisory Board (http:/ / csrc. nist. gov/ groups/ SMA/ ispab/
documents/ 94-rpt. txt)
[9] NIST 800-57 (http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-57/ sp800-57-Part1-revised2_Mar08-2007. pdf)
[10] The Debian PGP disaster that almost was. (http:/ / rdist. root. org/ 2009/ 05/ 17/ the-debian-pgp-disaster-that-almost-was/ )
[11] DSA k-value Requirements (http:/ / rdist. root. org/ 2010/ 11/ 19/ dsa-requirements-for-random-k-value/ )
External links
• FIPS-186 (http://www.itl.nist.gov/fipspubs/fip186.htm), the first version of the official DSA specification.
• FIPS-186, change notice No.1 (http://www.itl.nist.gov/fipspubs/186chg-1.htm), the first change notice to the
first version of the specification.
• FIPS-186-1 (http://www.mozilla.org/projects/security/pki/nss/fips1861.pdf), the first revision to the official
DSA specification.
• FIPS-186-3 (http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf), the third and current revision to
the official DSA specification.
• FIPS-186-3 Approval (http://csrc.nist.gov/publications/fips/fips186-3/frn-fips_186-3.pdf), Approval
announcement of the third revision to the official DSA specification.
• Recommendation for Key Management -- Part 1: general (http://csrc.nist.gov/publications/nistpubs/800-57/
sp800-57-Part1-revised2_Mar08-2007.pdf), NIST Special Publication 800-57, p. 62–63
52
HMAC
53
HMAC
In cryptography, HMAC (Hash-based
Message Authentication Code) is a
specific construction for calculating a
message authentication code (MAC)
involving a cryptographic hash
function in combination with a secret
key. As with any MAC, it may be used
to simultaneously verify both the data
integrity and the authenticity of a
message. Any cryptographic hash
function, such as MD5 or SHA-1, may
be used in the calculation of an
HMAC; the resulting MAC algorithm
is
termed
HMAC-MD5
or
HMAC-SHA1
accordingly.
The
cryptographic strength of the HMAC
depends upon the cryptographic
SHA-1 HMAC Generation.
strength of the underlying hash
function, the size of its hash output length in bits, and on the size and quality of the cryptographic key.
An iterative hash function breaks up a message into blocks of a fixed size and iterates over them with a compression
function. For example, MD5 and SHA-1 operate on 512-bit blocks. The size of the output of HMAC is the same as
that of the underlying hash function (128 or 160 bits in the case of MD5 or SHA-1, respectively), although it can be
truncated if desired.
The definition and analysis of the HMAC construction was first published in 1996 by Mihir Bellare, Ran Canetti,
and Hugo Krawczyk,[1] who also wrote RFC 2104. This paper also defined a variant called NMAC that is rarely if
ever used. FIPS PUB 198 generalizes and standardizes the use of HMACs. HMAC-SHA-1 and HMAC-MD5 are
used within the IPsec and TLS protocols.
Definition (from RFC 2104)
Let:
• H(·) be a cryptographic hash function
• K be a secret key padded to the right with extra zeros to the input block size of the hash function, or the hash of
the original key if it's longer than that block size
• m be the message to be authenticated
• ∥ denote concatenation
• ⊕ denote exclusive or (XOR)
• opad be the outer padding (0x5c5c5c…5c5c, one-block-long hexadecimal constant)
• ipad be the inner padding (0x363636…3636, one-block-long hexadecimal constant)
Then HMAC(K,m) is mathematically defined by
HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)).
HMAC
54
Implementation
The following pseudocode demonstrates how HMAC may be implemented. Blocksize is 64 (bytes) when using one
of the following hash functions: SHA-1, MD5, RIPEMD-128/160.[2]
function hmac (key, message)
if (length(key) > blocksize) then
key = hash(key) // keys longer than blocksize are shortened
end if
if (length(key) < blocksize) then
key = key ∥ [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded ('∥' is concatenation)
end if
o_key_pad = [0x5c * blocksize] ⊕ key // Where blocksize is that of the underlying hash function
i_key_pad = [0x36 * blocksize] ⊕ key // Where ⊕ is exclusive or (XOR)
return hash(o_key_pad ∥ hash(i_key_pad ∥ message)) // Where '∥' is concatenation
end function
The following is Python implementation of HMAC-MD5:
#!/usr/bin/env python
from hashlib import md5
class HMAC:
def __init__(self, key, msg):
self.outer = md5()
self.inner = md5()
self.digest_size = self.inner.digest_size
blocksize = 64
if len(key) > blocksize:
key = md5(key).digest()
key = key + chr(0) * (blocksize - len(key))
trans_5C = "".join ([chr (x ^ 0x5c) for x in xrange(256)])
trans_36 = "".join ([chr (x ^ 0x36) for x in xrange(256)])
self.outer.update(key.translate(trans_5C))
self.inner.update(key.translate(trans_36))
if msg:
self.inner.update(msg)
self.h = self.outer.copy()
self.h.update(self.inner.digest())
def hexdigest(self):
return self.h.hexdigest()
if __name__=="__main__":
h = HMAC("key","The quick brown fox jumps over the lazy dog")
print h.hexdigest() #80070713463e7749b90c2dc24911e275
HMAC
55
Example usage
A business that suffers from attackers that place fraudulent Internet orders may insist that all its customers deposit a
secret key with them. Along with an order, a customer must supply the order's HMAC digest, computed using the
customer's symmetric key. The business, knowing the customer's symmetric key, can then verify that the order
originated from the stated customer and has not been tampered with.
Design principles
The design of the HMAC specification was motivated by the existence of attacks on more trivial mechanisms for
combining a key with a hash function. For example, one might assume the same security that HMAC provides could
be achieved with MAC = H(key ∥ message). However, this method suffers from a serious flaw: with most hash
functions, it is easy to append data to the message without knowing the key and obtain another valid MAC. The
alternative, appending the key using MAC = H(message ∥ key), suffers from the problem that an attacker who can
find a collision in the (unkeyed) hash function has a collision in the MAC. Using MAC = H(key ∥ message ∥ key) is
better, however various security papers have suggested vulnerabilities with this approach, even when two different
keys are used.[1][3][4]
No known extensions attacks have been found against the current HMAC specification which is defined as H(key1 ∥
H(key2 ∥ message)) because the outer application of the hash function masks the intermediate result of the internal
hash. The values of ipad and opad are not critical to the security of the algorithm, but were defined in such a way to
have a large Hamming distance from each other and so the inner and outer keys will have fewer bits in common.
Security
The cryptographic strength of the HMAC depends upon the size of the secret key that is used. The most common
attack against HMACs is brute force to uncover the secret key. HMACs are substantially less affected by collisions
than their underlying hashing algorithms alone.[5] [6] .[7] Therefore, HMAC-MD5 does not suffer from the same
weaknesses that have been found in MD5.
In 2006, Jongsung Kim, Alex Biryukov, Bart Preneel, and Seokhie Hong showed how to distinguish HMAC with
reduced versions of MD5 and SHA-1 or full versions of HAVAL, MD4, and SHA-0 from a random function or
HMAC with a random function. Differential distinguishers allow an attacker to devise a forgery attack on HMAC.
Furthermore, differential and rectangle distinguishers can lead to second-preimage attacks. HMAC with the full
version of MD4 can be forged with this knowledge. These attacks do not contradict the security proof of HMAC, but
provide insight into HMAC based on existing cryptographic hash functions. [8]
At least theoretically a timing attack could be performed to find out a HMAC digit by digit.[9]
Examples of HMAC (MD5, SHA1, SHA256 )
Here are some empty HMAC values HMAC_MD5("", "") = 0x 74e6f7298a9c2d168935f58c001bad88
HMAC_SHA1("", "") = 0x fbdb1d1b18aa6c08324b7d64b71fb76370690e1d
HMAC_SHA256("", "") = 0x b613679a0814d9ec772f95d778c35fc5ff1697c493715653c6c712144292c5ad
Here are some non-empty HMAC values HMAC_MD5("key", "The quick brown fox jumps over the lazy dog") = 0x 80070713463e7749b90c2dc24911e275
HMAC_SHA1("key", "The quick brown fox jumps over the lazy dog") = 0x de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC_SHA256("key", "The quick brown fox jumps over the lazy dog") = 0x f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
Note: Input data+key are of the single-byte ANSI variety, and not two-byte Unicode characters
HMAC
56
External links
•
•
•
•
•
•
•
•
•
•
FIPS PUB 198, The Keyed-Hash Message Authentication Code [7]
PHP HMAC implementation [10]
Python HMAC implementation [11]
Perl HMAC implementation [12]
Ruby HMAC implementation [13]
C HMAC implementation [14]
Java implementation [15]
JavaScript MD5 and SHA HMAC implementation [16]
JavaScript SHA-only HMAC implementation [17]
.NET's System.Security.Cryptography.HMAC [18]
References
[1] Bellare, Mihir; Canetti, Ran; Krawczyk, Hugo (1996). "Keying Hash Functions for Message Authentication" (http:/ / citeseerx. ist. psu. edu/
viewdoc/ summary?doi=10. 1. 1. 134. 8430). .
[2] RFC 2104 (http:/ / tools. ietf. org/ html/ rfc2104), section 2, "Definition of HMAC", page 3.
[3] Preneel, Bart; van Oorschot, Paul C. (1995). "MDx-MAC and Building Fast MACs from Hash Functions" (http:/ / citeseerx. ist. psu. edu/
viewdoc/ summary?doi=10. 1. 1. 34. 3855). . Retrieved 2009-08-28.
[4] Preneel, Bart; van Oorschot, Paul C. (1995). "On the Security of Two MAC Algorithms" (http:/ / citeseerx. ist. psu. edu/ viewdoc/
summary?doi=10. 1. 1. 42. 8908). . Retrieved 2009-08-28.
[5] Bruce Schneier (August 2005). "SHA-1 Broken" (http:/ / www. schneier. com/ blog/ archives/ 2005/ 02/ sha1_broken. html). . Retrieved
2009-01-09. "although it doesn't affect applications such as HMAC where collisions aren't important"
[6] IETF (February 1997). "RFC 2104" (http:/ / www. ietf. org/ rfc/ rfc2104. txt). . Retrieved 2009-12-03. "The strongest attack known against
HMAC is based on the frequency of collisions for the hash function H ("birthday attack") [PV,BCK2], and is totally impractical for minimally
reasonable hash functions."
[7] Bellare, Mihir (June 2006). "New Proofs for NMAC and HMAC: Security without Collision-Resistance" (http:/ / cseweb. ucsd. edu/ ~mihir/
papers/ hmac-new. html). In Dwork, Cynthia. Advances in Cryptology – Crypto 2006 Proceedings. Lecture Notes in Computer Science 4117.
Springer-Verlag. . Retrieved 2010-05-25. "This paper proves that HMAC is a PRF under the sole assumption that the compression function is
a PRF. This recovers a proof based guarantee since no known attacks compromise the pseudorandomness of the compression function, and it
also helps explain the resistance-to-attack that HMAC has shown even when implemented with hash functions whose (weak) collision
resistance is compromised."
[8] Jongsung, Kim; Biryukov, Alex; Preneel, Bart; Hong, Seokhie (2006). On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5,
SHA-0 and SHA-1 (http:/ / eprint. iacr. org/ 2006/ 187. pdf). .
[9] Briefly mentioned at the end of this session Sebastian Schinzel:Time is on my Side - Exploiting Timing Side Channel Vulnerabilities on the
Web (http:/ / events. ccc. de/ congress/ 2011/ Fahrplan/ events/ 4640. en. html) 28th Chaos Communication Congress, 2011.
[10] http:/ / us2. php. net/ manual/ en/ function. hash-hmac. php
[11] http:/ / docs. python. org/ lib/ module-hmac. html
[12] http:/ / cpan. uwinnipeg. ca/ htdocs/ Digest-HMAC/ Digest/ HMAC. pm. html
[13] http:/ / ruby-hmac. rubyforge. org/
[14] http:/ / www. ouah. org/ ogay/ hmac/
[15] http:/ / download. oracle. com/ javase/ 1. 4. 2/ docs/ guide/ security/ jce/ JCERefGuide. html#HmacEx
[16] http:/ / pajhome. org. uk/ crypt/ md5/ instructions. html
[17] http:/ / jssha. sourceforge. net/
[18] http:/ / msdn. microsoft. com/ en-us/ library/ system. security. cryptography. hmac. aspx
Notes
• Mihir Bellare, Ran Canetti and Hugo Krawczyk, Keying Hash Functions for Message Authentication, CRYPTO
1996, pp1–15 (PS or PDF) (http://www-cse.ucsd.edu/users/mihir/papers/hmac.html#kmd5-paper).
• Mihir Bellare, Ran Canetti and Hugo Krawczyk, Message authentication using hash functions: The HMAC
construction, CryptoBytes 2(1), Spring 1996 (PS or PDF) (http://www-cse.ucsd.edu/users/mihir/papers/
hmac.html#hmac-cryptobytes).
HTTP Secure
57
HTTP Secure
HTTP
Persistence · Compression · HTTPS
Request methods
OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT
Header fields
Cookie · ETag · Location · Referer
DNT · X-Forwarded-For
Status codes
301 Moved permanently
302 Found
303 See Other
403 Forbidden
404 Not Found
Hypertext Transfer Protocol Secure (HTTPS) is a combination of Hypertext Transfer Protocol (HTTP) with
SSL/TLS protocol. It provides encrypted communication and secure identification of a network web server. HTTPS
connections are often used for payment transactions on the World Wide Web and for sensitive transactions in
corporate information systems.
HTTPS should not be confused with the little-used Secure HTTP (S-HTTP) specified in RFC 2660.
Overview
HTTPS is a URI scheme which has identical syntax to the standard HTTP scheme, aside from its scheme token.
However, HTTPS signals the browser to use an added encryption layer of SSL/TLS to protect the traffic. SSL is
especially suited for HTTP since it can provide some protection even if only one side of the communication is
authenticated. This is the case with HTTP transactions over the Internet, where typically only the server is
authenticated (by the client examining the server's certificate).
The main idea of HTTPS is to create a secure channel over an insecure network. This ensures reasonable protection
from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server
certificate is verified and trusted.
Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their
software. Certificate authorities (e.g. VeriSign/Microsoft/etc.) are in this way being trusted by web browser creators
to provide valid certificates. Logically, it follows that a user should trust an HTTPS connection to a website if and
only if all of the following are true:
1. The user trusts that the browser software correctly implements HTTPS with correctly pre-installed certificate
authorities.
2. The user trusts the certificate authority to vouch only for legitimate websites.
3. The website provides a valid certificate, which means it was signed by a trusted authority.
4. The certificate correctly identifies the website (e.g., when the browser visits "https://example.com", the
received certificate is properly for "Example Inc." and not some other entity).
5. Either the intervening hops on the Internet are trustworthy, or the user trusts that the protocol's encryption layer
(TLS/SSL) is sufficiently secure against eavesdroppers.
HTTP Secure
58
Browser integration
Most browsers display a warning if they receive an invalid certificate. Older browsers, when connecting to a site
with an invalid certificate, would present the user with a dialog box asking if they wanted to continue. Newer
browsers display a warning across the entire window. Newer browsers also prominently display the site's security
information in the address bar. Extended validation certificates turn the address bar green in newer browsers. Most
browsers also display a warning to the user when visiting a site that contains a mixture of encrypted and unencrypted
content.
Many web browsers, including Firefox (shown here), use the address
bar to tell the user that their connection is secure, often by coloring
the background.
Most web browsers alert the user when visiting sites that have invalid
security certificates. This example is from Firefox.
The Electronic Frontier Foundation, opining that "[i]n an ideal world, every web request could be defaulted to
HTTPS", has provided an add-on called "HTTPS Everywhere" for Mozilla Firefox that enables HTTPS by default
for several frequently used websites.[1][2]
Technical
Difference from HTTP
HTTPS URLs begin with "https://" and use port 443 by default, where HTTP URLs begin with "http://" and use port
80 by default.
HTTP is unsecured and is subject to man-in-the-middle and eavesdropping attacks, which can let attackers gain
access to website accounts and sensitive information. HTTPS is designed to withstand such attacks and is considered
secure against such attacks (with the exception of older deprecated versions of SSL).
Network layers
HTTP operates at the highest layer of the OSI Model, the Application layer; but the security protocol operates at a
lower sublayer, encrypting an HTTP message prior to transmission and decrypting a message upon arrival. Strictly
speaking, HTTPS is not a separate protocol, but refers to use of ordinary HTTP over an encrypted SSL/TLS
connection.
Everything in the HTTPS message is encrypted, including the headers, and the request/response load. With the
exception of the possible CCA cryptographic attack described in limitations section below, the attacker can only
know the fact that a connection is taking place between the two parties, already known to him, the domain name and
IP addresses.
HTTP Secure
Server setup
To prepare a web server to accept HTTPS connections, the administrator must create a public key certificate for the
web server. This certificate must be signed by a trusted certificate authority for the web browser to accept it without
warning. The authority certifies that the certificate holder is the operator of the web server that presents it. Web
browsers are generally distributed with a list of signing certificates of major certificate authorities so that they can
verify certificates signed by them.
Acquiring certificates
Authoritatively signed certificates may be free[3][4] or cost between US$8[5] and $1,500[6] per year. However, in the
case of free certificate authorities such as CACert, popular browsers (e.g. FireFox, Internet explorer) may not include
the trusted root certificates, which may cause untrusted warning messages to be displayed to end users.
Organizations may also run their own certificate authority, particularly if they are responsible for setting up browsers
to access their own sites (for example, sites on a company intranet, or major universities). They can easily add copies
of their own signing certificate to the trusted certificates distributed with the browser.
There also exists a peer-to-peer certificate authority, CACert.
Use as access control
The system can also be used for client authentication in order to limit access to a web server to authorized users. To
do this, the site administrator typically creates a certificate for each user, a certificate that is loaded into his/her
browser. Normally, that contains the name and e-mail address of the authorized user and is automatically checked by
the server on each reconnect to verify the user's identity, potentially without even entering a password.
In case of compromised private key
A certificate may be revoked before it expires, for example because the secrecy of the private key has been
compromised. Newer versions of popular browsers such as Google Chrome, Firefox,[7] Opera,[8] and Internet
Explorer on Windows Vista[9] implement the Online Certificate Status Protocol (OCSP) to verify that this is not the
case. The browser sends the certificate's serial number to the certificate authority or its delegate via OCSP and the
authority responds, telling the browser whether or not the certificate is still valid.[10]
Limitations
SSL comes in two options, simple and mutual.
The mutual version is more secure, but requires the user to install a personal certificate in their browser in order to
authenticate themselves.
Whatever strategy is used (simple or mutual), the level of protection strongly depends on the correctness of the
implementation of the web browser and the server software and the actual cryptographic algorithms supported.
SSL does not prevent the entire site from being indexed using a web crawler, and in some cases the URI of the
encrypted resource can be inferred by knowing only the intercepted request/response size.[11] This allows an attacker
to have access to the plaintext (the publicly-available static content), and the encrypted text (the encrypted version of
the static content), permitting a cryptographic attack.
Because SSL operates below HTTP and has no knowledge of higher-level protocols, SSL servers can only strictly
present one certificate for a particular IP/port combination.[12] This means that, in most cases, it is not feasible to use
name-based virtual hosting with HTTPS. A solution called Server Name Indication (SNI) exists, which sends the
hostname to the server before encrypting the connection, although many older browsers do not support this
extension. Support for SNI is available since Firefox 2, Opera 8, Safari 2.1, Google Chrome 6, and Internet Explorer
7 on Windows Vista.[13][14][15]
59
HTTP Secure
From an architectural point of view:
1. An SSL/TLS connection is managed by the first front machine that initiates the SSL connection. If, for any
reasons (routing, traffic optimization, etc.), this front machine is not the application server and it has to decipher
data, solutions have to be found to propagate user authentication informations or certificate to the application
server, which needs to know who is going to be connected.
2. For SSL with mutual authentication, the SSL/TLS session is managed by the first server that initiates the
connection. In situations where encryption has to be propagated along chained servers, session timeOut
management becomes extremely tricky to implement.
3. With mutual SSL/TLS, security is maximal, but on the client-side, there is no way to properly end the SSL
connection and disconnect the user except by waiting for the SSL server session to expire or closing all related
client applications.
4. For performance reasons, static content that is not specific to the user or transaction, and thus not private, is
usually delivered through a non-crypted front server or separate server instance with no SSL. As a consequence,
this content is usually not protected. Many browsers warn the user when a page has mixed encrypted and
non-encrypted resources.
A sophisticated type of man-in-the-middle attack was presented at the Blackhat Conference 2009. This type of attack
defeats the security provided by HTTPS by changing the https: link into an http: link, taking advantage of
the fact that few Internet users actually type "https" into their browser interface: they get to a secure site by clicking
on a link, and thus are fooled into thinking that they are using HTTPS when in fact they are using HTTP. The
attacker then communicates in clear with the client.[16]
In May, 2010, a research paper[17] by researchers from Microsoft Research and Indiana University discovered that
detailed sensitive user data can be inferred from side channels such as packet sizes. More specifically, the
researchers found that an eavesdropper can infer the illnesses/medications/surgeries of the user, her family income
and investment secrets, despite HTTPS protection in several high-profile, top-of-the-line web applications in
healthcare, taxation, investment and web search. This finding points out a unique challenge on information leaks that
HTTPS faces on the era of web 2.0.
History
Netscape Communications created HTTPS in 1994 for its Netscape Navigator web browser.[18] Originally, HTTPS
was used with SSL protocol. As SSL evolved into Transport Layer Security (TLS), the current version of HTTPS
was formally specified by RFC 2818 in May 2000.
References
[1] Peter Eckersley: Encrypt the Web with the HTTPS Everywhere Firefox Extension (https:/ / www. eff. org/ deeplinks/ 2010/ 06/
encrypt-web-https-everywhere-firefox-extension) EFF blog, 17 June 2010
[2] HTTPS Everywhere (https:/ / www. eff. org/ https-everywhere)
[3] "Free SSL Certificates from a Free Certificate Authority" (http:/ / www. sslshopper. com/
article-free-ssl-certificates-from-a-free-certificate-authority. html). sslshopper.com. . Retrieved 2009-10-24.
[4] Justin Fielding (2007-07-16). "Secure Outlook Web Access with (free) SSL: Part 1" (http:/ / www. techrepublic. com/ blog/ networking/
secure-outlook-web-access-with-free-ssl-part-1/ 293). TechRepublic. . Retrieved 2009-10-24.
[5] "Namecheap.com SSL Services" (https:/ / www. namecheap. com/ ssl-certificates/ comodo/ positivessl-certificate. aspx). namecheap. .
Retrieved 30 jan 2012.
[6] "Secure Site Pro with EV" (http:/ / www. verisign. com/ ssl/ buy-ssl-certificates/ extended-validation-pro-ssl-certificates/ index. html).
VeriSign. . Retrieved 6 May 2009.
[7] "Mozilla Firefox Privacy Policy" (http:/ / www. mozilla. com/ en-US/ legal/ privacy/ firefox-en. html). Mozilla Foundation. 27 April 2009. .
Retrieved 13 May 2009.
[8] "Opera 8 launched on FTP" (http:/ / news. softpedia. com/ news/ Opera-8-launched-on-FTP-1330. shtml). Softpedia. 19 April 2005. .
Retrieved 13 May 2009.
60
HTTP Secure
[9] Lawrence, Eric (31 January 2006). "HTTPS Security Improvements in Internet Explorer 7" (http:/ / msdn. microsoft. com/ en-us/ library/
bb250503. aspx). MSDN. . Retrieved 13 May 2009.
[10] Myers, M; Ankney, R; Malpani, A; Galperin, S; Adams, C (June 1999). "Online Certificate Status Protocol - OCSP" (http:/ / tools. ietf. org/
html/ rfc2560). Internet Engineering Task Force. . Retrieved 13 May 2009.
[11] Pusep, Stanislaw (31 July 2008). "The Pirate Bay un-SSL" (http:/ / sysd. org/ stas/ node/ 220). . Retrieved 6 March 2009.
[12] Apache FAQ: Why can't I use SSL with name-based/non-IP-based virtual hosts? (http:/ / httpd. apache. org/ docs/ 2. 0/ ssl/ ssl_faq.
html#vhosts)
[13] Lawrence, Eric (22 October 2005). "Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2" (http:/ / blogs. msdn. com/ ie/ archive/
2005/ 10/ 22/ 483795. aspx). Microsoft. . Retrieved 12 May 2009.
[14] Server Name Indication (SNI) (http:/ / blog. ebrahim. org/ 2006/ 02/ 21/ server-name-indication-sni/ )
[15] Pierre, Julien. "Browser support for TLS server name indication" (https:/ / bugzilla. mozilla. org/ show_bug. cgi?id=116169) (2001-12-19).
Bugzilla. Mozilla Foundation. . Retrieved 2010-12-15.
[16] "sslstrip" (http:/ / www. thoughtcrime. org/ software/ sslstrip/ index. html). . Retrieved 2011-11-26.
[17] Shuo Chen, Rui Wang, XiaoFeng Wang, and Kehuan Zhang (May, 2010). "Side-Channel Leaks in Web Applications: a Reality Today, a
Challenge Tomorrow" (http:/ / research. microsoft. com/ pubs/ 119060/ WebAppSideChannel-final. pdf). IEEE Symposium on Security &
Privacy 2010. .
[18] Walls, Colin (2005). Embedded software (http:/ / books. google. com/ books?id=FLvsis4_QhEC& pg=PA344). pp. 344. .
External links
• RFC 2818: HTTP Over TLS (http://tools.ietf.org/html/rfc2818)
•
•
•
•
•
•
SSL 3.0 Specification (http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00) (IETF)
HTTPS Everywhere (https://www.eff.org/https-everywhere/) created by Electronic Frontier Foundation
Wikipedia with HTTPS protocol (https://www.wikipedia.org/)
Apache-SSL homepage (http://www.apache-ssl.org/) (No longer actively developed)
Apache 2.2 mod_ssl documentation (http://httpd.apache.org/docs/2.2/ssl/)
HTTPS Protocol in Internet Explorer Development - MSDN (http://msdn2.microsoft.com/en-us/library/
aa767735(VS.85).aspx)
• Manually Configuring Windows Communication Foundation (WCF) when using HTTP and HTTPS - MSDN
(http://msdn2.microsoft.com/en-us/library/ms733768.aspx)
• HTTPS Security Improvements in Internet Explorer 7 & its Compatibility Impact - MSDN (http://msdn2.
microsoft.com/en-us/library/bb250503.aspx)
• HTTP versus HTTPS (http://www.biztechmagazine.com/article/2007/07/http-vs-https), a clear explanation
61
IPsec
IPsec
Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by
authenticating and encrypting each IP packet of a communication session. IPsec also includes protocols for
establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic
keys to be used during the session.
IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite. It can be used in
protecting data flows between a pair of hosts (host-to-host), between a pair of security gateways
(network-to-network), or between a security gateway and a host (network-to-host).[1]
Some other Internet security systems in widespread use, such as Secure Sockets Layer (SSL), Transport Layer
Security (TLS) and Secure Shell (SSH), operate in the upper layers of the TCP/IP model. The use of TLS/SSL must
be designed into an application to protect the application protocols. In contrast, applications do not need to be
specifically designed to use IPsec. Hence, IPsec protects any application traffic across an IP network.
IPsec originally was developed at the Naval Research Laboratory as part of a DARPA-sponsored research project.
ESP was derived directly from the SP3D protocol, rather than being derived from the ISO Network-Layer Security
Protocol (NLSP). The SP3D protocol specification was published by NIST, but designed by the Secure Data
Network System project of the National Security Agency (NSA), IPsec AH is derived in part from previous IETF
standards work for authentication of the Simple Network Management Protocol (SNMP).
IPsec is officially specified by the Internet Engineering Task Force (IETF) in a series of Request for Comments
documents addressing various components and extensions. It specifies the spelling of the protocol name to be
IPsec.[2]
Security architecture
The IPsec suite is an open standard. IPsec uses the following protocols to perform various functions:[3][4]
• Authentication Headers (AH) provide connectionless integrity and data origin authentication for IP datagrams and
provides protection against replay attacks.[5][6]
• Encapsulating Security Payloads (ESP) provide confidentiality, data origin authentication, connectionless
integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.[1]
• Security Associations (SA) provide the bundle of algorithms and data that provide the parameters necessary to
operate the AH and/or ESP operations. The Internet Security Association and Key Management Protocol
(ISAKMP) provides a framework for authentication and key exchange,[7] with actual authenticated keying
material provided either by manual configuration with pre-shared keys, Internet Key Exchange (IKE and IKEv2),
Kerberized Internet Negotiation of Keys (KINK), or IPSECKEY DNS records.[8][9][10][11]
Authentication Header
Authentication Header (AH) is a member of the IPsec protocol suite. AH guarantees connectionless integrity and
data origin authentication of IP packets. Further, it can optionally protect against replay attacks by using the sliding
window technique and discarding old packets (see below).
• In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for mutable fields (i.e.
those that might be altered in transit), and also IP options such as the IP Security Option (RFC-1108). Mutable
(and therefore unauthenticated) IPv4 header fields are DSCP/TOS, ECN, Flags, Fragment Offset, TTL and
Header Checksum.[6]
• In IPv6, the AH protects the most of the IPv6 base header, AH itself, non-mutable extension headers after the AH,
and the IP payload. Protection for the IPv6 header excludes the mutable fields: DSCP, ECN, Flow Label, and Hop
62
IPsec
63
Limit.[6]
AH operates directly on top of IP, using IP protocol number 51.[12]
The following AH packet diagram shows how an AH packet is constructed and interpreted:[5][6]
Authentication Header format
Offsets Octet16
0
1
2
Octet16
Bit10
0
0
4
32
Security Parameters Index (SPI)
8
64
Sequence Number
C
96
…
…
Integrity Check Value (ICV)
…
3
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next Header
Payload Len
Reserved
Next Header (8 bits)
Type of the next header, indicating what upper-layer protocol was protected. The value is taken from the list of
IP protocol numbers.
Payload Len (8 bits)
The length of this Authentication Header in 4-octet units, minus 2 (a value of 0 means 8 octets, 1 means 12
octets, etcetera). Although the size is measured in 4-octet units, the length of this header needs to be a multiple
of 8 octets if carried in an IPv6 packet. This restriction does not apply to an Authentication Header carried in
an IPv4 packet.
Reserved (16 bits)
Reserved for future use (all zeroes until then).
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the destination IP address) to identify the security association of
the receiving party.
Sequence Number (32 bits)
A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to prevent replay
attacks. When replay detection is enabled, sequence numbers are never reused because a new security
association must be renegotiated before an attempt to increment the sequence number beyond its maximum
value.[6]
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a
4-octet boundary for IPv4.
Encapsulating Security Payload
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin
authenticity, integrity, and confidentiality protection of packets. ESP also supports encryption-only and
authentication-only configurations, but using encryption without authentication is strongly discouraged because it is
insecure.[13][14][15] Unlike Authentication Header (AH), ESP in transport mode does not provide integrity and
authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated
with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header)
while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP
IPsec
64
operates directly on top of IP, using IP protocol number 50.[12]
The following ESP packet diagram shows how an ESP packet is constructed and interpreted:[1][16]
Encapsulating Security Payload format
Offsets Octet16
0
1
2
3
Octet16
Bit10
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0
0
Security Parameters Index (SPI)
4
32
Sequence Number
8
64
Payload data
…
…
…
…
…
…
…
…
…
…
…
…
Padding (0-255 octets)
Pad Length
Next Header
Integrity Check Value (ICV)
…
Security Parameters Index (32 bits)
Arbitrary value which is used (together with the destination IP address) to identify the security association of
the receiving party.
Sequence Number (32 bits)
A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against
replay attacks. There is a separate counter kept for every security association.
Payload data (variable)
The protected contents of the original IP packet, including any data used to protect the contents (e.g. an
Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by
the Next Header field.
Padding (0-255 octets)
Padding for encryption, to extend the payload data to a size that fits the encryption's cypher block size, and to
align the next field.
Pad Length (8 bits)
Size of the padding in octets.
Next Header (8 bits)
Type of the next header. The value is taken from the list of IP protocol numbers.
Integrity Check Value (multiple of 32 bits)
Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a
4-octet boundary for IPv4.
IPsec
Security association
The IP security architecture uses the concept of a security association as the basis for building security functions into
IP. A security association is simply the bundle of algorithms and parameters (such as keys) that is being used to
encrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows are
secured by a pair of security associations.
Security associations are established using the Internet Security Association and Key Management Protocol
(ISAKMP). ISAKMP is implemented by manual configuration with pre-shared secrets, Internet Key Exchange (IKE
and IKEv2), Kerberized Internet Negotiation of Keys (KINK), and the use of IPSECKEY DNS records.[11][17][18]
In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index
(SPI), an index to the security association database (SADB), along with the destination address in a packet header,
which together uniquely identify a security association for that packet. A similar procedure is performed for an
incoming packet, where IPsec gathers decryption and verification keys from the security association database.
For multicast, a security association is provided for the group, and is duplicated across all authorized receivers of the
group. There may be more than one security association for a group, using different SPIs, thereby allowing multiple
levels and sets of security within a group. Indeed, each sender can have multiple security associations, allowing
authentication, since a receiver can only know that someone knowing the keys sent the data. Note that the relevant
standard does not describe how the association is chosen and duplicated across the group; it is assumed that a
responsible party will have made the choice.
Modes of operation
IPsec can be implemented in a host-to-host transport mode, as well as in a network tunnel mode.
Transport mode
In transport mode, only the payload (the data you transfer) of the IP packet is usually encrypted and/or authenticated.
The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header
is used, the IP addresses cannot be translated, as this will invalidate the hash value. The transport and application
layers are always secured by hash, so they cannot be modified in any way (for example by translating the port
numbers). Transport mode is used for host-to-host communications.
A means to encapsulate IPsec messages for NAT traversal has been defined by RFC documents describing the
NAT-T mechanism.
Tunnel mode
In tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated into a new IP packet
with a new IP header. Tunnel mode is used to create virtual private networks for network-to-network
communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access), and
host-to-host communications (e.g. private chat).
Tunnel mode supports NAT traversal.
65
IPsec
Cryptographic algorithms
Cryptographic algorithms defined for use with IPsec include:
• HMAC-SHA1 for integrity protection and authenticity.
• TripleDES-CBC for confidentiality
• AES-CBC for confidentiality.
Refer to RFC 4835 for details.
Software implementations
IPsec support is usually implemented in the kernel with key management and ISAKMP/IKE negotiation carried out
from user-space. Existing IPsec implementations often include both.
There exist a number of implementations of IPsec and ISAKMP/IKE protocols. These include:
• NRL[19] IPsec, where the AH and ESP protocols were developed, and the original implementer of open-source
IPsec for 4.4 BSD.[20]
• OpenBSD, with its own code derived from a BSD/OS implementation written by John Ioannidis and Angelos D.
Keromytis in 1996.
• The KAME stack, that is included in Mac OS X, NetBSD and FreeBSD.
• "IPsec" in Juniper Operating Systems [21]
• "IPsec" in Cisco IOS Software [22]
• "IPsec" in Microsoft Windows, including Windows XP,[23][24] Windows 2000,[25] Windows 2003,[26] Windows
Vista, Windows Server 2008,[27] and Windows 7.[28]
• IPsec in Windows Vista and later
Authentec QuickSec toolkits[29]
IPsec in Solaris[30]
IBM AIX operating system
IBM z/OS
IPsec and IKE in HP-UX (HP-UX IPsec)
The Linux IPsec stack written by Alexey Kuznetsov and David S. Miller.
Openswan on Linux, FreeBSD and Mac OS X using the native Linux IPsec stack, or its own KLIPS stack. KLIPS
offers hardware acceleration and SAref tracking.
• strongSwan on Linux, FreeBSD, Mac OS X, and Android using the native IPsec stack.
•
•
•
•
•
•
•
Standards status
IPsec was developed in conjunction with IPv6 and must be available in all standards-compliant implementations of
IPv6 although not all IPv6 implementations include IPsec support;[31] it is optional for IPv4 implementations.
However, because of the slow deployment of IPv6, IPsec is most commonly used to secure IPv4 traffic. IPsec
protocols were originally defined in RFC 1825 and RFC 1829, published in 1995. In 1998, these documents were
superseded by RFC 2401 and RFC 2412 with incompatible aspects, although they were conceptually identical. In
addition, a mutual authentication and key exchange protocol Internet Key Exchange (IKE) was defined to create and
manage security associations. In December 2005, new standards were defined in RFC 4301 and RFC 4309 which are
largely a superset of the previous editions with a second version of the Internet Key Exchange standard IKEv2.
These third-generation documents standardized the abbreviation of IPsec to uppercase “IP” and lowercase “sec”. It is
unusual to see any product that offers support for RFCs 1825 and 1829. “ESP” generally refers to RFC 2406, while
ESPbis refers to RFC 4303.
Since mid-2008, an IPsec Maintenance and Extensions working group is active at the IETF.[32][33]
66
IPsec
References
[1] Kent, S.; Atkinson, R. (November 1998). IP Encapsulating Security Payload (ESP) (http:/ / tools. ietf. org/ html/ rfc2406). IETF. RFC 2406. .
[2] "RFC4301: Security Architecture for the Internet Protocol" (http:/ / tools. ietf. org/ html/ rfc4301#page-4). Network Working Group of the
IETF. December 2005. p. 4. . "The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other
capitalizations of IPsec [...] are deprecated."
[3] Thayer, R.; Doraswamy, N.; Glenn, R. (November 1998). IP Security Document Roadmap (http:/ / tools. ietf. org/ html/ rfc2411). IETF. RFC
2411. .
[4] Hoffman, P. (December 2005). Cryptographic Suites for IPsec (http:/ / tools. ietf. org/ html/ rfc4308). IETF. RFC 4308. .
[5] Kent, S.; Atkinson, R. (November 1998). IP Authentication Header (http:/ / tools. ietf. org/ html/ rfc2402). IETF. RFC 2402. .
[6] Kent, S. (December 2005). IP Authentication Header (http:/ / tools. ietf. org/ html/ rfc4302). IETF. RFC 4302. .
[7] The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
[8] Harkins, D.; Carrel, D. (November 1998). The Internet Key Exchange (IKE) (http:/ / tools. ietf. org/ html/ rfc2409). IETF. RFC 2409. .
[9] Kaufman, C., ed. IKE Version 2 (http:/ / tools. ietf. org/ html/ rfc4306). IETF. RFC 4306. .
[10] Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (November 1998). Kerberized Internet Negotiation of Keys (KINK) (http:/ / tools. ietf.
org/ html/ rfc4430). IETF. RFC 4430. .
[11] Richardson, M. (February 2005). A Method for Storing IPsec Keying Material in DNS (http:/ / tools. ietf. org/ html/ rfc4025). IETF. RFC
4025. .
[12] "Protocol Numbers" (http:/ / www. webcitation. org/ 5rXTFZt87). IANA. IANA. 2010-05-27. Archived from the original (http:/ / www. iana.
org/ assignments/ protocol-numbers/ protocol-numbers. xml) on 2010-07-27. .
[13] Bellovin, Steven M. (1996). "Problem Areas for the IP Security Protocols" (http:/ / www. cs. columbia. edu/ ~smb/ papers/ badesp. ps)
(PostScript). Proceedings of the Sixth Usenix Unix Security Symposium. San Jose, CA. pp. 1–16. . Retrieved 2007-07-09.
[14] Paterson, Kenneth G.; Yau, Arnold K.L. (2006-04-24). "Cryptography in theory and practice: The case of encryption in IPsec" (http:/ /
eprint. iacr. org/ 2005/ 416) (PDF). Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004. Berlin. pp. 12–29. . Retrieved 2007-08-13.
[15] Degabriele, Jean Paul; Paterson, Kenneth G. (2007-08-09). "Attacking the IPsec Standards in Encryption-only Configurations" (http:/ /
eprint. iacr. org/ 2007/ 125) (PDF). IEEE Symposium on Security and Privacy, IEEE Computer Society. Oakland, CA. pp. 335–349. .
[16] Kent, S. (December 2005). IP Encapsulating Security Payload (ESP) (http:/ / tools. ietf. org/ html/ rfc4303). IETF. RFC 4303. .
[17] RFC 2406, §1, page 2
[18] RFC 3129
[19] "Information Technology Division, Naval Research Laboratory" (http:/ / www. itd. nrl. navy. mil/ ). NRL ITD. 2009-10-29. . Retrieved
2010-12-31.
[20] "Best Software Review" (http:/ / ezine. daemonnews. org/ 199812/ security. html). Daemon News. . Retrieved 2010-12-31.
[21] Worldwide. "Internet Protocol Security (IPsec) - JUNOS Software Security Configuration Guide" (http:/ / www. juniper. net/ techpubs/
software/ junos-security/ junos-security95/ junos-security-swconfig-security/ ipsec-chapter. html). Juniper Networks. . Retrieved 2011-05-04.
[22] Worldwide. "An Introduction to IP Security (IPSec) Encryption [IPSec Negotiation/IKE Protocols]" (http:/ / www. cisco. com/ en/ US/ tech/
tk583/ tk372/ technologies_tech_note09186a0080094203. shtml). Cisco Systems. . Retrieved 2010-12-31.
[23] "Modifying an Internet Protocol security (IPSec) policy from a Windows XP SP1-based or Windows 2000-based client may corrupt the
IPSec policy" (http:/ / support. microsoft. com/ ?kbid=884909). Microsoft Support. 2006-12-25. . Retrieved 2010-12-31.
[24] "L2TP/IPsec NAT-T update for Windows XP and Windows 2000" (http:/ / support. microsoft. com/ kb/ 818043/ en-us). Microsoft Support.
2006-10-26. . Retrieved 2010-12-31.
[25] (http:/ / www. microsoft. com/ windows2000/ technologies/ communications/ ipsec/ default. mspx)
[26] (http:/ / www. microsoft. com/ windowsserver2003/ technologies/ networking/ ipsec/ default. mspx)
[27] "IPsec" (http:/ / technet. microsoft. com/ en-us/ network/ bb531150. aspx). Microsoft TechNet. . Retrieved 2010-12-31.
[28] "Windows Firewall with Advanced Security Getting Started Guide" (http:/ / technet. microsoft. com/ en-us/ library/ cc748991(WS. 10).
aspx). Microsoft TechNet. . Retrieved 2010-12-31.
[29] "Products | Toolkits" (http:/ / www. authentec. com/ toolkits. cfm). AuthenTec. . Retrieved 2010-12-31.
[30] "IPsec and IKE Administration Guide" (http:/ / docs. sun. com/ app/ docs/ doc/ 817-2694?a=expand). Sun Microsystems. 2003-12-09. .
[31] Loughney, J., ed (April 2006). IPv6 Node Requirements (http:/ / tools. ietf. org/ html/ rfc4294& #035;section-8. 1). IETF. sec. 8.1. RFC
4294. .
[32] ipsecme charter (http:/ / www. ietf. org/ html. charters/ ipsecme-charter. html)
[33] ipsecme status (http:/ / tools. ietf. org/ wg/ ipsecme/ )
67
IPsec
External links
• All IETF active security WGs (http://www.ietf.org/html.charters/wg-dir.html#Security Area)
• IETF ipsecme WG (http://datatracker.ietf.org/wg/ipsecme/) ("IP Security Maintenance and Extensions"
Working Group)
• IETF btns WG (http://www.ietf.org/html.charters/btns-charter.html) ("Better-Than-Nothing Security"
Working Group) (chartered to work on unauthenticated IPsec, IPsec APIs, connection latching)]
• Securing Data in Transit with IPsec (http://www.windowsecurity.com/articles/
Securing_Data_in_Transit_with_IPSec.html) WindowsSecurity.com article by Deb Shinder
• IPsec (http://search.dmoz.org/cgi-bin/search?search=ipsec) at the Open Directory Project
• IPsec (http://www.microsoft.com/ipsec) on Microsoft TechNet
• Microsoft IPsec Diagnostic Tool (http://www.microsoft.com/downloads/details.
aspx?FamilyID=1d4c292c-7998-42e4-8786-789c7b457881&displaylang=en) on Microsoft Download Center
• An Illustrated Guide to IPsec (http://www.unixwiz.net/techtips/iguide-ipsec.html) by Steve Friedl
• Security Architecture for IP (IPsec) (http://www.ict.tuwien.ac.at/lva/384.081/infobase/L97-IPsec_v4-7.
pdf) Data Communication Lectures by Manfred Lindner Part IPsec
• Creating VPNs with IPsec and SSL/TLS (http://www.linuxjournal.com/article/9916) Linux Journal article by
Rami Rosen
Standards
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RFC 2367: PF_KEY Interface
RFC 2401: Security Architecture for the Internet Protocol (IPsec overview) Obsolete by RFC 4301
RFC 2403: The Use of HMAC-MD5-96 within ESP and AH
RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2409: The Internet Key Exchange
RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec
RFC 2412: The OAKLEY Key Determination Protocol
RFC 2451: The ESP CBC-Mode Cipher Algorithms
RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH
RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements
RFC 3947: Negotiation of NAT-Traversal in the IKE
RFC 3948: UDP Encapsulation of IPsec ESP Packets
RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
RFC 4301: Security Architecture for the Internet Protocol
RFC 4302: IP Authentication Header
RFC 4303: IP Encapsulating Security Payload
RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet
Security Association and Key Management Protocol (ISAKMP)
• RFC 4306: Internet Key Exchange (IKEv2) Protocol
• RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
• RFC 4308: Cryptographic Suites for IPsec
• RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload
(ESP)
• RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
68
IPsec
•
•
•
•
•
•
•
RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4718: IKEv2 Clarifications and Implementation Guidelines
RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4809: Requirements for an IPsec Certificate Management Profile
RFC 4835: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)
• RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
• RFC 6071: IPsec and IKE Document Roadmap
69
Kerberos (protocol)
70
Kerberos (protocol)
Stable release krb5-1.9.2 / November 2, 2011
Website
web.mit.edu/kerberos/
[1]
Kerberos ( /ˈkɛərbərəs/) is a computer network authentication protocol which works on the basis of "tickets" to
allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its
designers aimed primarily at a client–server model, and it provides mutual authentication—both the user and the
server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay
attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use
public-key cryptography by utilizing asymmetric key cryptography during certain phases of authentication.[2]
Kerberos uses port 88 by default.
"Kerberos" also refers to a suite of free software published by Massachusetts Institute of Technology (MIT) that
implements the Kerberos protocol.
History and development
MIT developed Kerberos to protect network services provided by Project Athena. The protocol was named after the
character Kerberos (or Cerberus) from Greek mythology which was a monstrous three-headed guard dog of Hades.
Several versions of the protocol exist; versions 1–3 occurred only internally at MIT.
Steve Miller and Clifford Neuman, the primary designers of Kerberos version 4, published that version in the late
1980s, although they had targeted it primarily for Project Athena.
Version 5, designed by John Kohl and Clifford Neuman, appeared as RFC 1510 in 1993 (made obsolete by RFC
4120 in 2005), with the intention of overcoming the limitations and security problems of version 4.
MIT makes an implementation of Kerberos freely available, under copyright permissions similar to those used for
BSD. In 2007, MIT formed the Kerberos Consortium to foster continued development. Founding sponsors include
vendors such as Oracle, Apple Inc., Google, Microsoft, Centrify Corporation and TeamF1 Inc., and academic
institutions such as KTH-Royal Institute of Technology, Stanford University, MIT and vendors such as CyberSafe
offering commercially supported versions.
Authorities in the United States classified Kerberos as auxiliary military technology and banned its export because it
used the DES encryption algorithm (with 56-bit keys). A non-US Kerberos 4 implementation, KTH-KRB developed
at the Royal Institute of Technology in Sweden, made the system available outside the US before the US changed its
cryptography export regulations (circa 2000). The Swedish implementation was based on a limited version called
eBones. eBones was based on the exported MIT Bones release (stripped of both the encryption functions and the
calls to them) based on version Kerberos 4 patch-level 9.
Windows 2000 and later use Kerberos as their default authentication method. Some Microsoft additions to the
Kerberos suite of protocols are documented in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and
Set Password Protocols". RFC 4757 documents Microsoft's use of the RC4 cipher. While Microsoft uses the
Kerberos protocol, it does not use the MIT software.
Many UNIX and UNIX-like operating systems, including FreeBSD, Apple's Mac OS X, Red Hat Enterprise Linux 4,
Oracle's Solaris, IBM's AIX, HP's OpenVMS, and others, include software for Kerberos authentication of users or
services. Embedded implementation of the Kerberos V authentication protocol for client agents and network services
running on embedded platforms is also available from companies such as TeamF1, Inc.
As of 2005, the IETF Kerberos working group is updating the specifications. Recent updates include:
• Encryption and Checksum Specifications" (RFC 3961).
Kerberos (protocol)
71
• Advanced Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962).
• A new edition of the Kerberos V5 specification "The Kerberos Network Authentication Service (V5)" (RFC
4120). This version obsoletes RFC 1510, clarifies aspects of the protocol and intended use in a more detailed and
clearer explanation.
• A new edition of the GSS-API specification "The Kerberos Version 5 Generic Security Service Application
Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).
Protocol
Theory
Kerberos uses as its basis the symmetric Needham-Schroeder protocol. It makes use of a trusted third party, termed a
key distribution center (KDC), which consists of two theoretically independent roles: an Authentication Server (AS)
and a Ticket Granting Server (TGS).
The KDC maintains a database of secret keys; each entity on the network — whether a client or a server — shares a
secret key known only to itself and to the KDC. Knowledge of this key serves to prove an entity's identity. For
communication purposes the KDC generates a session key which communicating parties use to encrypt their
transmissions.
The security of the protocol relies heavily on short-lived assertions of authenticity called Kerberos tickets.
Description
The client authenticates itself to the AS which forwards the username to a Key Distribution Center (KDC). The KDC
issues a Ticket Granting Ticket (TGT), which is time stamped, encrypts it using the user's password and returns the
encrypted result to the user's workstation. If successful, this gives the user desktop access.
When the client needs to communicate with another node ("principal" in Kerberos parlance) it sends the TGT to the
Ticket Granting Service (TGS), which shares the same host as the TGT. After verifying the TGT is valid and the
user is permitted to access the requested service, the TGS issues a Ticket and session keys, which are returned to the
client.
The client then sends the Ticket and keys to the service (SS).
Here is another description.
The client authenticates to the AS once using a long-term shared secret
(e.g. a password) and receives a Ticket Granting Ticket (TGT) from
the AS. Later, when the client wants to contact some SS, it can (re)use
this ticket to get additional tickets from TGS, for SS, without resorting
to using the shared secret. The latter tickets can be used to prove
authentication to the SS.
The phases are detailed below.
User Client-based Logon
Kerberos negotiations
1. A user enters a username and password on the client machine.
2. The client performs a one-way function (hash usually) on the entered password, and this becomes the secret key
of the client/user.
Kerberos (protocol)
72
Client Authentication
1. The client sends a cleartext message of the user ID to the AS
requesting services on behalf of the user. (Note: Neither the secret
key nor the password is sent to the AS.) The AS generates the secret
key by hashing the password of the user found at the database (e.g.
Active Directory in Windows Server).
2. The AS checks to see if the client is in its database. If it is, the AS
sends back the following two messages to the client:
• Message A: Client/TGS Session Key encrypted using the secret
key of the client/user.
Kerberos Protocol
• Message B: Ticket-Granting-Ticket (which includes the client ID, client network address, ticket validity
period, and the client/TGS session key) encrypted using the secret key of the TGS.
3. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from
the password entered by the user. If the user entered password does not match the password in the AS database,
the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret
key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further
communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret
key.) At this point, the client has enough information to authenticate itself to the TGS.
Client Service Authorization
1. When requesting services, the client sends the following two messages to the TGS:
• Message C: Composed of the TGT from message B and the ID of the requested service.
• Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the
Client/TGS Session Key.
2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using
the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D
(Authenticator) and sends the following two messages to the client:
• Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and
Client/Server Session Key) encrypted using the service's secret key.
• Message F: Client/server session key encrypted with the Client/TGS Session Key.
Client Service Request
1. Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS.
The client connects to the SS and sends the following two messages:
• Message E from the previous step (the client-to-server ticket, encrypted using service's secret key).
• Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server
session key.
2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions
key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and
willingness to serve the client:
• Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session
Key.
3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is
correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.
4. The server provides the requested services to the client.
Kerberos (protocol)
Drawbacks and Limitations
• Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down,
no one can log in. This can be mitigated by using multiple Kerberos servers and fallback authentication
mechanisms.
• Kerberos has strict time requirements, which means the clocks of the involved hosts must be synchronized within
configured limits. The tickets have a time availability period and if the host clock is not synchronized with the
Kerberos server clock, the authentication will fail. The default configuration per MIT [3] requires that clock times
are no more than five minutes apart. In practice Network Time Protocol daemons are usually used to keep the host
clocks synchronized.
• The administration protocol is not standardized and differs between server implementations. Password changes
are described in RFC 3244 [4].
• Since all authentication is controlled by a centralized KDC, compromise of this authentication infrastructure will
allow an attacker to impersonate any user.
Related Requests For Comments
• RFC 4120 — The Kerberos Network Authentication Service (V5)
•
•
•
•
•
•
RFC 4537 — Kerberos Cryptosystem Negotiation Extension
RFC 4752 — The Kerberos V5 (GSSAPI) Simple Authentication and Security Layer (SASL) Mechanism
RFC 6111 — Additional Kerberos Naming Constraints
RFC 6112 — Anonymity Support for Kerberos
RFC 6113 — A Generalized Framework for Kerberos Pre-Authentication
RFC 6251 — Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
References
[1]
[2]
[3]
[4]
http:/ / web. mit. edu/ kerberos/
RFC 4556, abstract
http:/ / web. mit. edu/ Kerberos/ krb5-1. 5/ krb5-1. 5. 4/ doc/ krb5-admin/ Clock-Skew. html
http:/ / www. ietf. org/ rfc/ rfc3244. txt
Notes
• SDK Team. "Microsoft Kerberos (Windows)" (http://msdn.microsoft.com/en-us/library/aa378747(VS.85).
aspx). MSDN Library.
• B. Clifford Neuman and Theodore Ts'o (September 1994). "Kerberos: An Authentication Service for Computer
Networks" (http://gost.isi.edu/publications/kerberos-neuman-tso.html). IEEE Communications 32 (9): 33–8.
doi:10.1109/35.312841.
• John T. Kohl, B. Clifford Neuman, and Theodore Y. T'so (1994). "The Evolution of the Kerberos Authentication
System" (ftp://athena-dist.mit.edu/pub/kerberos/doc/krb_evol.PS). In Johansen, D.; Brazier, F. M. T.
(Postscript). Distributed open systems. Washington: IEEE Computer Society Press. pp. 78–94.
ISBN 0-8186-4292-0.
• Cisco Systems Kerberos Overview- An Authentication Service for Open Network Systems (http://www.cisco.
com/en/US/tech/tk59/technologies_white_paper09186a00800941b2.shtml)
73
Kerberos (protocol)
External links
• How Kerberos Authentication Works (http://learn-networking.com/network-security/
how-kerberos-authentication-works)
• Kerberos page (http://web.mit.edu/kerberos/) at MIT
• Kerberos Working Group at IETF (http://www.ietf.org/html.charters/krb-wg-charter.html)
• Kerberos Consortium (http://www.kerberos.org/) at MIT
• White Papers (http://www.kerberos.org/software/whitepapers.html) at MIT
• Vendor Documentation and Specifications (http://www.kerberos.org/docs/links.html) at MIT
• Kerberos How-to (http://www.kerberos.org/software/adminkerberos.pdf)
• The Kerberos FAQ (http://www.faqs.org/faqs/kerberos-faq/general/) (last modified 8/18/2000)
• Shishi, a free Kerberos implementation for the GNU system (http://josefsson.org/shishi/)
• Designing an Authentication System: A Dialogue in Four Scenes. Humorous play concerning how the design of
Kerberos evolved. (http://web.mit.edu/kerberos/www/dialogue.html)
• Description of Kerberos 5 in the SPORE library (http://www.lsv.ens-cachan.fr/spore/kerberos.html)
• Kerberos Authentication in Windows Server 2003 (http://www.microsoft.com/windowsserver2003/
technologies/security/kerberos/default.mspx)
• Kerberos Tutorial (http://www.kerberos.org/software/tutorial.html)
• Novell Inc's Comment to the Proposed Settlement between Microsoft and the Department of Justice - Microsoft
purposefully breaks Kerberos interoperability (http://www.usdoj.gov/atr/cases/ms_tuncom/major/
mtc-00029523.htm)
• Kerberos in FreeBSD (http://www.freebsd.org/doc/en/books/handbook/kerberos5.html)
• Embedded Kerberos Implementation (http://teamf1.com/home/product/authagent-kerberos/) by TeamF1
• Heimdal, an implementation of Kerberos 5 (http://www.h5l.org/)
In cryptography, a key distribution center (KDC) is part of a cryptosystem intended to reduce the risks inherent in
exchanging keys. KDCs often operate in systems within which some users may have permission to use certain
services at some times and not at others.
Security overview
For instance, an administrator may have established a policy that only certain users may use the tape backup facility.
(Perhaps the administrator has concerns that unrestricted use might result in someone smuggling out a tape
containing important information; but the precise reason does not matter for the purpose of explaining the
functioning of the key distribution center.) Many operating systems can control access to the tape facility via a
'system service'. If that system service further restricts the tape drive to operate on behalf only of users who can
submit a service-granting ticket when they wish to use it, there remains only the task of distributing such tickets to
the appropriately permitted users. If the ticket consists of (or includes) a key, we can then term the mechanism which
distributes it a KDC. Usually, in such situations, the KDC itself also operates as a system service.
74
Operation
A typical operation with a KDC involves a request from a user to use some service. The KDC will use cryptographic
techniques to authenticate requesting users as themselves. It will also check whether an individual user has the right
to access the service requested. If the authenticated user meets all prescribed conditions, the KDC can issue a ticket
permitting access.
KDCs mostly operate with symmetric encryption.
In most (but not all) cases the KDC shares a key with each of all the other parties.
The KDC produces a ticket based on a server key.
The client receives the ticket and submits it to the appropriate server.
The server can verify the submitted ticket and grant access to the user submitting it.
Security systems using KDCs include Kerberos.
Benefits
• Easier key distribution
• Scalability
Drawbacks
• A KDC can become a single point of failure
• Everybody must trust the KDC
• Vulnerable to replay attack
External links
• Kerberos 5 KDC operation [1]
References
[1] http:/ / www. zeroshell. net/ eng/ kerberos/ Kerberos-operation/
75
In cryptography, a message authentication code (often MAC) is a short piece of information used to authenticate a
message.
A MAC algorithm, sometimes called a keyed (cryptographic) hash function, accepts as input a secret key and an
arbitrary-length message to be authenticated, and outputs a MAC (sometimes known as a tag). The MAC value
protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret
key) to detect any changes to the message content.
Security
While MAC functions are similar to cryptographic hash functions, they possess different security requirements. To
be considered secure, a MAC function must resist existential forgery under chosen-plaintext attacks. This means that
even if an attacker has access to an oracle which possesses the secret key and generates MACs for messages of the
attacker's choosing, the attacker cannot guess the MAC for other messages without performing infeasible amounts of
computation.
MACs differ from digital signatures as MAC values are both generated and verified using the same secret key. This
implies that the sender and receiver of a message must agree on the same key before initiating communications, as is
the case with symmetric encryption. For the same reason, MACs do not provide the property of non-repudiation
offered by signatures specifically in the case of a network-wide shared secret key: any user who can verify a MAC is
also capable of generating MACs for other messages. In contrast, a digital signature is generated using the private
key of a key pair, which is asymmetric encryption. Since this private key is only accessible to its holder, a digital
signature proves that a document was signed by none other than that holder. Thus, digital signatures do offer
non-repudiation.
Message integrity codes
The term message integrity code (MIC) is frequently substituted for the term MAC, especially in communications,[1]
where the acronym MAC traditionally stands for Media Access Control. However, some authors[2] use MIC as a
distinctly different term from a MAC; in their usage of the term the MIC operation does not use secret keys. This
lack of security means that any MIC intended for use gauging message integrity should be encrypted or otherwise be
protected against tampering. MIC algorithms are created such that a given message will always produce the same
MIC assuming the same algorithm is used to generate both. Conversely, MAC algorithms are designed to produce
matching MACs only if the same message, secret key and initialization vector are input to the same algorithm. MICs
do not use secret keys and, when taken on their own, are therefore a much less reliable gauge of message integrity
than MACs. Because MACs use secret keys, they do not necessarily need to be encrypted to provide the same level
of assurance.
76
Implementation
MAC algorithms can be constructed from other cryptographic primitives, such as cryptographic hash functions (as in
the case of HMAC) or from block cipher algorithms (OMAC, CBC-MAC and PMAC). However many of the fastest
MAC algorithms such as UMAC and VMAC are constructed based on universal hashing.[3]
Standards
Various standards exist that define MAC algorithms. These include:
• FIPS PUB 113 Computer Data Authentication,[4] withdrawn in 2002,[5] defines an algorithm based on DES.
• ISO/IEC 9797-1 Mechanisms using a block cipher[6]
• ISO/IEC 9797-2 Mechanisms using a dedicated hash-function[7]
ISO/IEC 9797-1 and -2 define generic models and algorithms that can be used with any block cipher or hash
function, and a variety of different parameters. These models and parameters allow more specific algorithms to be
defined by nominating the parameters. For example the FIPS PUB 113 algorithm is functionally equivalent to
ISO/IEC 9797-1 MAC algorithm 1 with padding method 1 and a block cipher algorithm of DES.
Example
In this example, the sender of a message runs it through a MAC algorithm to produce a MAC data tag. The message
and the MAC tag are then sent to the receiver. The receiver in turn runs the message portion of the transmission
through the same MAC algorithm using the same key, producing a second MAC data tag. The receiver then
compares the first MAC tag received in the transmission to the second generated MAC tag. If they are identical, the
receiver can safely assume that the integrity of the message was not compromised, and the message was not altered
or tampered with during transmission.
77
78
External links
• RSA Laboratories entry on MACs [8]
• Ron Rivest lecture on MACs [9]
References
[1] IEEE 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (http:/ / standards. ieee. org/
getieee802/ download/ 802. 11-2007. pdf). (2007 revision). IEEE-SA. 12 June 2007. doi:10.1109/IEEESTD.2007.373646. .
[2] Fred B Schneider, Hashes and Message Digests, Cornell University (http:/ / www. cs. cornell. edu/ courses/ cs513/ 2005fa/ NL20. hashing.
html)
[3] "VMAC: Message Authentication Code using Universal Hashing" (http:/ / www. fastcrypto. org/ vmac/ draft-krovetz-vmac-01. txt). CFRG
Working Group (CFRG Working Group). . Retrieved 16 March 2010.
[4] FIPS PUB 113 Computer Data Authentication (http:/ / www. itl. nist. gov/ fipspubs/ fip113. htm)
[5] Federal Information Processing Standards Publications, Withdrawn FIPS Listed by Number (http:/ / www. itl. nist. gov/ fipspubs/ withdraw.
htm)
[6] ISO/IEC 9797-1 Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a
block cipher (http:/ / www. iso. org/ iso/ iso_catalogue/ catalogue_tc/ catalogue_detail. htm?csnumber=30656)
[7] ISO/IEC 9797-2 Information technology — Security techniques — Message Authentication Codes (MACs) — Part 2: Mechanisms using a
dedicated hash-function (http:/ / www. iso. org/ iso/ iso_catalogue/ catalogue_tc/ catalogue_detail. htm?csnumber=31136)
[8] http:/ / www. rsasecurity. com/ rsalabs/ node. asp?id=2177
[9] http:/ / web. mit. edu/ 6. 857/ OldStuff/ Fall97/ lectures/ lecture3. pdf
Needham–Schroeder protocol
The term Needham–Schroeder protocol can refer to one of two communication protocols intended for use over an
insecure network, both proposed by Roger Needham and Michael Schroeder.[1] These are:
• The Needham–Schroeder Symmetric Key Protocol is based on a symmetric encryption algorithm. It forms the
basis for the Kerberos protocol. This protocol aims to establish a session key between two parties on a network,
typically to protect further communication.
• The Needham–Schroeder Public-Key Protocol, based on public-key cryptography. This protocol is intended to
provide mutual authentication between two parties communicating on a network, but in its proposed form is
insecure.
The symmetric protocol
Here, Alice (A) initiates the communication to Bob (B). S is a server trusted by both parties. In the communication:
•
•
•
•
•
A and B are identities of Alice and Bob respectively
KAS is a symmetric key known only to A and S
KBS is a symmetric key known only to B and S
NA and NB are nonces generated by A and B respectively
KAB is a symmetric, generated key, which will be the session key of the session between A and B
The protocol can be specified as follows in security protocol notation:
Alice sends a message to the server identifying herself and Bob, telling the server she wants to communicate
with Bob.
The server generates
and sends back to Alice a copy encrypted under
for Alice to forward to Bob
and also a copy for Alice. Since Alice may be requesting keys for several different people, the nonce assures
NeedhamSchroeder protocol
79
Alice that the message is fresh and that the server is replying to that particular message and the inclusion of
Bob's name tells Alice who she is to share this key with.
Alice forwards the key to Bob who can decrypt it with the key he shares with the server, thus authenticating
the data.
Bob sends Alice a nonce encrypted under
to show that he has the key.
Alice performs a simple operation on the nonce, re-encrypts it and sends it back verifying that she is still alive
and that she holds the key.
Attacks on the protocol
The protocol is vulnerable to a replay attack (as identified by Denning and Sacco[2]). If an attacker uses an older,
compromised value for KAB, he can then replay the message
to Bob, who will accept it, being
unable to tell that the key is not fresh.
Fixing the attack
This flaw is fixed in the Kerberos protocol by the inclusion of a timestamp. It can also be fixed with the use of
nonces as described below.[3] At the beginning of the protocol:
Alice sends to Bob a request.
Bob responds with a nonce encrypted under his key with the Server.
Alice sends a message to the server identifying herself and Bob, telling the server she wants to communicate
with Bob.
Note the inclusion of the nonce.
The protocol then continues as described through the final three steps as described in the original protocol above.
Note that
is a different nonce from
.The inclusion of this new nonce prevents the replaying of a
compromised version of
since such a message would need to be of the form
which the attacker can't forge since she does not have
.
The public-key protocol
This assumes the use of a public-key encryption algorithm.
Here, Alice (A) and Bob (B) use a trusted server (S) to distribute public keys on request. These keys are:
• KPA and KSA, respectively public and private halves of an encryption key-pair belonging to A
• KPB and KSB, similar belonging to B
• KPS and KSS, similar belonging to S. (Note this has the property that KSS is used to encrypt and KPS to decrypt).
The protocol runs as follows:
A requests B's public keys from S
S responds with public key KPB alongside B's identity, signed by the server for authentication purposes.
A invents NA and sends it to B.
B requests A's public keys.
Server responds.
B invents NB, and sends it to A along with NA to prove ability to decrypt with KSB.
A confirms NB to B, to prove ability to decrypt with KSA
At the end of the protocol, A and B know each other's identities, and know both NA and NB. These nonces are not
known to eavesdroppers.
An attack on the protocol
Unfortunately, this protocol is vulnerable to a man-in-the-middle attack. If an impostor I can persuade A to initiate a
session with him, he can relay the messages to B and convince B that he is communicating with A.
Ignoring the traffic to and from S, which is unchanged, the attack runs as follows:
A sends NA to I, who decrypts the message with KSI
I relays the message to B, pretending that A is communicating
B sends NB
I relays it to A
A decrypts NB and confirms it to I, who learns it
I re-encrypts NB, and convinces B that he's decrypted it
At the end of the attack, B falsely believes that A is communicating with him, and that NA and NB are known only to
A and B.
80
Fixing the man-in-the-middle attack
The attack was first described in a 1995 paper by Gavin Lowe.[4] The paper also describes a fixed version of the
scheme, referred to as the Needham-Schroeder-Lowe protocol. The fix involves the modification of message six,
that is we replace:
with the fixed version:
References
[1] Needham, Roger; Schroeder, Michael (December 1978). "Using encryption for authentication in large networks of computers.".
Communications of the ACM 21 (12): 993–999. doi:10.1145/359657.359659
[2] Denning, Dorothy E.; Sacco, Giovanni Maria (1981). "Timestamps in key distributed protocols". Communication of the ACM 24 (8):
533–535. doi:10.1145/358722.358740.
[3] Needham, R. M.; Schroeder, M. D. (1987). "Authentication revisited". ACM SIGOPS Operating Systems Review 21 (1): 7.
doi:10.1145/24592.24593.
[4] Lowe, Gavin (November 1995). "An attack on the Needham-Schroeder public key authentication protocol." (http:/ / web. comlab. ox. ac. uk/
oucl/ work/ gavin. lowe/ Security/ Papers/ NSPKP. ps). Information Processing Letters 56 (3): 131–136. doi:10.1016/0020-0190(95)00144-2.
. Retrieved 2008-04-17
External links
• http://www.lsv.ens-cachan.fr/spore/nspk.html - description of the Public-key protocol
• http://www.lsv.ens-cachan.fr/spore/nssk.html - the Symmetric-key protocol
• http://www.lsv.ens-cachan.fr/spore/nspkLowe.html - the public-key protocol amended by Lowe
81
Pretty Good Privacy
82
Pretty Good Privacy
Pretty Good Privacy
Original author(s) Phil Zimmermann
Developer(s)
Phil Zimmermann
Initial release
In 1991
Written in
Multi-language
Operating system
Linux, Mac OS X, Windows
Website
http:/ / www. openpgp. org
Pretty Good Privacy (PGP) is a data encryption and decryption computer program that provides cryptographic
privacy and authentication for data communication. PGP is often used for signing, encrypting and decrypting texts,
E-mails, files, directories and whole disk partitions to increase the security of e-mail communications. It was created
by Phil Zimmermann in 1991.
PGP and similar products follow the OpenPGP standard (RFC 4880) for encrypting and decrypting data.
How PGP encryption works
PGP encryption uses a serial combination of hashing, data compression, symmetric-key cryptography, and, finally,
public-key cryptography; each step uses one of several supported algorithms. Each public key is bound to a user
name and/or an e-mail address. The first version of this system was generally known as a web of trust to contrast
with the X.509 system which uses a hierarchical approach based on certificate authority and which was added to
PGP implementations later. Current versions of PGP encryption include both options through an automated key
management server.
Compatibility
As PGP evolves, PGP systems that support newer features and algorithms are able to create encrypted messages that
older PGP systems cannot decrypt, even with a valid private key. Thus, it is essential that partners in PGP
communication understand each other's capabilities or at least agree on PGP settings.
Confidentiality
PGP can be used to send messages confidentially. For this, PGP combines symmetric-key encryption and public-key
encryption. The message is encrypted using a symmetric encryption algorithm, which requires a symmetric key.
Each symmetric key is used only once and is also called a session key. The session key is protected by encrypting it
with the receiver's public key thus ensuring that only the receiver can decrypt the session key. The encrypted
message along with the encrypted session key is sent to the receiver.
Digital signatures
PGP supports message authentication and integrity checking. The latter is used to detect whether a message has been
altered since it was completed (the message integrity property), and the former to determine whether it was actually
sent by the person/entity claimed to be the sender (a digital signature). In PGP, these are used by default in
conjunction with encryption, but can be applied to the plaintext as well. The sender uses PGP to create a digital
signature for the message with either the RSA or DSA signature algorithms. To do so, PGP computes a hash (also
called a message digest) from the plaintext, and then creates the digital signature from that hash using the sender's
Pretty Good Privacy
private key.
Web of trust
Both when encrypting messages and when verifying signatures, it is critical that the public key used to send
messages to someone or some entity actually does 'belong' to the intended recipient. Simply downloading a public
key from somewhere is not overwhelming assurance of that association; deliberate (or accidental) impersonation is
possible. PGP has, from its first versions, always included provisions for distributing a user's public keys in an
'identity certificate' which is also constructed cryptographically so that any tampering (or accidental garble) is readily
detectable. But merely making a certificate which is impossible to modify without being detected effectively is also
insufficient. It can prevent corruption only after the certificate has been created, not before. Users must also ensure
by some means that the public key in a certificate actually does belong to the person/entity claiming it. From its first
release, PGP products have included an internal certificate 'vetting scheme' to assist with this; a trust model which
has been called a web of trust. A given public key (or more specifically, information binding a user name to a key)
may be digitally signed by a third party user to attest to the association between someone (actually a user name) and
the key. There are several levels of confidence which can be included in such signatures. Although many programs
read and write this information, few (if any) include this level of certification when calculating whether to trust a
key.
The web of trust protocol was first described by Zimmermann in 1992 in the manual for PGP version 2.0:
As time goes on, you will accumulate keys from other people that you may want to designate as trusted
introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually
accumulate and distribute with their key a collection of certifying signatures from other people, with the
expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the
emergence of a decentralized fault-tolerant web of confidence for all public keys.
The web of trust mechanism has advantages over a centrally managed public key infrastructure scheme such as that
used by S/MIME but has not been universally used. Users have been willing to accept certificates and check their
validity manually or to simply accept them. No satisfactory solution has been found for the underlying problem.
Certificates
In the (more recent) OpenPGP specification, trust signatures can be used to support creation of certificate
authorities. A trust signature indicates both that the key belongs to its claimed owner and that the owner of the key is
trustworthy to sign other keys at one level below their own. A level 0 signature is comparable to a web of trust
signature since only the validity of the key is certified. A level 1 signature is similar to the trust one has in a
certificate authority because a key signed to level 1 is able to issue an unlimited number of level 0 signatures. A level
2 signature is highly analogous to the trust assumption users must rely on whenever they use the default certificate
authority list (like those included in web browsers); it allows the owner of the key to make other keys certificate
authorities.
PGP versions have always included a way to cancel ('revoke') identity certificates. A lost or compromised private
key will require this if communication security is to be retained by that user. This is, more or less, equivalent to the
certificate revocation lists of centralized PKI schemes. Recent PGP versions have also supported certificate
expiration dates.
The problem of correctly identifying a public key as belonging to a particular user is not unique to PGP. All public
key / private key cryptosystems have the same problem, if in slightly different guise, and no fully satisfactory
solution is known. PGP's original scheme, at least, leaves the decision whether or not to use its endorsement/vetting
system to the user, while most other PKI schemes do not, requiring instead that every certificate attested to by a
central certificate authority be accepted as correct.
83
Pretty Good Privacy
Security quality
To the best of publicly available information, there is no known method which will allow a person or group to break
PGP encryption by cryptographic or computational means. Indeed, in 1996, cryptographer Bruce Schneier
characterized an early version as being "the closest you're likely to get to military-grade encryption."[1] Early
versions of PGP have been found to have theoretical vulnerabilities and so current versions are recommended. In
addition to protecting data in transit over a network, PGP encryption can also be used to protect data in long-term
data storage such as disk files. These long-term storage options are also known as data at rest, i.e. data stored, not in
transit.
The cryptographic security of PGP encryption depends on the assumption that the algorithms used are unbreakable
by direct cryptanalysis with current equipment and techniques. For instance, in the original version, the RSA
algorithm was used to encrypt session keys; RSA's security depends upon the one-way function nature of
mathematical integer factoring.[2] Likewise, the symmetric key algorithm used in PGP version 2 was IDEA, which
might, at some future time, be found to have a previously unsuspected cryptanalytic flaw. Specific instances of
current PGP, or IDEA, insecurities—if they exist—are not publicly known. As current versions of PGP have added
additional encryption algorithms, the degree of their cryptographic vulnerability varies with the algorithm used. In
practice, each of the algorithms in current use is not publicly known to have cryptanalytic weaknesses.
New versions of PGP are released periodically and vulnerabilities that developers are aware of are progressively
fixed. Any agency wanting to read PGP messages would probably use easier means than standard cryptanalysis, e.g.
rubber-hose cryptanalysis or black-bag cryptanalysis i.e. installing some form of trojan horse or keystroke logging
software/hardware on the target computer to capture encrypted keyrings and their passwords. The FBI has already
used this attack against PGP[3][4] in its investigations. However, any such vulnerabilities apply not just to PGP, but to
all encryption software.
In 2003, an incident involving seized Psion PDAs belonging to members of the Red Brigade indicated that neither
the Italian police nor the FBI were able to decrypt PGP-encrypted files stored on them.[5]
A more recent incident in December 2006 (see United States v. Boucher) involving US customs agents and a seized
laptop PC which allegedly contained child pornography indicates that US Government agencies find it "nearly
impossible" to access PGP-encrypted files. Additionally, a judge ruling on the same case in November 2007 has
stated that forcing the suspect to reveal his PGP passphrase would violate his Fifth Amendment rights i.e. a suspect's
constitutional right not to incriminate himself.[6][7] The Fifth Amendment issue has been opened again as the case
was appealed and the federal judge again ordered the defendant to provide the key.[8]
Evidence suggests that as of 2007, British police investigators are unable to break PGP,[9] so instead have resorted to
using RIPA legislation to demand the passwords/keys. In November 2009 a British citizen was convicted under
RIPA legislation and jailed for 9 months for refusing to provide police investigators with encryption keys to
PGP-encrypted files.[10]
History
Early history
Phil Zimmermann created the first version of PGP encryption in 1991. The name, "Pretty Good Privacy", is
humorously ironic and was inspired by the name of a grocery store, "Ralph's Pretty Good Grocery", featured in radio
host Garrison Keillor's fictional town, Lake Wobegon. This first version included a symmetric-key algorithm that
Zimmermann had designed himself, named BassOmatic after a Saturday Night Live sketch. Zimmermann had been a
long-time anti-nuclear activist, and created PGP encryption so that similarly inclined people might securely use
BBSs and securely store messages and files. No license was required for its non-commercial use. There was not even
a nominal charge, and the complete source code was included with all copies.
84
Pretty Good Privacy
In a posting of June 5, 2001, entitled "PGP Marks 10th Anniversary",[11] Zimmermann describes the circumstances
surrounding his release of PGP:
"It was on this day in 1991 that I sent the first release of PGP to a couple of my friends for uploading to the
Internet. First, I sent it to Allan Hoeltje, who posted it to Peacenet, an ISP that specialized in grassroots
political organizations, mainly in the peace movement. Peacenet was accessible to political activists all over
the world. Then, I uploaded it to Kelly Goen, who proceeded to upload it to a Usenet newsgroup that
specialized in distributing source code. At my request, he marked the Usenet posting as "US only". Kelly also
uploaded it to many BBS systems around the country. I don't recall if the postings to the Internet began on
June 5th or 6th.
It may be surprising to some that back in 1991, I did not yet know enough about Usenet newsgroups to realize
that a "US only" tag was merely an advisory tag that had little real effect on how Usenet propagated
newsgroup postings. I thought it actually controlled how Usenet routed the posting. But back then, I had no
clue how to post anything on a newsgroup, and didn't even have a clear idea what a newsgroup was."
PGP found its way onto the Internet, and it very rapidly acquired a considerable following around the world. Users
and supporters included dissidents in totalitarian countries (some affecting letters to Zimmermann have been
published, and some have been included in testimony before the US Congress), civil libertarians in other parts of the
world (see Zimmermann's published testimony in various hearings), and the 'free communications' activists who call
themselves cypherpunks (who provided both publicity and distribution).
Criminal investigation
Shortly after its release, PGP encryption found its way outside the United States, and in February 1993 Zimmermann
became the formal target of a criminal investigation by the US Government for "munitions export without a license".
Cryptosystems using keys larger than 40 bits were then considered munitions within the definition of the US export
regulations; PGP has never used keys smaller than 128 bits so it qualified at that time. Penalties for violation, if
found guilty, were substantial. After several years, the investigation of Zimmermann was closed without filing
criminal charges against him or anyone else.
Zimmermann challenged these regulations in a curious way. He published the entire source code of PGP in a
hardback book,[12] via MIT Press, which was distributed and sold widely. Anybody wishing to build their own copy
of PGP could buy the $60 book, cut off the covers, separate the pages, and scan them using an OCR program,
creating a set of source code text files. One could then build the application using the freely available GNU Compiler
Collection. PGP would thus be available anywhere in the world. The claimed principle was simple: export of
munitions—guns, bombs, planes, and software—was (and remains) restricted; but the export of books is protected by
the First Amendment. The question was never tested in court with respect to PGP. In cases addressing other
encryption software, however, two federal appeals courts have established the rule that cryptographic software
source code is speech protected by the First Amendment (the Ninth Circuit Court of Appeals in the Bernstein case
and the Sixth Circuit Court of Appeals in the Junger case).
US export regulations regarding cryptography remain in force, but were liberalized substantially throughout the late
1990s. Since 2000, compliance with the regulations is also much easier. PGP encryption no longer meets the
definition of a non-exportable weapon, and can be exported internationally except to 7 specific countries and a list of
named groups and individuals[13] (with whom substantially all US trade is prohibited under various US export
controls).
85
Pretty Good Privacy
PGP 3 and founding of PGP Inc.
During this turmoil, Zimmermann's team worked on a new version of PGP encryption called PGP 3. This new
version was to have considerable security improvements, including a new certificate structure which fixed small
security flaws in the PGP 2.x certificates as well as permitting a certificate to include separate keys for signing and
encryption. Furthermore, the experience with patent and export problems led them to eschew patents entirely. PGP 3
introduced use of the CAST-128 (a.k.a. CAST5) symmetric key algorithm, and the DSA and ElGamal asymmetric
key algorithms, all of which were unencumbered by patents.
After the Federal criminal investigation ended in 1996, Zimmermann and his team started a company to produce new
versions of PGP encryption. They merged with Viacrypt (to whom Zimmermann had sold commercial rights and
who had licensed RSA directly from RSADSI) which then changed its name to PGP Incorporated. The newly
combined Viacrypt/PGP team started work on new versions of PGP encryption based on the PGP 3 system. Unlike
PGP 2, which was an exclusively command line program, PGP 3 was designed from the start as a software library
allowing users to work from a command line or inside a GUI environment. The original agreement between Viacrypt
and the Zimmermann team had been that Viacrypt would have even-numbered versions and Zimmermann
odd-numbered versions. Viacrypt, thus, created a new version (based on PGP 2) that they called PGP 4. To remove
confusion about how it could be that PGP 3 was the successor to PGP 4, PGP 3 was renamed and released as PGP 5
in May 1997.
OpenPGP
Inside PGP Inc., there was still concern about patent issues. RSADSI was challenging the continuation of the
Viacrypt RSA license to the newly merged firm. The company adopted an informal internal standard called
"Unencumbered PGP": "use no algorithm with licensing difficulties". Because of PGP encryption's importance
worldwide (it is thought to be the most widely chosen quality cryptographic system), many wanted to write their own
software that would interoperate with PGP 5. Zimmermann became convinced that an open standard for PGP
encryption was critical for them and for the cryptographic community as a whole. In July 1997, PGP Inc. proposed
to the IETF that there be a standard called OpenPGP. They gave the IETF permission to use the name OpenPGP to
describe this new standard as well as any program that supported the standard. The IETF accepted the proposal and
started the OpenPGP Working Group.
OpenPGP is on the Internet Standards Track and is under active development. The current specification is RFC 4880
(November 2007), the successor to RFC 2440. Many e-mail clients provide OpenPGP-compliant email security as
described in RFC 3156.
The Free Software Foundation has developed its own OpenPGP-compliant program called GNU Privacy Guard
(abbreviated GnuPG or GPG). GnuPG is freely available together with all source code under the GNU General
Public License (GPL) and is maintained separately from several Graphical User Interfaces (GUIs) that interact with
the GnuPG library for encryption, decryption and signing functions (see KGPG, Seahorse, MacGPG). Several other
vendors have also developed OpenPGP-compliant software.
Network Associates acquisition
In December 1997, PGP Inc. was acquired by Network Associates, Inc. ("NAI"). Zimmermann and the PGP team
became NAI employees. NAI was the first company to have a legal export strategy by publishing source code. Under
NAI, the PGP team added disk encryption, desktop firewalls, intrusion detection, and IPsec VPNs to the PGP family.
After the export regulation liberalizations of 2000 which no longer required publishing of source, NAI stopped
releasing source code.
In early 2001, Zimmermann left NAI. He served as Chief Cryptographer for Hush Communications, who provide an
OpenPGP-based e-mail service, Hushmail. He has also worked with Veridis and other companies. In October, 2001,
NAI announced that its PGP assets were for sale and that it was suspending further development of PGP encryption.
86
Pretty Good Privacy
The only remaining asset kept was the PGP E-Business Server (the original PGP Commandline version). In February
2002, NAI canceled all support for PGP products, with the exception of the re-named commandline product. NAI
(now McAfee) continues to sell and support the product under the name McAfee E-Business Server.
Current situation
In August 2002, several ex-PGP team members formed a new company, PGP Corporation, and bought the PGP
assets (except for the command line version) from NAI. The new company was funded by Rob Theis of Doll Capital
Management (DCM) and Terry Garnett of Venrock Associates. PGP Corporation supports existing PGP users and
honors NAI's support contracts. Zimmermann now serves as a special advisor and consultant to PGP Corporation, as
well as continuing to run his own consulting company. In 2003, PGP Corporation created a new server-based
product called PGP Universal. In mid-2004, PGP Corporation shipped its own command line version called PGP
Command Line, which integrates with the other PGP Encryption Platform applications. In 2005, PGP Corporation
made its first acquisition—the German software company Glück & Kanja Technology AG,[14] which is now PGP
Deutschland AG.[15] In 2010, PGP Corporation acquired Hamburg-based certificate authority TC TrustCenter and its
parent company, ChosenSecurity, to form its PGP TrustCenter[16] division.[17]
Since the 2002 purchase of NAI's PGP assets, PGP Corporation has offered worldwide PGP technical support from
its offices in Draper, Utah, Offenbach, Germany and Tokyo, Japan.
On April 29, 2010 Symantec Corp. announced that it would acquire PGP for $300 million with the intent of
integrating it into its Enterprise Security Group.[18] This acquisition was finalized and announced to the public on
June 7, 2010. The source code of PGP Desktop 10 is available for peer review.[19]
PGP Corporation encryption applications
This section describes commercial programs available from PGP Corporation. For information on other
programs compatible with the OpenPGP specification, see OpenPGP implementations below.
While originally used primarily for encrypting the contents of e-mail messages and attachments from a desktop
client, PGP products have been diversified since 2002 into a set of encryption applications which can be managed by
an optional central policy server. PGP encryption applications include e-mail and attachments, digital signatures,
laptop full disk encryption, file and folder security, protection for IM sessions, batch file transfer encryption, and
protection for files and folders stored on network servers and, more recently, encrypted and/or signed HTTP
request/responses by means of a client side (Enigform) and a server side (mod openpgp) module. There is also a
Wordpress plugin available, called wp-enigform-authentication, that takes advantage of the session management
features of Enigform with mod_openpgp.
The PGP Desktop 9.x family includes PGP Desktop Email, PGP Whole Disk Encryption, and PGP NetShare.
Additionally, a number of Desktop bundles are also available. Depending on application, the products feature
desktop e-mail, digital signatures, IM security, whole disk encryption, file and folder security, self decrypting
archives, and secure shredding of deleted files. Capabilities are licensed in different ways depending on features
required.
The PGP Universal Server 2.x management console handles centralized deployment, security policy, policy
enforcement, key management, and reporting. It is used for automated e-mail encryption in the gateway and manages
PGP Desktop 9.x clients. In addition to its local keyserver, PGP Universal Server works with the PGP public
keyserver—called the PGP Global Directory—to find recipient keys. It has the capability of delivering e-mail
securely when no recipient key is found via a secure HTTPS browser session.
With PGP Desktop 9.x managed by PGP Universal Server 2.x, first released in 2005, all PGP encryption applications
are based on a new proxy-based architecture. These newer versions of PGP software eliminate the use of e-mail
plug-ins and insulate the user from changes to other desktop applications. All desktop and server operations are now
87
Pretty Good Privacy
based on security policies and operate in an automated fashion. The PGP Universal server automates the creation,
management, and expiration of keys, sharing these keys among all PGP encryption applications.
The current shipping versions are PGP Desktop 10.2.0 (Windows and Mac-OS Platforms) and PGP Universal 3.2.0.
Also available are PGP Command Line, which enables command line-based encryption and signing of information
for storage, transfer, and backup, as well as the PGP Support Package for BlackBerry which enables RIM
BlackBerry devices to enjoy sender-to-recipient messaging encryption.
New versions of PGP applications use both OpenPGP and the S/MIME, allowing communications with any user of a
NIST specified standard.
References
[1]
[2]
[3]
[4]
Schneier, Bruce (1995-10-09). Applied Cryptography. New York: Wiley. p. 587. ISBN 0471117099.
Nichols, Randall (1999). ICSA Guide to Cryptography. McGrawHill. p. 267. ISBN 0079137598.
"United States v. Scarfo (Key-Logger Case)" (http:/ / www. epic. org/ crypto/ scarfo. html). Epic.org. . Retrieved 2010-02-08.
McCullagh, Declan (2007-07-10). "Feds use keylogger to thwart PGP, Hushmail | Tech news blog - CNET News.com" (http:/ / www. news.
com/ 8301-10784_3-9741357-7. html). News.com. . Retrieved 2010-02-08.
[5] "PGP Encryption Proves Powerful" (http:/ / www. pcworld. com/ article/ 110841/ pgp_encryption_proves_powerful. html). PCWorld.
2003-05-26. . Retrieved 2010-02-08.
[6] McCullagh, Declan (2007-12-14). "Judge: Man can't be forced to divulge encryption passphrase | The Iconoclast - politics, law, and
technology - CNET News.com" (http:/ / www. news. com/ 8301-13578_3-9834495-38. html?tag=nefd. blgs). News.com. . Retrieved
2010-02-08.
[7] McCullagh, Declan (2008-01-18). "Feds appeal loss in PGP compelled-passphrase case | The Iconoclast - politics, law, and technology CNET News.com" (http:/ / www. news. com/ 8301-13578_3-9854034-38. html). News.com. . Retrieved 2010-02-08.
[8] McCullagh, Declan (February 26, 2009). "Judge orders defendant to decrypt PGP-protected laptop" (http:/ / news. cnet. com/
8301-13578_3-10172866-38. html). CNET news. . Retrieved 2009-04-22.
[9] John Leyden (14 November 2007). "Animal rights activist hit with RIPA key decrypt demand" (http:/ / www. theregister. co. uk/ 2007/ 11/
14/ ripa_encryption_key_notice). The Register. .
[10] Chris Williams (24 November 2009). "UK jails schizophrenic for refusal to decrypt files" (http:/ / www. theregister. co. uk/ 2009/ 11/ 24/
ripa_jfl/ page2. html). The Register: p. 2. .
[11] "PGP Marks 10th Anniversary" (http:/ / www. philzimmermann. com/ EN/ news/ PGP_10thAnniversary. html). Phil Zimmermann. .
[12] Zimmermann, Philip (1995). PGP Source Code and Internals. MIT Press. ISBN 0-262-24039-4.
[13] "Lists to Check" (http:/ / www. bis. doc. gov/ complianceandenforcement/ liststocheck. htm). US Department of Commerce, Bureau of
Industry and Security. . Retrieved 4 December 2011.
[14] glueckkanja.com (http:/ / glueckkanja. com)
[15] pgp.de (http:/ / pgp. de)
[16] pgptrustcenter.com (http:/ / www. pgptrustcenter. com)
[17] http:/ / www. pgp. com/ insight/ newsroom/ press_releases/ pgp_corporation_acquires_chosensecurity. html
[18] "Symantec buys encryption specialist PGP for $300M" (http:/ / www. computerworld. com/ s/ article/ 9176121/
Symantec_buys_encryption_specialist_PGP_for_300M). Computerworld. 2010-04-29. . Retrieved 2010-04-29.
[19] Symantec PGP Desktop Peer Review Source Code (http:/ / www. symantec. com/ connect/ downloads/
symantec-pgp-desktop-peer-review-source-code)
88
Pretty Good Privacy
Further reading
• Garfinkel, Simson (1991-12-01). PGP: Pretty Good Privacy. O'Reilly & Associates. ISBN 1-56592-098-8.
• Zimmermann, Phil (1991-06). "Why I Wrote PGP" (http://www.philzimmermann.com/EN/essays/
WhyIWrotePGP.html). Retrieved 2008-03-03.
External links
OpenPGP implementations
•
•
•
•
PGP Corporation (http://www.pgp.com) (→ redirects to the Symantec website)
GNU Privacy Guard (http://www.gnupg.org/)
OpenPGP::SDK (http://openpgp.nominet.org.uk/)
cl.cam.ac.uk PGP information (http://www.cl.cam.ac.uk/PGP/)
Support
• PGP Corporation Support Forum (http://forums.pgpsupport.com/) community support plus contributions from
PGP Support staff
•
•
•
•
•
Phil Zimmermann's Home Page (http://www.philzimmermann.com)
MIT Public Key Directory for Registration and Search (http://pgp.mit.edu/)
List of public keyservers (http://www.rossde.com/PGP/pgp_keyserv.html#pubserv)
IETF OpenPGP working group (http://www.ietf.org/html.charters/openpgp-charter.html)
OpenPGP Alliance (http://www.openpgp.org/)
89
90
In cryptography, a public key certificate (also known as a digital
certificate or identity certificate) is an electronic document which
uses a digital signature to bind a public key with an identity —
information such as the name of a person or an organization, their
address, and so forth. The certificate can be used to verify that a
public key belongs to an individual.
In a typical public key infrastructure (PKI) scheme, the signature
will be of a certificate authority (CA). In a web of trust scheme, the
signature is of either the user (a self-signed certificate) or other
users ("endorsements"). In either case, the signatures on a
certificate are attestations by the certificate signer that the identity
information and the public key belong together.
For provable security this reliance on something external to the
system has the consequence that any public key certification
scheme has to rely on some special setup assumption, such as the
existence of a certificate authority.[1]
Certificates can be created for Unix-based servers with tools such
as OpenSSL's ca [2] command.[3] or SuSE's gensslcert. These
may be used to issue unmanaged certificates, Certification
Authority (CA) certificates for managing other certificates, and
user and/or computer certificate requests to be signed by the CA, as
well as a number of other certificate related functions.
Diagram of an example usage of digital certificate
Similarly, Microsoft Windows 2000 Server and Windows Server
2003 contain a Certification Authority (CA) as part of Certificate Services for the creation of digital certificates. In
Windows Server 2008 the CA may be installed as part of Active Directory Certificate Services. The CA is used to
manage and centrally issue certificates to users and/or computers. Microsoft also provides a number of different
certificate utilities, such as SelfSSL.exe for creating unmanaged certificates, and Certreq.exe for creating and
submitting certificate requests to be signed by the CA, and certutil.exe for a number of other certificate related
functions.
Contents of a typical digital certificate
Serial Number: Used to uniquely identify the certificate.
Subject: The person, or entity identified.
Signature Algorithm: The algorithm used to create the signature.
Signature: The actual signature to verify that it came from the issuer.
Issuer: The entity that verified the information and issued the certificate.
Valid-From: The date the certificate is first valid from.
Valid-To: The expiration date.
Key-Usage: Purpose of the public key (e.g. encipherment, signature, certificate signing...).
Public Key: The public key.
Thumbprint Algorithm: The algorithm used to hash the public key.
Thumbprint: The hash itself, used as an abbreviated form of the public key.
Classification
Vendor defined classes
VeriSign uses the concept of classes for different types of digital certificates [4]:
• Class 1 for individuals, intended for email.
• Class 2 for organizations, for which proof of identity is required.
• Class 3 for servers and software signing, for which independent verification and checking of identity and
authority is done by the issuing certificate authority.
• Class 4 for online business transactions between companies.
• Class 5 for private organizations or governmental security.
Other vendors may choose to use different classes or no classes at all as this is not specified in the SSL protocol,
though, most do opt to use classes in some form.
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are the two most widely deployed security
protocols in use today. SSL is essentially a protocol that provides a secure channel between two machines operating
over the Internet or an internal network. In today’s Internet focused world, we typically see SSL in use when a web
browser needs to securely connect to a web server over the insecure Internet.
Technically SSL is a transparent protocol, which requires little interaction from the end user when establishing a
secure session. For example, in the case of a browser, users are alerted to the presence of SSL when the browser
displays a padlock, or in the case of Extended Validation SSL the address bar displays both a padlock and a green
bar or green name. This is the key to the success of SSL – it provides a simple yet secure experience for end users.
Usage in the European Union
The EU Directive 1999/93/EC on a Community framework for electronic signatures[5] defines the term qualified
certificate as "a certificate which meets the requirements laid down in Annex I and is provided by a
certification-service-provider who fulfils the requirements laid down in Annex II":
Annex I: Requirements for qualified certificates
Qualified certificates must contain:
(a) an indication that the certificate is issued as a qualified certificate;
(b) the identification of the certification-service-provider and the State in which it is established;
(c) the name of the signatory or a pseudonym, which shall be identified as such;
(d) provision for a specific attribute of the signatory to be included if relevant, depending on the purpose for
which the certificate is intended;
(e) signature-verification data which correspond to signature-creation data under the control of the signatory;
(f) an indication of the beginning and end of the period of validity of the certificate;
(g) the identity code of the certificate;
(h) the advanced electronic signature of the certification-service-provider issuing it;
(i) limitations on the scope of use of the certificate, if applicable; and
(j) limits on the value of transactions for which the certificate can be used, if applicable.
Annex II Requirements for certification-service-providers issuing qualified certificates
Certification-service-providers must:
(a) demonstrate the reliability necessary for providing certification services;
91
(b) ensure the operation of a prompt and secure directory and a secure and immediate revocation service;
(c) ensure that the date and time when a certificate is issued or revoked can be determined precisely;
(d) verify, by appropriate means in accordance with national law, the identity and, if applicable, any specific
attributes of the person to which a qualified certificate is issued;
(e) employ personnel who possess the expert knowledge, experience, and qualifications necessary for the
services provided, in particular competence at managerial level, expertise in electronic signature technology
and familiarity with proper security procedures; they must also apply administrative and management
procedures which are adequate and correspond to recognised standards;
(f) use trustworthy systems and products which are protected against modification and ensure the technical and
cryptographic security of the process supported by them;
(g) take measures against forgery of certificates, and, in cases where the certification-service-provider
generates signature-creation data, guarantee confidentiality during the process of generating such data;
(h) maintain sufficient financial resources to operate in conformity with the requirements laid down in the
Directive, in particular to bear the risk of liability for damages, for example, by obtaining appropriate
insurance;
(i) record all relevant information concerning a qualified certificate for an appropriate period of time, in
particular for the purpose of providing evidence of certification for the purposes of legal proceedings. Such
recording may be done electronically;
(j) not store or copy signature-creation data of the person to whom the certification-service-provider provided
key management services;
(k) before entering into a contractual relationship with a person seeking a certificate to support his electronic
signature inform that person by a durable means of communication of the precise terms and conditions
regarding the use of the certificate, including any limitations on its use, the existence of a voluntary
accreditation scheme and procedures for complaints and dispute settlement. Such information, which may be
transmitted electronically, must be in writing and in redily understandable language. Relevant parts of this
information must also be made available on request to third-parties relying on the certificate;
(l) use trustworthy systems to store certificates in a verifiable form so that:
• only authorized persons can make entries and changes,
• information can be checked for authenticity,
• certificates are publicly available for retrieval in only those cases for which the certificate-holder's consent has
been obtained, and
• any technical changes compromising these security requirements are apparent to the operator.
Certificates and web site security
The most common use of certificates is for HTTPS-based web sites. A web browser validates that an SSL (Transport
Layer Security) web server is authentic, so that the user can feel secure that his/her interaction with the web site has
no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In
practice, a web site operator obtains a certificate by applying to a certificate provider (a CA that presents as a
commercial retailer of certificates) with a certificate signing request. The certificate request is an electronic
document that contains the web site name, contact email address, and company information. The certificate provider
signs the request, thus producing a public certificate. During web browsing, this public certificate is served to any
web browser that connects to the web site and proves to the web browser that the provider believes it has issued a
certificate to the owner of the web site.
92
Before issuing a certificate, the certificate provider will request the contact email address for the web site from a
public domain name registrar, and check that published address against the email address supplied in the certificate
request. Therefore, an https web site is only secure to the extent that the end user can be sure that the web site is
operated by someone in contact with the person who registered the domain name.
As an example, when a user connects to https://www.example.com/ with his browser, if the browser gives
no certificate warning message, then the user can be theoretically sure that interacting with
https://www.example.com/ is equivalent to interacting with the entity in contact with the email address
listed in the public registrar under "example.com", even though that email address may not be displayed anywhere
on the web site. No other surety of any kind is implied. Further, the relationship between the purchaser of the
certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not
guaranteed. At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not
been compromised (hacked) or the certificate issuing process subverted.
Extended Validation
Certificate providers issue "higher security" certificates that require further security checks, and therefore warrant
much higher fees. This is called an Extended Validation. These security checks cross reference the owner of the
domain name with the owner of the legal entity that claims to operate under it. (These checks may involve the
presentation of utility bills, passports, etc.) The difference between these higher security certificates and regular
certificates are that the browser URL bar changes to a different color, usually green. This improved security assumes
the user knows the meaning of the colors, and would choose to navigate away from the site if the color code was not
commensurate with the purpose of the web site. To be clear, for a https:// web site URL, the difference between
having no certificate, and having a regular certificate is that the browser will refuse to access the site without
confirming with the user. By comparison, the difference between a regular certificate and an extended validation
certificate is merely a change in color.
Weaknesses
A web browser will give no warning to the user if a web site suddenly presents a different certificate, even if that
certificate has a lower number of key bits, even if it lacks Extended Validation, even if it has a different provider,
and even if the previous certificate had an expiry date far into the future. Where certificate providers are under the
jurisdiction of governments, those governments may have the freedom to order the provider to generate any
certificate, such as for the purposes of law enforcement. Subsidiary wholesale certificate providers also have the
freedom to generate any certificate. All web browsers come with an extensive built-in list of trusted root certificates,
many of which are controlled by unknown organizations. Each of these organizations is free to issue any certificate
for any web site and have the guarantee that all web browsers will accept it as genuine.
The list of built-in certificates is also not fixed: users (and to a degree applications) are free to extend the list for
special purposes such as for company intranets. Whoever is able to insert a temporary trusted root certificate into a
browser's installed list of trusted root certificates will have the freedom to generate any certificate with the guarantee
that the web browser will accept it as genuine. The only way to discern a fake is to carefully inspect the certificate
path.
93
Usefulness versus unsecured web sites
In spite of the limitations described above, certificate-authenticated SSL is considered mandatory by all security
guidelines whenever a web site hosts confidential information or performs material transactions. This is because, in
practice, in spite of the serious flaws described above, web sites secured by public key certificates are still more
secure than unsecured http:// web sites.
References
[1]
[2]
[3]
[4]
[5]
Ran Canetti: Universally Composable Signature, Certification, and Authentication. CSFW 2004, http:/ / eprint. iacr. org/ 2003/ 239
http:/ / www. openssl. org/ docs/ apps/ ca. html
OpenSSL: Documentation ca(1) (http:/ / www. openssl. org/ docs/ apps/ ca. html)
VeriSign Class definitions (https:/ / www. verisign. com/ support/ roots. html)
"Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic
signatures" (http:/ / eur-lex. europa. eu/ LexUriServ/ LexUriServ. do?uri=CELEX:31999L0093:EN:HTML). Official Journal L 013 ,
19/01/2000 P. 0012 - 0020. Annex II. . Retrieved 2010-02-17.
External links
• RFC 5280 (http://www.ietf.org/rfc/rfc5280.txt) Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile
Public Key Infrastructure (PKI) is a set of
hardware, software, people, policies, and
procedures needed to create, manage,
distribute, use, store, and revoke digital
certificates.[1]
In cryptography, a PKI is an arrangement
that binds public keys with respective user
identities by means of a certificate authority
(CA). The user identity must be unique
within each CA domain. The binding is
established through the registration and
issuance process, which, depending on the
level of assurance the binding has, may be
Diagram of a public key infrastructure
carried out by software at a CA, or under
human supervision. The PKI role that
assures this binding is called the Registration Authority (RA). The RA ensures that the public key is bound to the
individual to which it is assigned in a way that ensures non-repudiation.
The term trusted third party (TTP) may also be used for certificate authority (CA). The term PKI is sometimes
erroneously used to denote public key algorithms, which do not require the use of a CA.
94
Overview
A PKI enables users to securely communicate on an insecure public network using public key encryption. The PKI
provides digital certificates which are used to identify individuals or organizations, securely stores these certificates
in a central repository, and revokes them if needed.[2]
A PKI consists of[2][3]
•
•
•
•
A certificate authority (CA) that both issues and verifies the digital certificates.
A registration authority which verifies the identity of users requesting information from the CA
A central directory -- i.e. a secure location in which to store and index keys.
A certificate management system
Methods of certification
Broadly speaking, there are three approaches to getting this trust: Certificate Authorities (CAs), Web of Trust
(WoT), and Simple public key infrastructure (SPKI).
Certificate Authorities
The primary role of the CA is to digitally sign and publish the public key bound to a given user. This is done using
the CA's own private key, so that trust in the user key relies on one's trust in the validity of the CA's key. The
mechanism that binds keys to users is called the Registration Authority (RA), which may or may not be separate
from the CA. The key-user binding is established, depending on the level of assurance the binding has, by software
or under human supervision.
The term trusted third party (TTP) may also be used for certificate authority (CA). Moreover, PKI is itself often
used as a synonym for a CA implementation.
Temporary Certificates & Single Sign-On
This approach involves a server that acts as an online certificate authority within a single sign-on system. A single
sign-on server will issue digital certificates into the client system, but never stores them. Users can execute
programs, etc. with the temporary certificate. It is common to find this solution variety with x.509-based
certificates.[4]
Web of Trust
An alternative approach to the problem of public authentication of public key information is the web of trust scheme,
which uses self-signed certificates and third party attestations of those certificates. The singular term Web of Trust
does not imply the existence of a single web of trust, or common point of trust, but rather one of any number of
potentially disjoint "webs of trust". Examples of implementations of this approach are PGP (Pretty Good Privacy)
and GnuPG (an implementation of OpenPGP, the standardized specification of PGP). Because PGP and
implementations allow the use of e-mail digital signatures for self-publication of public key information, it is
relatively easy to implement one's own Web of Trust.
One of the benefits of the Web of Trust, such as in PGP, is that it can interoperate with a PKI CA fully trusted by all
parties in a domain (such as an internal CA in a company) that is willing to guarantee certificates, as a trusted
introducer. Only if the "web of trust" is completely trusted, and because of the nature of a web of trust, trusting one
certificate is granting trust to all the certificates in that web. A PKI is only as valuable as the standards and practices
that control the issuance of certificates and including PGP or a personally instituted web of trust could significantly
degrade the trustability of that enterprise's or domain's implementation of PKI.[5]
The web of trust concept was first put forth by PGP creator Phil Zimmermann in 1992 in the manual for PGP version
2.0:
95
As time goes on, you will accumulate keys from other people that you may want to designate as trusted
introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually
accumulate and distribute with their key a collection of certifying signatures from other people, with the
expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the
emergence of a decentralized fault-tolerant web of confidence for all public keys.
Simple public key infrastructure
Another alternative, which does not deal with public authentication of public key information, is the simple public
key infrastructure (SPKI) that grew out of three independent efforts to overcome the complexities of X.509 and
PGP's web of trust. SPKI does not associate users with persons, since the key is what is trusted, rather than the
person. SPKI does not use any notion of trust, as the verifier is also the issuer. This is called an "authorization loop"
in SPKI terminology, where authorization is integral to its design.
History
The concepts and use of Public Key Infrastructure were discovered by James H. Ellis and British GCHQ scientists in
1969. After the re-discovery and commercial use of PKI by Rivest, Shamir, Diffie and others, the British government
considered releasing the records of GCHQ's successes in this field. However, the untimely publication of Spycatcher
meant that the government once again issued a gag order and full details of GCHQ achievement were never revealed.
The public disclosure of both secure key exchange and asymmetric key algorithms in 1976 by Diffie, Hellman,
Rivest, Shamir, and Adleman changed secure communications entirely. With the further development of high speed
digital electronic communications (the Internet and its predecessors), a need became evident for ways in which users
could securely communicate with each other, and as a further consequence of that, for ways in which users could be
sure with whom they were actually interacting.
Assorted cryptographic protocols were invented and analyzed within which the new cryptographic primitives could
be effectively used. With the invention of the World Wide Web and its rapid spread, the need for authentication and
secure communication became still more acute. Commercial reasons alone (e.g., e-commerce, on-line access to
proprietary databases from Web browsers, etc.) were sufficient. Taher Elgamal and others at Netscape developed the
SSL protocol ('https' in Web URLs); it included key establishment, server authentication (prior to v3, one-way only),
and so on. A PKI structure was thus created for Web users/sites wishing secure communications.
Vendors and entrepreneurs saw the possibility of a large market, started companies (or new projects at existing
companies), and began to agitate for legal recognition and protection from liability. An American Bar Association
technology project published an extensive analysis of some of the foreseeable legal aspects of PKI operations (see
ABA digital signature guidelines), and shortly thereafter, several US states (Utah being the first in 1995) and other
jurisdictions throughout the world, began to enact laws and adopt regulations. Consumer groups and others raised
questions of privacy, access, and liability considerations which were more taken into consideration in some
jurisdictions than in others.
The enacted laws and regulations differed, there were technical and operational problems in converting PKI schemes
into successful commercial operation, and progress has been far slower than pioneers had imagined it would be.
By the first few years of the 21st century the underlying cryptographic engineering was clearly not easy to deploy
correctly. Operating procedures (manual or automatic) were not easy to correctly design (nor even if so designed, to
execute perfectly, which the engineering required). The standards that existed were insufficient.
PKI vendors have found a market, but it is not quite the market envisioned in the mid-90s, and it has grown both
more slowly and in somewhat different ways than were anticipated.[6] PKIs have not solved some of the problems
they were expected to, and several major vendors have gone out of business or been acquired by others. PKI has had
the most success in government implementations; the largest PKI implementation to date is the Defense Information
96
Systems Agency (DISA) PKI infrastructure for the Common Access Cards program.
Security issues
• See PKI security issues with X.509
• See Breach of Comodo CA
• See Breach of Diginotar CA
Usage examples
PKIs of one type or another, and from any of several vendors, have many uses, including providing public keys and
bindings to user identities which are used for:
• Encryption and/or sender authentication of e-mail messages (e.g., using OpenPGP or S/MIME).
• Encryption and/or authentication of documents (e.g., the XML Signature [7] or XML Encryption [8] standards if
documents are encoded as XML).
• Authentication of users to applications (e.g., smart card logon, client authentication with SSL). There's
experimental usage for digitally signed HTTP authentication in the Enigform and mod_openpgp projects.
• Bootstrapping secure communication protocols, such as Internet key exchange (IKE) and SSL. In both of these,
initial set-up of a secure channel (a "security association") uses asymmetric key (a.k.a. public key) methods,
whereas actual communication uses faster symmetric key (a.k.a. secret key) methods.
• Mobile signatures[9] are electronic signatures that are created using a mobile device and rely on signature or
certification services in a location independent telecommunication environment.
• Universal Metering Interface (UMI) an open standard, originally created by Cambridge Consultants for use in
Smart Metering devices/systems and home automation, uses a PKI infrastructure for security.
Terminology
• CA: Certificate authority
• TTP: Trusted third party
References
[1] "LPKI - A Lightweight Public Key Infrastructure for the Mobile Environments" (http:/ / ieeexplore. ieee. org/ xpl/ freeabs_all.
jsp?arnumber=4737164), Proceedings of the 11th IEEE International Conference on Communication Systems (IEEE ICCS'08), pp.162-166,
Guangzhou, China, Nov. 2008.
[2] Vacca, Jhn R. (2004). Public key infrastructure: building trusted applications and Web services (http:/ / books. google. com/
books?id=3kS8XDALWWYC& pg=PA8). CRC Press. p. 8. ISBN 9780849308222. .
[3] McKinley, Barton (January 17, 2001). "The ABCs of PKI: Decrypting the complex task of setting up a public-key infrastructure" (http:/ /
www. networkworld. com/ research/ 2000/ 0117feat. html). Network World. .
[4] Single Sign-On Technology for SAP Enterprises: What does SAP have to say? (http:/ / www. secude. com/ html/ ?id=1890)
[5] Ed Gerck, Overview of Certification Systems: x.509, CA, PGP and SKIP, in The Black Hat Briefings '99, http:/ / www. securitytechnet. com/
resource/ rsc-center/ presentation/ black/ vegas99/ certover. pdf and http:/ / mcwg. org/ mcg-mirror/ cert. htm
[6] Stephen Wilson, Dec 2005, "The importance of PKI today" (http:/ / www. china-cic. org. cn/ english/ digital library/ 200512/ 3. pdf), China
Communications, Retrieved on 2010-12-13
[7] http:/ / www. w3. org/ TR/ xmldsig-core/
[8] http:/ / www. w3. org/ TR/ xmlenc-core/
[9] Mark Gasson, Martin Meints, Kevin Warwick (2005), D3.2: A study on PKI and biometrics (http:/ / www. fidis. net/ resources/ deliverables/
hightechid/ #c1785), FIDIS deliverable (3)2, July 2005
97
External links
•
•
•
•
PKI tutorial (http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf) by Peter Gutmann
PKI Tutorial using Fingerpuppets (http://www.carillon.ca/tutorials.php)
PKIX workgroup (http://www.ietf.org/html.charters/pkix-charter.html)
Easing the PAIN (http://www-106.ibm.com/developerworks/library/s-pain.html) — a detailed explanation of
PKI Privacy, Authentication, Integrity and Non-repudiation (PAIN)
• NIST PKI Program (http://csrc.nist.gov/pki/) — in which the National Institute of Standards and Technology
(NIST) is attempting to develop a public key infrastructure
• Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure (http://www.schneier.com/
paper-pki.html) by C. Ellison and B. Schneier
• Response to Ten Risks (http://homepage.mac.com/aramperez/responsetenrisks.html) by A. Perez
• Seven and a Half Non-risks of PKI (http://www.apache-ssl.org/7.5things.txt) by B. Laurie
• The Inevitable Collapse of the Certificate Model (http://www.hbarel.com/blog?itemid=36) by Hagai Bar-El
Public-key cryptography refers to a cryptographic
system requiring two separate keys, one to lock or
encrypt the plaintext, and one to unlock or decrypt the
cyphertext. Neither key will do both functions. One of
these keys is published or public and the other is kept
private. If the lock/encryption key is the one published
then the system enables private communication from
the public to the unlocking key's owner. If the
unlock/decryption key is the one published then the
system serves as a signature verifier of documents
locked by the owner of the private key.
This cryptographic approach uses asymmetric key
algorithms, hence the more general name of
"asymmetric key cryptography". Some of these
algorithms have the public key/private key property;
that is, neither key is derivable from knowledge of the
In an asymmetric key encryption scheme, anyone can encrypt
messages
using the public key, but only the holder of the paired
other; not all asymmetric key algorithms do. Those
private key can decrypt. Security depends on the secrecy of that
with this property are particularly useful and have been
private key.
widely deployed, and are the source of the commonly
used name. The public key is used to transform a
message into an unreadable form, decryptable only by using the (different but matching) private key. Participants in
such a system must create a mathematically linked key pair (i.e., a public and a private key). By publishing the
public key, the key producer empowers anyone who gets a copy of the public key to produce messages only s/he can
read
--
98
99
because only the key producer has a copy of the private
key (required for decryption). When someone wants to
send a secure message to the creator of those keys, the
sender encrypts it (i.e., transforms it into an unreadable
form) using the intended recipient's public key; to
decrypt the message, the recipient uses the private key.
No one else, including the sender, can do so.
Thus, unlike symmetric key algorithms, a public key
algorithm does not require a secure initial exchange of
one, or more, secret keys between the sender and
receiver. These algorithms work in such a way that,
while it is easy for the intended recipient to generate
the public and private keys and to decrypt the message
using the private key, and while it is easy for the sender
to encrypt the message using the public key, it is
extremely difficult for anyone to figure out the private
key based on their knowledge of the public key. They
are based on mathematical relationships (the most
notable ones being the integer factorization and discrete
logarithm problems) that have no efficient solution.
In some related signature schemes, the private key is used to sign a
message; anyone can check the signature using the public key.
Validity depends on security of the private key.
The use of these algorithms also allows authenticity of
a message to be checked by creating a digital signature
of a message using the private key, which can be
verified using the public key.
Public key cryptography is a fundamental and widely
used technology. It is an approach used by many
cryptographic algorithms and cryptosystems. It
underpins such Internet standards as Transport Layer
Security (TLS) (successor to SSL), PGP, and GPG.
How it works
The distinguishing technique used in public key
cryptography is the use of asymmetric key algorithms,
where the key used to encrypt a message is not the
In the Diffie–Hellman key exchange scheme, each party generates a
same as the key used to decrypt it. Each user has a pair
public/private key pair and distributes the public key... After
obtaining an authentic copy of each other's public keys, Alice and
of cryptographic keys — a public encryption key and
Bob can compute a shared secret offline. The shared secret can be
a private decryption key. The publicly available
used, for instance, as the key for a symmetric cipher.
encrypting-key is widely distributed, while the private
decrypting-key is known only to the recipient.
Messages are encrypted with the recipient's public key and can be decrypted only with the corresponding private key.
The keys are related mathematically, but parameters are chosen so that determining the private key from the public
key is prohibitively expensive. The discovery of algorithms that could produce public/private key pairs
revolutionized the practice of cryptography beginning in the mid-1970s.
In contrast, symmetric-key algorithms, variations of which having been used for thousands of years, use a single
secret key — which must be shared and kept private by both sender and receiver — for both encryption and
decryption. To use a symmetric encryption scheme, the sender and receiver must securely share a key in advance.
Because symmetric key algorithms are nearly always much less computationally intensive, it is common to exchange
a key using a key-exchange algorithm and transmit data using that key and a symmetric key algorithm. PGP and the
SSL/TLS family of schemes do this, for instance, and are thus called hybrid cryptosystems.
Description
The two main branches of public key cryptography are:
• Public key encryption: a message encrypted with a recipient's public key cannot be decrypted by anyone except a
possessor of the matching private key — it is presumed that this will be the owner of that key and the person
associated with the public key used. This is used for confidentiality.
• Digital signatures: a message signed with a sender's private key can be verified by anyone who has access to the
sender's public key, thereby proving that the sender had access to the private key (and therefore is likely to be the
person associated with the public key used), and the part of the message that has not been tampered with. On the
question of authenticity, see also message digest.
An analogy to public-key encryption is that of a locked mail box with a mail slot. The mail slot is exposed and
accessible to the public; its location (the street address) is in essence the public key. Anyone knowing the street
address can go to the door and drop a written message through the slot; however, only the person who possesses the
key can open the mailbox and read the message.
An analogy for digital signatures is the sealing of an envelope with a personal wax seal. The message can be opened
by anyone, but the presence of the seal authenticates the sender.
A central problem for use of public-key cryptography is confidence (ideally proof) that a public key is correct,
belongs to the person or entity claimed (i.e., is 'authentic'), and has not been tampered with or replaced by a
malicious third party. The usual approach to this problem is to use a public-key infrastructure (PKI), in which one or
more third parties, known as certificate authorities, certify ownership of key pairs. PGP, in addition to a certificate
authority structure, has used a scheme generally called the "web of trust", which decentralizes such authentication of
public keys by a central mechanism, substituting individual endorsements of the link between user and public key.
No fully satisfactory solution to the public key authentication problem is known.
History
During the early history of cryptography, two parties would rely upon a key using a secure, but non-cryptographic,
method; for example, a face-to-face meeting or an exchange via a trusted courier. This key, which both parties kept
absolutely secret, could then be used to exchange encrypted messages. A number of significant practical difficulties
arise in this approach to distributing keys. Public-key cryptography addresses these drawbacks so that users can
communicate securely over a public channel without having to agree upon a shared key beforehand.
In 1874, a book by William Stanley Jevons[1] described the relationship of one-way functions to cryptography and
went on to discuss specifically the factorization problem used to create the trapdoor function in the RSA system. In
July 1996, one observer[2] commented on the Jevons book in this way:
In his book The Principles of Science: A Treatise on Logic and Scientific Method, written and published
in the 1890s,[3] William S. Jevons observed that there are many situations where the 'direct' operation is
relatively easy, but the 'inverse' operation is significantly more difficult. One example mentioned briefly
is that enciphering (encryption) is easy while deciphering (decryption) is not. In the same section of
Chapter 7: Introduction titled 'Induction an Inverse Operation', much more attention is devoted to the
principle that multiplication of integers is easy, but finding the (prime) factors of the product is much
100
harder. Thus, Jevons anticipated a key feature of the RSA Algorithm for public key cryptography,
though he certainly did not invent the concept of public key cryptography.
An asymmetric-key cryptosystem was published in 1976 by Whitfield Diffie and Martin Hellman, who, influenced
by Ralph Merkle's work on public-key distribution, disclosed a method of public-key agreement. This method of key
exchange, which uses exponentiation in a finite field, came to be known as Diffie–Hellman key exchange. This was
the first published practical method for establishing a shared secret-key over an authenticated (but not private)
communications channel without using a prior shared secret. Merkle's public-key-agreement technique became
known as Merkle's Puzzles, and was invented in 1974 and published in 1978.
In 1997, it was publicly disclosed that asymmetric key algorithms were developed by James H. Ellis, Clifford Cocks,
and Malcolm Williamson at the Government Communications Headquarters (GCHQ) in the UK in 1973.[4] The
researchers independently developed Diffie–Hellman key exchange and a special case of RSA. The GCHQ
cryptographers referred to the technique as "non-secret encryption". This work was named an IEEE Milestone in
2010.[5]
A generalization of Cocks's scheme was independently invented in 1977 by Rivest, Shamir and Adleman, all then at
MIT. The latter authors published their work in 1978, and the algorithm appropriately came to be known as RSA.
RSA uses exponentiation modulo a product of two large primes to encrypt and decrypt, performing both public key
encryption and public key digital signature, and its security is connected to the presumed difficulty of factoring large
integers, a problem for which there is no known efficient (i.e., practicably fast) general technique. In 1979 Michael
O. Rabin published a related cryptosystem that is probably secure as long as factorization of the public key remains
difficult; it remains an assumption that RSA also enjoys this security.
Since the 1970s, a large number and variety of encryption, digital signature, key agreement, and other techniques
have been developed in the field of public-key cryptography. The ElGamal cryptosystem (invented by Taher
ElGamal) relies on the (similar, and related) difficulty of the discrete logarithm problem, as does the closely related
DSA developed at the US National Security Agency (NSA) and published by NIST as a proposed standard. The
introduction of elliptic curve cryptography by Neal Koblitz and Victor Miller independently and simultaneously in
the mid-1980s has yielded new public-key algorithms based on the discrete logarithm problem. Although
mathematically more complex, elliptic curves provide smaller key sizes and faster operations for equivalent
estimated security.
Security
Some encryption schemes can be proven secure on the basis of the presumed hardness of a mathematical problem
like factoring the product of two large primes or computing discrete logarithms. Note that "secure" here has a precise
mathematical meaning, and there are multiple different (meaningful) definitions of what it means for an encryption
scheme to be secure. The "right" definition depends on the context in which the scheme will be deployed.
The most obvious application of a public key encryption system is confidentiality; a message that a sender encrypts
using the recipient's public key can be decrypted only by the recipient's paired private key (assuming, of course, that
no flaw is discovered in the basic algorithm used).
Another type of application in public-key cryptography is that of digital signature schemes. Digital signature
schemes can be used for sender authentication and non-repudiation. In such a scheme, a user who wants to send a
message computes a digital signature of this message and then sends this digital signature together with the message
to the intended receiver. Digital signature schemes have the property that signatures can be computed only with the
knowledge of a private key. To verify that a message has been signed by a user and has not been modified the
receiver needs to know only the corresponding public key. In some cases (e.g., RSA), there exist digital signature
schemes with many similarities to encryption schemes. In other cases (e.g., DSA), the algorithm does not resemble
any encryption scheme.
101
To achieve both authentication and confidentiality, the sender can first sign the message using his private key and
then encrypt both the message and the signature using the recipient's public key.
These characteristics can be used to construct many other, sometimes surprising, cryptographic protocols and
applications, like digital cash, password-authenticated key agreement, multi-party key agreement, time-stamping
service, non-repudiation protocols, etc.
Practical considerations
A postal analogy
An analogy that can be used to understand the advantages of an asymmetric system is to imagine two people, Alice
and Bob, sending a secret message through the public mail. In this example, Alice wants to send a secret message to
Bob, and expects a secret reply from Bob.
With a symmetric key system, Alice first puts the secret message in a box, and locks the box using a padlock to
which she has a key. She then sends the box to Bob through regular mail. When Bob receives the box, he uses an
identical copy of Alice's key (which he has somehow obtained previously, maybe by a face-to-face meeting) to open
the box, and reads the message. Bob can then use the same padlock to send his secret reply.
In an asymmetric key system, Bob and Alice have separate padlocks. First, Alice asks Bob to send his open padlock
to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing
her message, and sends the locked box to Bob. Bob can then unlock the box with his key and reads the message from
Alice. To reply, Bob must similarly get Alice's open padlock to lock the box before sending it back to her.
The critical advantage in an asymmetric key system is that Bob and Alice never need to send a copy of their keys to
each other. This prevents a third party (perhaps, in the example, a corrupt postal worker) from copying a key while it
is in transit, allowing said third party to spy on all future messages sent between Alice and Bob. So in the public key
scenario, Alice and Bob need not trust the postal service as much. In addition, if Bob were careless and allowed
someone else to copy his key, Alice's messages to Bob would be compromised, but Alice's messages to other people
would remain secret, since the other people would be providing different padlocks for Alice to use.
In another kind of asymmetric key system, Bob and Alice have separate padlocks. First, Alice puts the secret
message in a box, and locks the box using a padlock to which only she has a key. She then sends the box to Bob
through regular mail. When Bob receives the box, he adds his own padlock to the box, and sends it back to Alice.
When Alice receives the box with the two padlocks, she removes her padlock and sends it back to Bob. When Bob
receives the box with only his padlock on it, Bob can then unlock the box with his key and read the message from
Alice. Note that, in this scheme, the order of Decryption is the same as the order of encryption; this is only possible
if commutative ciphers are used. A commutative cipher is one in which the order of encryption and decryption is
interchangeable, just as the order of multiplication is interchangeable; i.e., A*B*C = A*C*B = C*B*A. A simple
XOR with the individual keys is such a commutative cipher. For example, let E1() and E2() be two encryption
functions and let "M" be the message so if Alice encrypts it using E1() and sends E1(M) to Bob. Bob then again
encrypts the message as E2(E1(M)) and sends it to Alice. Now Alice Decrypts E2(E1(M)) using E1(). She'll
now get E2(M), meaning when she sends this again to Bob, he will be able to decrypt the message using E2() and
get "M". Although none of the keys were ever exchanged, the message "M" may well be a key, e.g., Alice's Public
key. This three-pass protocol is typically used during key exchange.
102
Actual algorithms—two linked keys
Not all asymmetric key algorithms operate in precisely this fashion. The most common ones have the property that
Alice and Bob each own two keys, one for encryption and one for decryption. In a secure asymmetric key encryption
scheme, the private key should not be deducible from the public key. This is known as public-key encryption, since
an encryption key can be published without compromising the security of messages encrypted with that key.
In the analogy above, Bob might publish instructions on how to make a lock ("public key"), but the lock is such that
it is impossible (so far as is known) to deduce from these instructions how to make a key that will open that lock
("private key"). Those wishing to send messages to Bob use the public key to encrypt the message; Bob uses his
private key to decrypt it.
Another example is that Alice and Bob both choose a key at random and contact each other to compare the depth of
each notch on their keys. Having determined the difference a locked box is built with a special lock that has each pin
inside divided into 2 pins, matching the numbers of their keys. Now the box will be able to be opened with either key
and Alice and Bob can exchange messages inside securely.
Weaknesses
Of course, there is a possibility that someone could "pick" Bob's or Alice's lock. Among symmetric key encryption
algorithms, only the one-time pad can be proven to be secure against any adversary, no matter how much computing
power is available. However, there is no public-key scheme with this property, since all public-key schemes are
susceptible to the brute-force key search attack. Such attacks are impractical if the amount of computation needed to
succeed (termed 'work factor' by Claude Shannon) is out of reach of potential attackers. In many cases, the work
factor can be increased by simply choosing a longer key. But other attacks may have much lower work factors,
making resistance to brute-force attack irrelevant, and some are known for some public key encryption algorithms.
Both RSA and ElGamal encryption have known attacks that are much faster than the brute-force approach. Such
estimates have changed both with the decreasing cost of computer power, and new mathematical discoveries.
In practice, these insecurities can be generally avoided by choosing key sizes large enough that the best-known
attack would take so long that it is not worth any adversary's time and money to break the code. For example, if an
estimate of how long it takes to break an encryption scheme is one thousand years, and it were used to encrypt your
credit card details, they would be safe enough, since the time needed to decrypt the details will be rather longer than
the useful life of those details, which expire after a few years. Typically, the key size needed is much longer for
public key algorithms than for symmetric key algorithms.
Aside from the resistance to attack of a particular keypair, the security of the certification hierarchy must be
considered when deploying public key systems. Some certificate authority (usually a purpose built program running
on a server computer) vouches for the identities assigned to specific private keys by producing a digital certificate.
Public key digital certificates are typically valid for several years at a time, so the associated private keys must be
held securely over that time. When a private key used for certificate creation higher in the PKI server hierarchy is
compromised or accidentally disclosed then a man-in-the-middle attack is possible, making any subordinate
certificate wholly insecure.
Major weaknesses have been found for several formerly promising asymmetric key algorithms. The 'knapsack
packing' algorithm was found to be insecure when a new attack was found. Recently, some attacks based on careful
measurements of the exact amount of time it takes known hardware to encrypt plain text have been used to simplify
the search for likely decryption keys (see side channel attack). Thus, mere use of asymmetric key algorithms does
not ensure security; it is an area of active research to discover and protect against new attacks.
Another potential security vulnerability in using asymmetric keys is the possibility of a man-in-the-middle attack, in
which communication of public keys is intercepted by a third party and modified to provide different public keys
instead. Encrypted messages and responses must also be intercepted, decrypted and re-encrypted by the attacker
103
using the correct public keys for different communication segments in all instances to avoid suspicion. This attack
may seem to be difficult to implement in practice, but it's not impossible when using insecure media (e.g., public
networks such as the Internet or wireless communications). A malicious staff member at Alice or Bob's ISP might
find it quite easy to carry out. In the earlier postal analogy, Alice would have to have a way to make sure that the
lock on the returned packet really belongs to Bob before she removes her lock and sends the packet back. Otherwise,
the lock could have been put on the packet by a corrupt postal worker pretending to be Bob to Alice.
One approach to prevent such attacks is the use of a certificate authority, a trusted third party responsible for
verifying the identity of a user of the system and issuing a tamper resistant and non-spoofable digital certificate for
participants. Such certificates are signed data blocks stating that this public key belongs to that person, company, or
other entity. This approach also has weaknesses. For example, the certificate authority issuing the certificate must be
trusted to have properly checked the identity of the key-holder, the correctness of the public key when it issues a
certificate, and has made arrangements with all participants to check all certificates before protected communications
can begin. Web browsers, for instance, are supplied with many self-signed identity certificates from PKI providers;
these are used to check certificate's bonafides (issued properly by the claimed central PKI server?) and then, in a
second step, the certificate of a potential communicant. An attacker who could subvert the certificate authority into
issuing a certificate for a bogus public key could then mount a man-in-the-middle attack as easily as if the certificate
scheme were not used at all. Despite its problems, this approach is widely used; examples include SSL and its
successor, TLS, which are commonly used to provide security in web browsers, for example, to securely send credit
card details to an online store.
Computational cost
Public key algorithms known thus far are relatively computationally costly compared with most symmetric key
algorithms of apparently equivalent security. The difference factor is the use of typically quite large keys. This has
important implications for their practical use. Most are used in hybrid cryptosystems for reasons of efficiency; in
such a cryptosystem, a shared secret key ("session key") is generated by one party and this much briefer session key
is then encrypted by each recipient's public key. Each recipient uses the corresponding private key to decrypt the
session key. Once all parties have obtained the session key they can use a much faster symmetric algorithm to
encrypt and decrypt messages. In many of these schemes, the session key is unique to each message exchange, being
pseudo-randomly chosen for each message.
Associating public keys with identities
The binding between a public key and its 'owner' must be correct, lest the algorithm function perfectly and yet be
entirely insecure in practice. As with most cryptography, the protocols used to establish and verify this binding are
critically important. Associating a public key with its owner is typically done by protocols implementing a public
key infrastructure; these allow the validity of the association to be formally verified by reference to a trusted third
party, in the form of either a hierarchical certificate authority (e.g., X.509), a local trust model (e.g., SPKI), or a web
of trust scheme (e.g., that originally built into PGP and GPG and still to some extent usable with them). Whatever
the cryptographic assurance of the protocols themselves, the association between a public key and its owner is
ultimately a matter of subjective judgment on the part of the trusted third party, since the key is a mathematical entity
while the owner, and the connection between owner and key, are not. For this reason, the formalism of a public key
infrastructure must provide for explicit statements of the policy followed when making this judgment. For example,
the complex and never fully implemented X.509 standard allows a certificate authority to identify its policy by
means of an object identifier, which functions as an index into a catalog of registered policies. Policies may exist for
many different purposes, ranging from anonymity to military classification.
104
Relation to real world events
A public key will be known to a large and, in practice, unknown set of users. All events requiring revocation or
replacement of a public key can take a long time to take full effect with all who must be informed (i.e., all those
users who possess that key). For this reason, systems that must react to events in real time (e.g., safety-critical
systems or national security systems) should not use public-key encryption without taking great care. There are four
issues of interest:
Privilege of key revocation
A malicious (or erroneous) revocation of some or all of the keys in the system is likely, or in the second case, certain,
to cause a complete failure of the system. If public keys can be revoked individually, this is a possibility. However,
there are design approaches that can reduce the practical chance of this occurring. For example, by means of
certificates we can create what is called a "compound principal"; one such principal could be "Alice and Bob have
Revoke Authority". Now only Alice and Bob (in concert) can revoke a key, and neither Alice nor Bob can revoke
keys alone. However, revoking a key now requires both Alice and Bob to be available, and this creates a problem of
reliability. In concrete terms, from a security point of view, there is now a single point of failure in the public key
revocation system. A successful Denial of Service attack against either Alice or Bob (or both) will block a required
revocation. In fact, any partition of authority between Alice and Bob will have this effect, regardless of how it comes
about.
Because the principle allowing revocation authority for keys is very powerful, the mechanisms used to control it
should involve both, as many participants as possible (to guard against malicious attacks of this type), while at the
same time as few as possible (to ensure that a key can be revoked without dangerous delay). Public key certificates
that include an expiry date are unsatisfactory in that the expiry date may not correspond with a real-world revocation
need, but at least such certificates need not all be tracked down system-wide, nor must all users be in constant
contact with the system at all times.
Distribution of a new key
After a key has been revoked, or when a new user is added to a system, a new key must be distributed in some
predetermined manner. Assume that Carol's key has been revoked (e.g., automatically by exceeding its use-before
date, or less so, because of a compromise of Carol's matching private key). Until a new key has been distributed,
Carol is effectively out of contact. No one will be able to send her messages without violating system protocols (i.e.,
without a valid public key, no one can encrypt messages to her), and messages from her cannot be signed for the
same reason. Or, in other words, the "part of the system" controlled by Carol is in essence unavailable. Security
requirements have been ranked higher than system availability in such designs.
One could leave the power to create (and certify) keys as well as revoke them in the hands of each user, and the
original PGP design did so, but this raises problems of user understanding and operation. For security reasons, this
approach has considerable difficulties; if nothing else, some users will be forgetful or inattentive or confused. On one
hand, a message revoking a public key certificate should be spread as fast as possible while, on the other hand, (parts
of) the system might be rendered inoperable before a new key can be installed. The time window can be reduced to
zero by always issuing the new key together with the certificate that revokes the old one, but this requires co-location
of authority to both revoke keys and generate new keys.
It is most likely a system-wide failure if the (possibly combined) principal that issues new keys fails by issuing keys
improperly. It is an instance of a common mutual exclusion; a design can make the reliability of a system high, but
only at the cost of system availability, and vice versa.
105
Spreading the revocation
Notification of a key certificate revocation must be spread to all those who might potentially hold it, and as rapidly
as possible.
There are two means of spreading information (e.g., a key revocation here) in a distributed system: either the
information is pushed to users from a central point(s), or it is pulled from a central point(s) by end users.
Pushing the information is the simplest solution in that a message is sent to all participants. However, there is no way
of knowing whether all participants will actually receive the message. And, if the number of participants is large and
some of their physical or network distance great, the probability of complete success (which is, in ideal
circumstances, required for system security) will be rather low. In a partly updated state, the system is particularly
vulnerable to denial of service attacks as security has been breached, and a vulnerability window will continue to
exist as long as some users have not 'gotten the word'. In other words, pushing certificate revocation messages is
neither easy to secure nor very reliable.
The alternative to pushing is pulling. In the extreme, all certificates contain all the keys needed to verify that the
public key of interest (i.e., the one belonging to the user to whom one wishes to send a message, or whose signature
is to be checked) is still valid. In this case, at least some use of the system will be blocked if a user cannot reach the
verification service (i.e., one of those systems that can establish the current validity of another user's key). Again,
such a system design can be made as reliable as one wishes, at the cost of lowering security (the more servers to
check for the possibility of a key revocation, the longer the window of vulnerability).
Another trade-off is to use a somewhat less reliable, but more secure, verification service but to include an expiry
date for each of the verification sources. How long this timeout should be is a decision that embodies a trade-off
between availability and security that will have to be decided in advance, at system design time.
Recovery from a leaked key
Assume that the principal authorized to revoke a key has decided that a certain key must be revoked. In most cases
this happens after the fact; for instance, it becomes known that at some time in the past an event occurred that
endangered a private key. Let us denote the time at which it is decided that the compromise occurred with T.
Such a compromise has two implications. Messages encrypted with the matching public key (now or in the past) can
no longer be assumed to be secret. One solution to avoid this problem is to use a protocol that has perfect forward
secrecy. Second, signatures made with the no longer trusted to be actually private key after time T, can no longer be
assumed to be authentic without additional information about who, where, when, etc. of the events leading up to
digital signature. These will not always be available, and so all such digital signatures will be less than credible. A
solution to reduce the impact of leaking a private key of a signature scheme is to use timestamps.
Loss of secrecy and/or authenticity, even for a single user, has system-wide security implications, and a strategy for
recovery must thus be established. Such a strategy will determine who has authority and under what conditions to
revoke a public key certificate, how to spread the revocation, but also, ideally, how to deal with all messages signed
with the key since time T (which will rarely be known precisely). Messages sent to that user (which require the
proper, now compromised, private key to decrypt) must be considered compromised as well, no matter when they
were sent.
Such a recovery procedure can be quite complex, and while it is in progress the system will likely be vulnerable
against Denial of Service attacks, among other things.
106
Examples
Examples of well-regarded asymmetric key techniques for varied purposes include:
•
•
•
•
•
•
•
•
Diffie–Hellman key exchange protocol
DSS (Digital Signature Standard), which incorporates the Digital Signature Algorithm
ElGamal
Various elliptic curve techniques
Various password-authenticated key agreement techniques
Paillier cryptosystem
RSA encryption algorithm (PKCS#1)
Cramer–Shoup cryptosystem
Examples of asymmetric key algorithms not widely adopted include:
• NTRUEncrypt cryptosystem
• McEliece cryptosystem
Examples of notable yet insecure asymmetric key algorithms include:
• Merkle–Hellman knapsack cryptosystem
Examples of protocols using asymmetric key algorithms include:
•
•
•
•
•
•
•
•
GPG, an implementation of OpenPGP
Internet Key Exchange
PGP
ZRTP, a secure VoIP protocol
Secure Socket Layer, now codified as the IETF standard Transport Layer Security (TLS)
SILC
SSH
Bitcoin
Notes
[1] Jevons, William Stanley, The Principles of Science: A Treatise on Logic and Scientific Method (http:/ / www. archive. org/ stream/
principlesofscie00jevorich#page/ n166/ mode/ 1up) p. 141, Macmillan & Co., London, 1874, 2nd ed. 1877, 3rd ed. 1879. Reprinted with a
foreword by Ernst Nagel, Dover Publications, New York, NY, 1958.
[2] Golob, Solomon (1996). "ON FACTORING JEVONS' NUMBER". Cryptologia 20 (3): 243. doi:10.1080/0161-119691884933.
[3] The 1890s date for the publication of Jevons' book in this quotation is incorrect.
[4] http:/ / www. gchq. gov. uk/ history/ pke. html
[5] "List of IEEE Milestones" (http:/ / www. ieeeghn. org/ wiki/ index. php/ Milestones:List_of_IEEE_Milestones). IEEE Global History
Network. IEEE. . Retrieved 4 August 2011.
References
• N. Ferguson; B. Schneier (2003). Practical Cryptography. Wiley. ISBN 0-471-22357-3.
• J. Katz; Y. Lindell (2007). Introduction to Modern Cryptography. CRC Press. ISBN 1-58488-551-3.
• A. J. Menezes; P. C. van Oorschot; S. A. Vanstone (1997). Handbook of Applied Cryptography (http://www.
cacr.math.uwaterloo.ca/hac/). ISBN 0-8493-8523-7.
• J. Davies (2011). Implementing SSL/TLS Using Cryptography and PKI. Wiley. ISBN 978-0470920411.
• IEEE 1363: Standard Specifications for Public-Key Cryptography (http://grouper.ieee.org/groups/1363)
• Christof Paar, Jan Pelzl, "Introduction to Public-Key Cryptography" (http://wiki.crypto.rub.de/Buch/movies.
php), Chapter 6 of "Understanding Cryptography, A Textbook for Students and Practitioners". (companion web
site contains online cryptography course that covers public-key cryptography), Springer, 2009.
107
External links
• Oral history interview with Martin Hellman (http://purl.umn.edu/107353), Charles Babbage Institute,
University of Minnesota. Leading cryptography scholar Martin Hellman discusses the circumstances and
fundamental insights of his invention of public key cryptography with collaborators Whitfield Diffie and Ralph
Merkle at Stanford University in the mid-1970s.
• An account of how GCHQ kept their invention of PKE secret until 1997 (http://www.ladlass.com/intel/
archives/010256.html) (Content can be found at the Internet Archive.) (http://web.archive.org/web/
20080625052129/http://www.ladlass.com/intel/archives/010256.html)
• A good documentation and program for Public-key cryptography (http://gpg4win.org/documentation.html)
108
RSA (algorithm)
109
RSA (algorithm)
RSA
General
Designers
Ron Rivest, Adi Shamir, and Leonard Adleman
First published 1978
Certification
PKCS#1, ANSI X9.31, IEEE 1363
Cipher detail
Key sizes
1,024 to 4,096 bit typical
A 768 bit key has been broken
RSA is an algorithm for public-key cryptography that is based on the presumed difficulty of factoring large integers,
the factoring problem. RSA stands for Ron Rivest, Adi Shamir and Leonard Adleman, who first publicly described it
in 1978. A user of RSA creates and then publishes the product of two large prime numbers, along with an auxiliary
value, as their public key. The prime factors must be kept secret. Anyone can use the public key to encrypt a
message, but with currently published methods, if the public key is large enough, only someone with knowledge of
the prime factors can feasibly decode the message.[1] Whether breaking RSA encryption is as hard as factoring is an
open question known as the RSA problem.
History
Clifford Cocks, an English mathematician working for the UK intelligence agency GCHQ, described an equivalent
system in an internal document in 1973, but given the relatively expensive computers needed to implement it at the
time, it was mostly considered a curiosity and, as far as is publicly known, was never deployed. His discovery,
however, was not revealed until 1998 due to its top-secret classification, and Rivest, Shamir, and Adleman devised
RSA independently of Cocks' work.
RSA (algorithm)
The RSA algorithm was publicly described in 1978 by Ron Rivest, Adi
Shamir, and Leonard Adleman at MIT; the letters RSA are the initials of
their surnames, listed in the same order as on the paper.[2]
MIT was granted U.S. Patent 4405829 [3] for a "Cryptographic
communications system and method" that used the algorithm in 1983.
The patent would have expired on September 21, 2000 (the term of
patent was 17 years at the time), but the algorithm was released to the
public domain by RSA Security on 6 September 2000, two weeks
earlier.[4] Since a paper describing the algorithm had been published in
August 1977,[2] prior to the December 1977 filing date of the patent
application, regulations in much of the rest of the world precluded
patents elsewhere and only the US patent was granted. Had Cocks' work
been publicly known, a patent in the US might not have been possible.
From the DWPI's abstract of the patent,
The system includes a communications channel coupled to
at least one terminal having an encoding device and to at
Adi Shamir, one of the authors of RSA: Rivest,
least one terminal having a decoding device. A
Shamir and Adleman
message-to-be-transferred is enciphered to ciphertext at the
encoding terminal by encoding the message as a number M in a predetermined set. That number is then
raised to a first predetermined power (associated with the intended receiver) and finally computed. The
remainder or residue, C, is... computed when the exponentiated number is divided by the product of two
predetermined prime numbers (associated with the intended receiver).
Operation
The RSA algorithm involves three steps: key generation, encryption and decryption.
Key generation
RSA involves a public key and a private key. The public key can be known to everyone and is used for encrypting
messages. Messages encrypted with the public key can only be decrypted using the private key. The keys for the
RSA algorithm are generated the following way:
1. Choose two distinct prime numbers p and q.
• For security purposes, the integers p and q should be chosen at random, and should be of similar bit-length.
Prime integers can be efficiently found using a primality test.
2. Compute n = pq.
• n is used as the modulus for both the public and private keys
3. Compute φ(n) = (p – 1)(q – 1), where φ is Euler's totient function.
4. Choose an integer e such that 1 < e < φ(n) and greatest common denominator of (e,φ(n)) = 1, i.e. e and φ(n) are
coprime.
• e is released as the public key exponent.
• e having a short bit-length and small Hamming weight results in more efficient encryption - most commonly
0x10001 = 65537. However, small values of e (such as 3) have been shown to be less secure in some
settings.[5]
5. Determine d = e–1 mod φ(n); i.e. d is the multiplicative inverse of e mod φ(n).
• This is more clearly stated as solve for d given (d*e)mod φ(n) = 1
110
RSA (algorithm)
111
• This is often computed using the extended Euclidean algorithm.
• d is kept as the private key exponent.
The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the
modulus n and the private (or decryption) exponent d which must be kept secret.
Notes:
• An alternative, used by PKCS#1, is to choose d matching de ≡ 1 mod λ with λ = lcm(p − 1,q − 1), where lcm is
the least common multiple. Using λ instead of φ(n) allows more choices for d. λ can also be defined using the
Carmichael function, λ(n).
• The ANSI X9.31 standard prescribes, IEEE 1363 describes, and PKCS#1 allows, that p and q match additional
requirements: be strong primes, and be different enough that Fermat factorization fails.
Encryption
Alice transmits her public key
to Bob and keeps the private key secret. Bob then wishes to send message M
to Alice.
He first turns M into an integer m, such that
padding scheme. He then computes the ciphertext
by using an agreed-upon reversible protocol known as a
corresponding to
.
This can be done quickly using the method of exponentiation by squaring. Bob then transmits
to Alice.
Note that at least nine values of m will yield a ciphertext c equal to m[6], But this is very unlikely to occur in
practice.
Decryption
Alice can recover
from
by using her private key exponent
via computing
.
Given
, she can recover the original message M by reversing the padding scheme.
(In practice, there are more efficient methods of calculating
using the pre computed values below.)
Using the Chinese remainder algorithm
For efficiency many popular crypto libraries (like OpenSSL, Java and .NET) use the following optimization for
decryption and signing: The following values are precomputed and stored as part of the private key:
•
and
: the primes from the key generation,
•
,
•
•
and
.
These values allow the recipient to compute the exponentiation
•
•
•
(if
more efficiently as follows:
then some libraries compute h as
)
•
This is more efficient than computing
even though two modular exponentiations have to be
computed. The reason is that these two modular exponentiations both use a smaller exponent and a smaller modulus.
RSA (algorithm)
112
A working example
Here is an example of RSA encryption and decryption. The parameters used here are artificially small, but one can
also use OpenSSL to generate and examine a real keypair.
1. Choose two distinct prime numbers, such as
and
.
giving
2. Compute
n = 61 · 53 = 3233.
3. Compute the totient of the product as
.
that is coprime to 3120. Choosing a prime number for
4. Choose any number
check that
leaves us only to
is not a divisor of 3120.
Let
5. Compute
giving
.
, the modular multiplicative inverse of
yielding
.
The public key is (
,
). For a padded plaintext message
, the encryption function is
.
The private key is (
,
). For an encrypted ciphertext
, the decryption function is
.
For instance, in order to encrypt
, we calculate
.
To decrypt
, we calculate
.
Both of these calculations can be computed efficiently using the square-and-multiply algorithm for modular
exponentiation. In real life situations the primes selected would be much larger; in our example it would be relatively
trivial to factor , 3233, obtained from the freely available public key back to the primes and . Given , also
from the public key, we could then compute
and so acquire the private key.
Practical implementations use Chinese remainder theorem to speed up the calculation using modulus of factors (mod
p*q using mod p and mod q).
The values dp, dq and qInv, which are part of the private key are computed as follows:
•
•
•
(Hence:
)
Here is how dp, dq and qInv are used for efficient decryption. (Encryption is efficient by choice of public exponent
e)
•
•
•
•
(same as above but computed more efficiently)
RSA (algorithm)
113
Attacks against plain RSA
There are a number of attacks against plain RSA as described below.
• When encrypting with low encryption exponents (e.g.,
the result of
is strictly less than the modulus
) and small values of the
, (i.e.
)
. In this case, ciphertexts can be easily decrypted by taking
the th root of the ciphertext over the integers.
• If the same clear text message is sent to or more recipients in an encrypted way, and the receivers share the
same exponent , but different , , and therefore , then it is easy to decrypt the original clear text
message via the Chinese remainder theorem. Johan Håstad noticed that this attack is possible even if the cleartexts
are not equal, but the attacker knows a linear relation between them.[7] This attack was later improved by Don
Coppersmith.[8]
• Because RSA encryption is a deterministic encryption algorithm – i.e., has no random component – an attacker
can successfully launch a chosen plaintext attack against the cryptosystem, by encrypting likely plaintexts under
the public key and test if they are equal to the ciphertext. A cryptosystem is called semantically secure if an
attacker cannot distinguish two encryptions from each other even if the attacker knows (or has chosen) the
corresponding plaintexts. As described above, RSA without padding is not semantically secure.
• RSA has the property that the product of two ciphertexts is equal to the encryption of the product of the respective
plaintexts. That is
Because of this multiplicative property a chosen-ciphertext
attack is possible. E.g. an attacker, who wants to know the decryption of a ciphertext
ask the holder of the private key to decrypt an unsuspicious-looking ciphertext
value
chosen by the attacker. Because of the multiplicative property
with the modular inverse of
modulo
for some
is the encryption of
Hence, if the attacker is successful with the attack, he will learn
message m by multiplying
may
.
from which he can derive the
.
Padding schemes
To avoid these problems, practical RSA implementations typically embed some form of structured, randomized
padding into the value
before encrypting it. This padding ensures that
does not fall into the range of insecure
plaintexts, and that a given message, once padded, will encrypt to one of a large number of different possible
ciphertexts.
Standards such as PKCS#1 have been carefully designed to securely pad messages prior to RSA encryption. Because
these schemes pad the plaintext
with some number of additional bits, the size of the un-padded message M must
be somewhat smaller. RSA padding schemes must be carefully designed so as to prevent sophisticated attacks which
may be facilitated by a predictable message structure. Early versions of the PKCS#1 standard (up to version 1.5)
used a construction that turned RSA into a semantically secure encryption scheme. This version was later found
vulnerable to a practical adaptive chosen ciphertext attack. Later versions of the standard include Optimal
Asymmetric Encryption Padding (OAEP), which prevents these attacks. The PKCS#1 standard also incorporates
processing schemes designed to provide additional security for RSA signatures, e.g., the Probabilistic Signature
Scheme for RSA (RSA-PSS).
RSA (algorithm)
114
Signing messages
Suppose Alice uses Bob's public key to send him an encrypted message. In the message, she can claim to be Alice
but Bob has no way of verifying that the message was actually from Alice since anyone can use Bob's public key to
send him encrypted messages. In order to verify the origin of a message, RSA can also be used to sign a message.
Suppose Alice wishes to send a signed message to Bob. She can use her own private key to do so. She produces a
hash value of the message, raises it to the power of
(as she does when decrypting a message), and
attaches it as a "signature" to the message. When Bob receives the signed message, he uses the same hash algorithm
in conjunction with Alice's public key. He raises the signature to the power of
(as he does when
encrypting a message), and compares the resulting hash value with the message's actual hash value. If the two agree,
he knows that the author of the message was in possession of Alice's private key, and that the message has not been
tampered with since.
Secure padding schemes such as RSA-PSS are as essential for the security of message signing as they are for
message encryption. The same key should never be used for both encryption and signing.[9]
Security and practical considerations
Integer factorization and RSA problem
The security of the RSA cryptosystem is based on two mathematical problems: the problem of factoring large
numbers and the RSA problem. Full decryption of an RSA ciphertext is thought to be infeasible on the assumption
that both of these problems are hard, i.e., no efficient algorithm exists for solving them. Providing security against
partial decryption may require the addition of a secure padding scheme.
The RSA problem is defined as the task of taking th roots modulo a composite : recovering a value
such
that
, where
is an RSA public key and is an RSA ciphertext. Currently the most
promising approach to solving the RSA problem is to factor the modulus
factors, an attacker can compute the secret exponent from a public key
procedure. To accomplish this, an attacker factors
the determination of
from
into
and
. With the ability to recover prime
, then decrypt using the standard
, and computes
which allows
. No polynomial-time method for factoring large integers on a classical computer has
yet been found, but it has not been proven that none exists. See integer factorization for a discussion of this problem.
Rivest, Shamir and Adleman note[1] that Miller has shown that - assuming the Extended Riemann Hypothesis
(though others call it the Generalized Riemann Hypothesis) - finding d from n and e is as hard as factoring n into p
and q (up to a polynomial time difference).[10] However, this proof does not imply that inverting RSA is equally hard
as factoring.
As of 2010, the largest (known) number factored by a general-purpose factoring algorithm was 768 bits long (see
RSA-768), using a state-of-the-art distributed implementation. RSA keys are typically 1024–2048 bits long. Some
experts believe that 1024-bit keys may become breakable in the near future (though this is disputed); few see any
way that 4096-bit keys could be broken in the foreseeable future. Therefore, it is generally presumed that RSA is
secure if is sufficiently large. If is 300 bits or shorter, it can be factored in a few hours on a personal computer,
using software already freely available. Keys of 512 bits have been shown to be practically breakable in 1999 when
RSA-155 was factored by using several hundred computers and are now factored in a few weeks using common
hardware.[11] Exploits using 512-bit code-signing certificates that may have been factored were reported in 2011.[12]
A theoretical hardware device named TWIRL and described by Shamir and Tromer in 2003 called into question the
security of 1024 bit keys. It is currently recommended that be at least 2048 bits long.[13]
In 1994, Peter Shor showed that a quantum computer (if one could ever be practically created for the purpose) would
be able to factor in polynomial time, breaking RSA.
RSA (algorithm)
115
Key generation
Finding the large primes p and q is usually done by testing random numbers of the right size with probabilistic
primality tests which quickly eliminate virtually all non-primes.
Numbers p and q should not be 'too close', lest the Fermat factorization for n be successful, if p − q, for instance is
less than 2n1/4 (which for even small 1024-bit values of n is 3×1077) solving for p and q is trivial. Furthermore, if
either p − 1 or q − 1 has only small prime factors, n can be factored quickly by Pollard's p − 1 algorithm, and these
values of p or q should therefore be discarded as well.
It is important that the private key d be large enough. Michael J. Wiener showed[14] that if p is between q and 2q
(which is quite typical) and d < n1/4/3, then d can be computed efficiently from n and e.
There is no known attack against small public exponents such as e = 3, provided that proper padding is used.
However, when no padding is used, or when the padding is improperly implemented, small public exponents have a
greater risk of leading to an attack, such as the unpadded plaintext vulnerability listed above. 65537 is a commonly
used value for e. This value can be regarded as a compromise between avoiding potential small exponent attacks and
still allowing efficient encryptions (or signature verification). The NIST Special Publication on Computer Security
(SP 800-78 Rev 1 of August 2007) does not allow public exponents e smaller than 65537, but does not state a reason
for this restriction.
This procedure raises additional security issues. For instance, it is of utmost importance to use a strong random
number generator for the symmetric key, because otherwise Eve (an eavesdropper wanting to see what was sent)
could bypass RSA by guessing the symmetric key.
Timing attacks
Kocher described a new attack on RSA in 1995: if the attacker Eve knows Alice's hardware in sufficient detail and is
able to measure the decryption times for several known ciphertexts, she can deduce the decryption key quickly.
This attack can also be applied against the RSA signature scheme. In 2003, Boneh and Brumley demonstrated a
more practical attack capable of recovering RSA factorizations over a network connection (e.g., from a Secure
Socket Layer (SSL)-enabled webserver)[15] This attack takes advantage of information leaked by the Chinese
remainder theorem optimization used by many RSA implementations.
One way to thwart these attacks is to ensure that the decryption operation takes a constant amount of time for every
ciphertext. However, this approach can significantly reduce performance. Instead, most RSA implementations use an
alternate technique known as cryptographic blinding. RSA blinding makes use of the multiplicative property of RSA.
Instead of computing
, Alice first chooses a secret random value and computes
. The result of this computation after applying Euler's Theorem is
removed by multiplying by its inverse. A new value of
and so the effect of
can be
is chosen for each ciphertext. With blinding applied, the
decryption time is no longer correlated to the value of the input ciphertext and so the timing attack fails.
Adaptive chosen ciphertext attacks
In 1998, Daniel Bleichenbacher described the first practical adaptive chosen ciphertext attack, against
RSA-encrypted messages using the PKCS #1 v1 padding scheme (a padding scheme randomizes and adds structure
to an RSA-encrypted message, so it is possible to determine whether a decrypted message is valid.) Due to flaws
with the PKCS #1 scheme, Bleichenbacher was able to mount a practical attack against RSA implementations of the
Secure Socket Layer protocol, and to recover session keys. As a result of this work, cryptographers now recommend
the use of provably secure padding schemes such as Optimal Asymmetric Encryption Padding, and RSA
Laboratories has released new versions of PKCS #1 that are not vulnerable to these attacks.
RSA (algorithm)
116
Side-channel analysis attacks
A side-channel attack using branch prediction analysis (BPA) has been described. Many processors use a branch
predictor to determine whether a conditional branch in the instruction flow of a program is likely to be taken or not.
Often these processors also implement simultaneous multithreading (SMT). Branch prediction analysis attacks use a
spy process to discover (statistically) the private key when processed with these processors.
Simple Branch Prediction Analysis (SBPA) claims to improve BPA in a non-statistical way. In their paper, "On the
Power of Simple Branch Prediction Analysis",[16] the authors of SBPA (Onur Aciicmez and Cetin Kaya Koc) claim
to have discovered 508 out of 512 bits of an RSA key in 10 iterations.
A power fault attack on RSA implementations has been described in 2010.[17] The authors recovered the key by
varying the CPU power voltage outside limits; this caused multiple power faults on the server.
Proofs of correctness
Proof using Fermat's Little Theorem
The proof of the correctness of RSA is based on Fermat's little theorem. This theorem states that if p is prime and p
does not divide an integer a then
We want to show (me)d
m
for every integer m when p and q are distinct prime numbers and e and d are
positive integers satisfying
We can write
for some nonnegative integer h.
To check two numbers, like med and m, are congruent mod pq it suffices (and in fact is equivalent) to check they are
congruent mod p and mod q separately. (This is part of the Chinese remainder theorem, although it is not the
significant part of that theorem.) To show med
m mod p, we consider two cases: m 0 mod p and m
0 mod
p. In the first case med is a multiple of p, so med
0
m mod p. In the second case
where we used Fermat's little theorem to replace mp-1 mod p with 1.
The verification that med
m mod q proceeds in a similar way, treating separately the cases m
0 mod q, using Fermat's little theorem for modulus q in the second case.
0 mod q and m
This completes the proof that, for any integer m,
Proof using Euler's Theorem
Although the original paper of Rivest, Shamir, and Adleman used Fermat's little theorem to explain why RSA works,
it is common to find proofs that rely instead on Euler's theorem.
We want to show med
m mod n, where n = pq is a product of two different prime numbers and e and d are
positive integers satisfying ed
1 mod
. Since e and d are positive, we can write
for
some nonnegative integer h. Assuming that m is relatively prime to n, we have
where the last congruence directly follows from Euler's theorem. When
is not relatively prime to , the
argument just given is invalid. However, the desired congruence is still true. Either m 0 mod p or m 0 mod q,
RSA (algorithm)
and these cases can be treated using the previous proof.
Numerous references which explain RSA using Euler's theorem deal with the case that the message m is not
relatively prime to the modulus pq by a misleading probabilistic argument: the proportion of integers mod pq that
have a factor in common with the modulus is 1 - (p-1)(q-1)/pq = 1/p + 1/q - 1/pq, which is very small when p and q
are large so the chance of the message having a factor in common with the modulus can be considered remote in
practice. What is misleading here is that, as the proof with Fermat's little theorem shows, nothing breaks down in the
case of messages having a factor in common with the modulus: one has med
m mod n for all m without
exceptions. Therefore the correctness of RSA should really be considered an application of Fermat's little theorem
rather than Euler's theorem, just as in the original RSA paper.
Notes
[1] Rivest, R.; A. Shamir; L. Adleman (1978). "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems" (http:/ / theory. lcs.
mit. edu/ ~rivest/ rsapaper. pdf). Communications of the ACM 21 (2): 120–126. doi:10.1145/359340.359342. .
[2] SIAM News, Volume 36, Number 5, June 2003 (http:/ / www. msri. org/ people/ members/ sara/ articles/ rsa. pdf), "Still Guarding Secrets
after Years of Attacks, RSA Earns Accolades for its Founders", by Sara Robinson
[4] http:/ / www. rsa. com/ press_release. aspx?id=261
[5] Boneh, Dan (1999). "Twenty Years of attacks on the RSA Cryptosystem" (http:/ / crypto. stanford. edu/ ~dabo/ abstracts/ RSAattack-survey.
html). Notices of the American Mathematical Society (AMS) 46 (2): 203–213. .
[6] Namely, the values of m which are equal to -1, 0, or 1 modulo p while also equal to -1, 0, or 1 modulo q. There will be more values of m
having c=m if p-1 or q-1 has other divisors in common with e-1 besides 2 because this gives more values of m such that
or
respectively.
[7] Johan Håstad, "On using RSA with Low Exponent in a Public Key Network", Crypto 85
[8] Don Coppersmith, "Small Solutions to Polynomial Equations, and Low Exponent RSA Vulnerabilities", Journal of Cryptology, v. 10, n. 4,
Dec. 1997
[9] http:/ / www. di-mgt. com. au/ rsa_alg. html#weaknesses
[10] Gary L. Miller, "Riemann's Hypothesis and Tests for Primality" (http:/ / www. cs. cmu. edu/ ~glmiller/ Publications/ Papers/ Mi75. pdf)
[11] 518-bit GNFS with msieve (http:/ / www. mersenneforum. org/ showthread. php?t=9787)
[12] RSA-512 certificates abused in-the-wild (http:/ / blog. fox-it. com/ 2011/ 11/ 21/ rsa-512-certificates-abused-in-the-wild/ )
[13] Has the RSA algorithm been compromised as a result of Bernstein's Paper? (http:/ / www. rsa. com/ rsalabs/ node. asp?id=2007) What key
size should I be using?
[14] Wiener, Michael J. (May 1990). "Cryptanalysis of short RSA secret exponents". Information Theory, IEEE Transactions on 36 (3):
553–558. doi:10.1109/18.54902.
[15] Remote timing attacks are practical. (http:/ / crypto. stanford. edu/ ~dabo/ papers/ ssl-timing. pdf). SSYM'03 Proceedings of the 12th
conference on USENIX Security Symposium.
[16] http:/ / citeseerx. ist. psu. edu/ viewdoc/ download?doi=10. 1. 1. 80. 1438& rep=rep1& type=pdf
[17] FaultBased Attack of RSA Authentication (http:/ / www. eecs. umich. edu/ ~valeria/ research/ publications/ DATE10RSA. pdf)
References
• Menezes, Alfred; Paul C. van Oorschot; Scott A. Vanstone (October 1996). Handbook of Applied Cryptography.
CRC Press. ISBN 0-8493-8523-7.
• Cormen, Thomas H.; Charles E. Leiserson; Ronald L. Rivest; Clifford Stein (2001). Introduction to Algorithms
(2e ed.). MIT Press and McGraw-Hill. pp. 881–887. ISBN 0-262-03293-7.
External links
• The Original RSA Patent as filed with the U.S. Patent Office by Rivest; Ronald L. (Belmont, MA), Shamir; Adi
(Cambridge, MA), Adleman; Leonard M. (Arlington, MA), December 14, 1977, U.S. Patent 4405829 (http://
www.google.com/patents?vid=4405829).
• PKCS #1: RSA Cryptography Standard (http://www.rsasecurity.com/rsalabs/node.asp?id=2125) (RSA
Laboratories website)
117
RSA (algorithm)
•
•
•
•
•
•
•
•
• The PKCS #1 standard "provides recommendations for the implementation of public-key cryptography based
on the RSA algorithm, covering the following aspects: cryptographic primitives; encryption schemes;
signature schemes with appendix; ASN.1 syntax for representing keys and for identifying the schemes".
Thorough walk through of RSA (http://www.di-mgt.com.au/rsa_alg.html)
Prime Number Hide-And-Seek: How the RSA Cipher Works (http://www.muppetlabs.com/~breadbox/txt/rsa.
html)
Menezes, Oorschot, Vanstone, Scott: Handbook of Applied Cryptography (free PDF downloads), see Chapter 8
(http://www.cacr.math.uwaterloo.ca/hac/)
Onur Aciicmez, Cetin Kaya Koc, Jean-Pierre Seifert: On the Power of Simple Branch Prediction Analysis (http://
eprint.iacr.org/2006/351)
A New Vulnerability In RSA Cryptography, CAcert NEWS Blog (http://blog.cacert.org/2006/11/193.html)
Example of an RSA implementation with PKCS#1 padding (GPL source code) (http://polarssl.org/
source_code)
Kocher's article about timing attacks (http://www.cryptography.com/resources/whitepapers/TimingAttacks.
pdf)
Online RSA encryption application (http://www.gax.nl/wiskundePO/) (Dutch)
• An animated explanation of RSA with its mathematical background by CrypTool (http://www.cryptool.org/
images/ct1/presentations/RSA/RSA-Flash-en/player.html)
S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of
MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly
RFCs(3369,3370,3850,3851). S/MIME was originally developed by RSA Data Security Inc. The original
specification used the IETF MIME specification[1] with the de facto industry standard PKCS#7 secure message
format. Change control to S/MIME has since been vested in the IETF and the specification is now layered on
Cryptographic Message Syntax, an IETF specification that is identical in most respects with PKCS #7. S/MIME
functionality is built into the majority of modern email software and interoperates between them.
Function
S/MIME provides the following cryptographic security services for electronic messaging applications:
authentication, message integrity, non-repudiation of origin (using digital signatures), privacy and data security
(using encryption). S/MIME specifies the MIME type application/pkcs7-mime (smime-type
"enveloped-data") for data enveloping (encrypting) where the whole (prepared) MIME entity to be enveloped is
encrypted and packed into an object which subsequently is inserted into an application/pkcs7-mime MIME entity.
S/MIME certificates
Before S/MIME can be used in any of the above applications, one must obtain and install an individual
key/certificate either from one's in-house certificate authority (CA) or from a public CA. The accepted best practice
is to use separate private keys (and associated certificates) for signature and for encryption, as this permits escrow of
the encryption key without compromise to the non-repudiation property of the signature key. Encryption requires
having the destination party's certificate on store (which is typically automatic upon receiving a message from the
party with a valid signing certificate). While it is technically possible to send a message encrypted (using the
destination party certificate) without having one's own certificate to digitally sign, in practice, the S/MIME clients
will require you install your own certificate before they allow encrypting to others.
118
S/MIME
A typical basic ("class 1") personal certificate verifies the owner's "identity" only insofar as it declares that sender is
the owner of the "From:" email address in the sense that the sender can receive email sent to that address, and so
merely proves that an email received really did come from the "From:" address given. It does not verify the person's
name or business name. If a sender wishes to enable email recipients to verify the sender's identity in the sense that a
received certificate name carries the sender's name or an organization's name, the sender needs to obtain a certificate
("class 2") from a CA who carries out a more in-depth identity verification process, and this involves making
enquiries about the would-be certificate holder. For more detail on authentication, see digital signature.
Depending on the policy of the CA, your certificate and all its contents may be posted publicly for reference and
verification. This makes your name and email address available for all to see and possibly search for. Other CAs
only post serial numbers and revocation status, which does not include any of the personal information. The latter, at
a minimum, is mandatory to uphold the integrity of the public key infrastructure.
Obstacles to deploying S/MIME in practice
• Not all email software handles S/MIME signatures, resulting in an attachment called smime.p7s that may confuse
some people.
• S/MIME is sometimes considered not properly suited for use via webmail clients, however, the proprietary
S/MIME capable multi-browser extension Penango [2] is a counter-example. Penango can enable support for
webmail based browsing with specific webmail mail user agents (Gmail and Zimbra) using Firefox and Internet
Explorer. Though support can be hacked into a browser, some security practices require the private key to be kept
accessible to the user but inaccessible from the webmail server, complicating the key webmail advantage of
providing ubiquitous accessibility. This issue is not fully specific to S/MIME - other secure methods of signing
webmail may also require a browser to execute code to produce the signature, exceptions are PGP Desktop and
versions of GnuPG, who will grab the data out of the webmail, sign it by means of a clipboard, and put the signed
data back into the webmail page. Seen from the view of security this is even the more secure solution.
• Some organizations consider it acceptable for webmail servers to be "in on the secrets"; others don't. Some of
the considerations are mentioned below regarding malware. Another argument is that servers often contain
data that is confidential to the organization anyway, so what difference does it make if additional data, such a
private keys used for decryption, are also stored and used on such servers?
• Many make a distinction between private keys used for decryption and those used for digital signatures. They
are far more likely to accept sharing of the former than the latter. This is especially true if the non-repudiation
aspect of digital signatures is a concern (it may not be). There is fairly universal consensus that
non-repudiation requires that a private key be under sole control of its owner during its entire lifecycle.
Therefore, decryption done with webmail servers is more likely to be acceptable than digital signatures.
• S/MIME is tailored for end to end security. Logically you can't have a third party inspecting your email for
malware and have secure end-to-end communications. Encryption will not only encrypt your messages, but also
malware. Thus if your mail is scanned for malware anywhere but at the end points, such as your company's
gateway, encryption will defeat the detector and successfully deliver the malware. The only solution to this is to
perform malware scanning on end user stations after decryption. Other solutions do not provide end to end trust
as they require keys to be shared a third party for the purpose of detecting malware. Examples of this type of
compromise are:
• Solutions which store private keys on the gateway server so decryption can occur prior to the gateway malware
scan. These unencrypted messages are then delivered to end users.
• Solutions which store private keys on malware scanners so that it can inspect messages content, the encrypted
message is then relayed to its destination.
• Due to the requirement of a certificate for implementation, not all users can take advantage of S/MIME, as some
may wish to encrypt a message, with a public/private key pair for example, without the involvement or
119
S/MIME
administrative overhead of certificates.
Even more generally, any messages that an S/MIME client stores in their encrypted form will not be decryptable if
the certificate/private key used for encryption has been deleted or otherwise not available, whether that certificate
has expired or not. Also because of encrypted storage searching and indexing of encrypted message contents is not
possible in many clients. This is not specific to S/MIME however, and is not a problem in messages that are only
signed with S/MIME.
S/MIME signatures are usually done with what's called "detached signatures". The signature information is separate
from the text being signed. The MIME type for this is multipart/signed with the second part having a MIME subtype
of application/(x-)pkcs7-signature. Mailing list software is notorious for changing the textual part and thereby
invalidating the signature. However, this is not specific to S/MIME, and a digital signature only reveals that the
signed content has been changed.
External links
• RFC 3851: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
• RFC 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (Draft
Tracker [3])
• How to secure email using S/MIME standard [4]
• Penango [2]
References
[1]
[2]
[3]
[4]
RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One was published in November 1996
http:/ / www. penango. com/
http:/ / datatracker. ietf. org/ doc/ rfc5751/
http:/ / yplakosh. blogspot. com/ 2008/ 10/ how-to-secure-email-using-smime. html
120
Secure Electronic Transaction (SET) was a standard protocol for securing credit card transactions over insecure
networks, specifically, the Internet. SET was not itself a payment system, but rather a set of security protocols and
formats that enable users to employ the existing credit card payment infrastructure on an open network in a secure
fashion. However, it failed to gain traction. VISA now promotes the 3-D Secure scheme.
SET was developed by SETco, led by VISA and MasterCard (and involving other companies such as GTE, IBM,
Microsoft, Netscape, RSA, Safelayer --formerly SET Projects-- and VeriSign) starting in 1996. SET was based on
X.509 certificates with several extensions. The first version was finalised in May 1997 and a pilot test was
announced in July 1998.
SET allowed parties to cryptographically identify themselves to each other and exchange information securely. SET
used a blinding algorithm that, in effect, would have let merchants substitute a certificate for a user's credit-card
number. If SET were used, the merchant itself would never have had to know the credit-card numbers being sent
from the buyer, which would have provided verified good payment but protected customers and credit companies
from fraud.
SET was intended to become the de facto standard of payment method on the Internet between the merchants, the
buyers, and the credit-card companies. Despite heavy publicity, it failed to win market share. Reasons for this
include:
• Network effect - need to install client software (an e-wallet).
• Cost and complexity for merchants to offer support and comparatively low cost and simplicity of the existing SSL
based alternative.
• Client-side certificate distribution logistics.
Key features
To meet the business requirements, SET incorporates the following features:
•
•
•
•
Confidentiality of information
Integrity of data
Cardholder account authentication
Merchant authentication
Participants
A SET system includes the following participants:
•
•
•
•
•
•
Cardholder
Merchant
Issuer
Acquirer
Payment gateway
Certification authority
121
Transaction
The sequence of events required for a transaction are as follows:
1. The customer obtains a credit card account with a bank that supports electronic payment and SET
2. The customer receives a X.509v3 digital certificate signed by the bank.
3. Merchants have their own certificates
4. The customer places an order
5. The merchant sends a copy of its certificate so that the customer can verify that it's a valid store
6. The order and payment are sent
7. The merchant requests payment authorization
8. The merchant confirms the order
9. The merchant ships the goods or provides the service to the customer
10. The merchant requests payment
Dual signature
An important innovation introduced in SET is the dual signature. The purpose of the dual signature is the same as
the standard electronic signature: to guarantee the authentication and integrity of data. It links two messages that are
intended for two different recipients. In this case, the customer wants to send the order information (OI) to the
merchant and the payment information (PI) to the bank. The merchant does not need to know the customer's credit
card number, and the bank does not need to know the details of the customer's order. The link is needed so that the
customer can prove that the payment is intended for this order.
The message digest (MD) of the OI and the PI are independently calculated by the customer. The dual signature is
the encrypted MD (with the customer's secret key) of the concatenated MD's of PI and OI. The dual signature is sent
to both the merchant and the bank. The protocol arranges for the merchant to see the MD of the PI without seeing the
PI itself, and the bank sees the MD of the OI but not the OI itself. The dual signature can be verified using the MD of
the OI or PI. It doesn't require the OI or PI itself. Its MD does not reveal the content of the OI or PI, and thus privacy
is preserved.
122
Secure Shell
Secure Shell
Secure Shell (SSH) is a network protocol for secure data communication, remote shell services or command
execution and other secure network services between two networked computers that it connects via a secure channel
over an insecure network: a server and a client (running SSH server and SSH client programs, respectively).[1] The
protocol specification distinguishes two major versions that are referred to as SSH-1 and SSH-2.
The best-known application of the protocol is for access to shell accounts on Unix-like operating systems. It was
designed as a replacement for Telnet and other insecure remote shell protocols such as the Berkeley rsh and rexec
protocols, which send information, notably passwords, in plaintext, rendering them susceptible to interception and
disclosure using packet analysis.[2] The encryption used by SSH is intended to provide confidentiality and integrity
of data over an unsecured network, such as the Internet.
Definition
SSH uses public-key cryptography to authenticate the remote computer and allow it to authenticate the user, if
necessary.[1] Anyone can produce a matching pair of different keys (public and private). The public key is placed on
all computers that must allow access to the owner of the matching private key (the owner keeps the private key
secret). While authentication is based on the private key, the key itself is never transferred through the network
during authentication.
SSH only verifies if the same person offering the public key also owns the matching private key. Hence, in all
versions of SSH it is important to verify unknown public keys before accepting them as valid. Accepting an
attacker's public key without validation will authorize an unauthorized attacker as a valid user.
Key management
On Unix-like systems, the list of authorized keys is stored in the home folder of the user that is allowed to log in
remotely, in the file ~/.ssh/authorized_keys.[3] This file is only respected by ssh if it is not writable by anything apart
from the owner and root. When the public key is present on one side and the matching private key is present on
another side, typing in the password is no longer required (some software like MPI stack may need this
password-less access to run properly). However, for additional security the private key itself can be locked with a
passphrase.
The private key can also be looked for in standard places, but its full path can also be specified as a command line
setting (the switch -i for ssh). The ssh-keygen utility produces the public and private keys, always in pairs.
SSH also supports password-based authentication that is encrypted by automatically generated keys. In this case the
attacker could imitate the legitimate side, ask for the password and obtain it (man-in-the-middle attack). However
this is only possible if the two sides have never authenticated before, as SSH remembers the key that the remote side
once used. Password authentication can be disabled.
123
Secure Shell
Usage
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding
TCP ports and X11 connections; it can transfer files using the associated SSH file transfer (SFTP) or secure copy
(SCP) protocols.[1] SSH uses the client-server model.
The standard TCP port 22 has been assigned for contacting SSH servers,[4] though administrators frequently change
it to a non-standard port as an additional security measure.
An SSH client program is typically used for establishing connections to an SSH daemon accepting remote
connections. Both are commonly present on most modern operating systems, including Mac OS X, most
distributions of GNU/Linux, OpenBSD, FreeBSD, Solaris and OpenVMS. Proprietary, freeware and open source
versions of various levels of complexity and completeness exist.
Version 1.x
In 1995, Tatu Ylönen, a researcher at Helsinki University of Technology, Finland, designed the first version of the
protocol (now called SSH-1) prompted by a password-sniffing attack at his university network. The goal of SSH was
to replace the earlier rlogin, TELNET and rsh protocols, which did not provide strong authentication nor guarantee
confidentiality. Ylönen released his implementation as freeware in July 1995, and the tool quickly gained in
popularity. Towards the end of 1995, the SSH user base had grown to 20,000 users in fifty countries.
In December 1995, Ylönen founded SSH Communications Security to market and develop SSH. The original
version of the SSH software used various pieces of free software, such as GNU libgmp, but later versions released by
SSH Secure Communications evolved into increasingly proprietary software.
It is estimated that, as of 2000, there were 2 million users of SSH.[5]
Notable vulnerabilities
In 1998 a vulnerability was described in SSH 1.5 which allowed the unauthorized insertion of content into an
encrypted SSH stream due to insufficient data integrity protection from CRC-32 used in this version of the
protocol.[6][7] A fix known as SSH Compensation Attack Detector[8] was introduced into most implementations.
Many of these updated implementations contained a new integer overflow vulnerability[9] that allowed attackers to
execute arbitrary code with the privileges of the SSH daemon, typically root.
In January 2001 a vulnerability was discovered that allows attackers to modify the last block of an IDEA-encrypted
session.[10] The same month, another vulnerability was discovered that allowed a malicious server to forward a client
authentication to another server.[11]
Since SSH-1 has inherent design flaws which make it vulnerable, it is now generally considered obsolete and should
be avoided by explicitly disabling fallback to SSH-1. Most modern servers and clients support SSH-2.
124
Secure Shell
Version 1.99
In January 2006, well after version 2.1 was established, RFC 4253 specified that an SSH server which supports both
2.0 and prior versions of SSH should identify its protoversion as 1.99.[12] This is not an actual version but a method
to identify backward compatibility.
OpenSSH and OSSH
In 1999, developers wanting a free software version to be available went back to the older 1.2.12 release of the
original SSH program, which was the last released under an open source license. Björn Grönvall's OSSH was
subsequently developed from this codebase. Shortly thereafter, OpenBSD developers forked Grönvall's code and did
extensive work on it, creating OpenSSH, which shipped with the 2.6 release of OpenBSD. From this version, a
"portability" branch was formed to port OpenSSH to other operating systems. As of 2005, OpenSSH was the single
most popular SSH implementation, coming by default in a large number of operating systems. OSSH meanwhile has
become obsolete.[13] OpenSSH continued to be maintained and now supports both 1.x and 2.0 versions.
Version 2.x
"Secsh" was the official Internet Engineering Task Force's (IETF) name for the IETF working group responsible for
version 2 of the SSH protocol.[14] In 2006, a revised version of the protocol, SSH-2, was adopted as a standard. This
version is incompatible with SSH-1. SSH-2 features both security and feature improvements over SSH-1. Better
security, for example, comes through Diffie-Hellman key exchange and strong integrity checking via message
authentication codes. New features of SSH-2 include the ability to run any number of shell sessions over a single
SSH connection.[15] Due to SSH-2's superiority and popularity over SSH-1, some implements such as Lsh[16] and
Dropbear[17], only support SSH-2 protocol.
Vulnerabilities
In November 2008, a vulnerability was discovered for all versions of SSH which allowed recovery of up to 32 bits of
plaintext from a block of ciphertext that was encrypted using what was then the standard default encryption mode,
CBC.[18]
Internet standard documentation
The following RFC publications by the IETF "secsh" working group document SSH-2 as a proposed Internet
standard.
•
•
•
•
•
•
•
•
•
•
RFC 4250, The Secure Shell (SSH) Protocol Assigned Numbers
RFC 4251, The Secure Shell (SSH) Protocol Architecture
RFC 4252, The Secure Shell (SSH) Authentication Protocol
RFC 4253, The Secure Shell (SSH) Transport Layer Protocol
RFC 4254, The Secure Shell (SSH) Connection Protocol
RFC 4255, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
RFC 4256, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
RFC 4335, The Secure Shell (SSH) Session Channel Break Extension
RFC 4344, The Secure Shell (SSH) Transport Layer Encryption Modes
RFC 4345, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
It was later modified and expanded by the following publications.
• RFC 4419, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol (March 2006)
• RFC 4432, RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol (March 2006)
125
Secure Shell
126
• RFC 4462, Generic Security Service Application Program Interface (GSS-API) Authentication and Key
Exchange for the Secure Shell (SSH) Protocol (May 2006)
• RFC 4716, The Secure Shell (SSH) Public Key File Format (November 2006)
• RFC 5656, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer (December 2009)
Uses
SSH is a protocol that can be used for many
applications across many platforms including Unix,
Microsoft Windows, Apple's Mac OS X, and Linux.
Some of the applications below may require features
that are only available or compatible with specific SSH
clients or servers. For example, using the SSH protocol
to implement a VPN is possible, but presently only
with the OpenSSH server and client implementation.
• For login to a shell on a remote host (replacing
Telnet and rlogin)
• For executing a single command on a remote host
(replacing rsh)
• Secure file transfer
• In combination with rsync to back up, copy and
mirror files efficiently and securely
Example of tunneling an X11 application over SSH: the user 'josh'
has SSHed from the local machine 'foofighter' to the remote machine
'tengwar' to run xeyes.
• For forwarding or tunneling a port (not to be
confused with a VPN, which routes packets between
different networks, or bridges two broadcast
domains into one).
• For using as a full-fledged encrypted VPN. Note that
only OpenSSH server and client supports this
feature.
• For forwarding X from a remote host (possible
through multiple intermediate hosts)
Logging into OpenWrt via SSH using PuTTY running on Windows.
• For browsing the web through an encrypted proxy connection with SSH clients that support the SOCKS protocol.
• For securely mounting a directory on a remote server as a filesystem on a local computer using SSHFS.
• For automated remote monitoring and management of servers through one or more of the mechanisms discussed
above.
• For development on a mobile or embedded device that supports SSH.
File transfer protocols using SSH
There are multiple mechanisms for transferring files using the Secure Shell protocols.
• Secure copy (SCP), which evolved from RCP protocol over SSH
• SSH File Transfer Protocol (SFTP), a secure alternative to FTP (not to be confused with FTP over SSH)
• Files transferred over shell protocol (a.k.a. FISH), released in 1998, which evolved from Unix shell commands
over SSH
Secure Shell
127
Architecture
The SSH-2 protocol has an internal architecture
(defined in RFC 4251) with well-separated layers.
These are:
• The transport layer (RFC 4253). This layer handles
initial key exchange as well as server authentication,
and sets up encryption, compression and integrity
verification. It exposes to the upper layer an
interface for sending and receiving plaintext packets
with sizes of up to 32,768 bytes each (more can be
allowed by the implementation). The transport layer
also arranges for key re-exchange, usually after 1
GB of data has been transferred or after 1 hour has
passed, whichever is sooner.
Diagram of the SSH-2 binary packet.
• The user authentication layer (RFC 4252). This
layer handles client authentication and provides a number of authentication methods. Authentication is
client-driven: when one is prompted for a password, it may be the SSH client prompting, not the server. The
server merely responds to the client's authentication requests. Widely used user authentication methods include
the following:
• password: a method for straightforward password authentication, including a facility allowing a password to be
changed. This method is not implemented by all programs.
• publickey: a method for public key-based authentication, usually supporting at least DSA or RSA keypairs,
with other implementations also supporting X.509 certificates.
• keyboard-interactive (RFC 4256): a versatile method where the server sends one or more prompts to enter
information and the client displays them and sends back responses keyed-in by the user. Used to provide
one-time password authentication such as S/Key or SecurID. Used by some OpenSSH configurations when
PAM is the underlying host authentication provider to effectively provide password authentication, sometimes
leading to inability to log in with a client that supports just the plain password authentication method.
• GSSAPI authentication methods which provide an extensible scheme to perform SSH authentication using
external mechanisms such as Kerberos 5 or NTLM, providing single sign on capability to SSH sessions. These
methods are usually implemented by commercial SSH implementations for use in organizations, though
OpenSSH does have a working GSSAPI implementation.
• The connection layer (RFC 4254). This layer defines the concept of channels, channel requests and global
requests using which SSH services are provided. A single SSH connection can host multiple channels
simultaneously, each transferring data in both directions. Channel requests are used to relay out-of-band channel
specific data, such as the changed size of a terminal window or the exit code of a server-side process. The SSH
client requests a server-side port to be forwarded using a global request. Standard channel types include:
• shell for terminal shells, SFTP and exec requests (including SCP transfers)
• direct-tcpip for client-to-server forwarded connections
• forwarded-tcpip for server-to-client forwarded connections
• The SSHFP DNS record (RFC 4255) provides the public host key fingerprints in order to aid in verifying the
authenticity of the host.
This open architecture provides considerable flexibility, allowing SSH to be used for a variety of purposes beyond a
secure shell. The functionality of the transport layer alone is comparable to Transport Layer Security (TLS); the user
authentication layer is highly extensible with custom authentication methods; and the connection layer provides the
Secure Shell
ability to multiplex many secondary sessions into a single SSH connection, a feature comparable to BEEP and not
available in TLS.
New enhancements to SSH
These are geared towards performance enhancements of SSH products:
•
•
•
•
SCTP: an enhancement over TCP for connection oriented transport layer protocol.
ECDSA: an enhancement over DSA or RSA for signing.
ECDH: an enhancement over DH (Plain Diffie Hellman KEX) for encryption key exchange.
UMAC: an enhancement over HMAC for MAC/integrity.
References
[1]
[2]
[3]
[4]
Network Working Group of the IETF, January 2006, RFC 4252, The Secure Shell (SSH) Authentication Protocol
SSH Hardens the Secure Shell (http:/ / www. serverwatch. com/ news/ print. php/ 3551081), Serverwatch.com
SSH setup manual (http:/ / wiki. qnap. com/ wiki/ How_To_Set_Up_Authorized_Keys)
port-numbers assignments (http:/ / www. iana. org/ assignments/ port-numbers) at iana.org
[5] Nicholas Rosasco and David Larochelle. "How and Why More Secure Technologies Succeed in Legacy Markets: Lessons from the Success
of SSH" (http:/ / www. cs. virginia. edu/ ~drl7x/ sshVsTelnetWeb3. pdf). Quoting Barrett and Silverman, SSH, the Secure Shell: The
Definitive Guide, O'Reilly & Associates (2001). Dept. of Computer Science, Univ. of Virginia. . Retrieved 2006-05-19.
[6] SSH Insertion Attack (http:/ / www. coresecurity. com/ content/ ssh-insertion-attack)
[7] Weak CRC allows packet injection into SSH sessions encrypted with block ciphers (http:/ / www. kb. cert. org/ vuls/ id/ 13877), US-CERT
[8] SSH CRC-32 Compensation Attack Detector Vulnerability (http:/ / www. securityfocus. com/ bid/ 2347/ discuss), SecurityFocus
[9] SSH CRC32 attack detection code contains remote integer overflow (http:/ / www. kb. cert. org/ vuls/ id/ 945216), US-CERT
[10] Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice (http:/ / www. kb. cert. org/ vuls/ id/ 315308),
US-CERT
[11] SSH-1 allows client authentication to be forwarded by a malicious server to another server (http:/ / www. kb. cert. org/ vuls/ id/ 684820),
US-CERT
[12] RFC 4253, section 5. Compatibility With Old SSH Versions (http:/ / tools. ietf. org/ html/ rfc4253#section-5. 1), IETF
[13] OSSH Information for VU#419241 (https:/ / www. kb. cert. org/ vuls/ id/ MIMG-6L4LBL)
[14] Secsh Protocol Documents (http:/ / www. vandyke. com/ technology/ drafts. html), VanDyke Software, Inc.
[15] SSH Frequently Asked Questions (http:/ / www. snailbook. com/ faq/ ssh-1-vs-2. auto. html)
[16] Official website of Lsh (http:/ / www. lysator. liu. se/ ~nisse/ lsh/ )
[17] Official website of Dropbear (https:/ / matt. ucc. asn. au/ dropbear/ dropbear. html)
[18] SSH CBC vulnerability (http:/ / www. kb. cert. org/ vuls/ id/ 958563), US-CERT
Further reading
• Daniel J. Barrett, Richard E. Silverman, and Robert G. Byrnes, SSH: The Secure Shell (The Definitive Guide),
O'Reilly 2005 (2nd edition). ISBN 0-596-00895-3
• Michael Stahnke, Pro OpenSSH, Apress 2005 ISBN 1-59059-476-2
• Tatu Ylönen (12 July 1995). "Announcement: Ssh (Secure Shell) Remote Login Program" (http://groups.
google.com/group/comp.security.unix/msg/67079d812a19f499?dmode=source&hl=en). comp.security.unix.
Original announcement of Ssh
• Himanshu Dwivedi; Implementing SSH, Wiley 2003. ISBN 978-0-471-45880-7
• This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed
under the GFDL.
128
Secure Shell
External links
• Old homepage for IETF 'secsh' working group, which has concluded (http://www.ietf.org/html.charters/OLD/
secsh-charter.html) (for SSH-2)
• SSH Protocols (http://www.snailbook.com/protocols.html)
Security service is a service, provided by a layer of communicating open systems, which ensures adequate security
of the systems or of data transfers[1] as defined by ITU-T X.800 Recommendation.
X.800 and ISO 7498-2 (Information processing systems – Open systems interconnection – Basic Reference Model –
Part 2: Security architecture)[2] are technically aligned. This model is widely recognized [3] [4]
A more general definition is in CNSS Instruction No. 4009 dated 26 April 2010 by Committee on National Security
Systems of United States of America: [5]
A capability that supports one, or more, of the security requirements (Confidentiality, Integrity, Availability).
Examples of security services are key management, access control, and authentication.
Another authoritative definition is in W3C Web service Glossary [6] adopted by NIST SP 800-95:[7]
A processing or communication service that is provided by a system to give a specific kind of protection to
resources, where said resources may reside with said system or reside with other systems, for example, an
authentication service or a PKI-based document attribution and authentication service. A security service is a
superset of AAA services. Security services typically implement portions of security policies and are
implemented via security mechanisms.
Basic security terminology
Information security and Computer security are disciplines that are dealing with the requirements of Confidentiality,
Integrity, Availability, the so called CIA Triad, of information assett of an organization(company or agency) or the
information managed by computers respectively.
There are threats that can attack the resources (information or devices to manage it) exploiting one or more
vulnerabilities. The resources can be protected by one or more countermeasures or security controls.[8]
So security services implement part of the countermeasures, trying to achieve the security requirements of an
organization.[3][9]
Basic OSI terminology
In order to let different devices (computers, routers, cellular phones) to communicate data in a standardized way,
communication protocols had been defined.
The ITU-T organization published a large set of protocols. The general architecture of these protocols is defined in
reccomandation X.200.[10]
The different means (air, cables) and ways (protocols and protocol stacks) to communicate are called a
communication network.
Security requirements are applicable at the information sent over the network. The discipline dealing with security
over a network is called Network security[11]
X.800 Recommendation[1]:
1. provides a general description of security services and related mechanisms, which may be provided by the
Reference Model; and
129
2. defines the positions within the Reference Model where the services and mechanisms may be provided.
This Recommendation extends the field of application of Recommendation X.200, to cover secure communications
between open systems.
According to X.200 Recommendation, in the so called OSI Reference model there are 7 layers, each one is
generically called N layer. The N+1 entity ask for transmission services to the N entity.[10]
At each level two entities ((N-entity) interact by means of the (N) protocol by transmitting Protocol Data Units
(PDU). Service Data Unit (SDU) is a specific unit of data that has been passed down from an OSI layer, to a lower
layer, and has not yet been encapsulated into a Protocol data Unit (PDU), by the lower layer. It is a set of data that is
sent by a user of the services of a given layer, and is transmitted semantically unchanged to a peer service user . The
PDU at any given layer, layer 'n', is the SDU of the layer below, layer 'n-1'. In effect the SDU is the 'payload' of a
given PDU. That is, the process of changing a SDU to a PDU, consists of an encapsulation process, performed by the
lower layer. All the data contained in the SDU becomes enapsulated within the PDU. The layer n-1 adds headers or
footers, or both, to the SDU, transforming it into a PDU of layer n-1. The added headers or footers are part of the
process used to make it possible to get data from a source to a destination.[10]
OSI Security Services General description
The following are considered to be the security services which can be provided optionally within the framework of
the OSI Reference Model. The authentication services require authentication information comprising locally stored
information and data that is transferred (credentials) to facilitate the authentication:[1][4]:
Authentication
These services provide for the authentication of a communicating peer entity and the source of data as
described below.
Peer entity authentication
This service, when provided by the (N)-layer, provides corroboration to the (N + 1)-entity that the peer
entity is the claimed (N + 1)-entity.
Data origin authentication
This service, when provided by the (N)-layer, provides corroboration to an (N + 1)-entity that the source
of the data is the claimed peer (N + 1)-entity.
Access control
This service provides protection against unauthorized use of resources accessible via OSI. These may be OSI
or non-OSI resources accessed via OSI protocols. This protection service may be applied to various types of
access to a resource (e.g., the use of a communications resource; the reading, the writing, or the deletion of an
information resource; the execution of a processing resource) or to all accesses to a resource.
Data confidentiality
These services provide for the protection of data from unauthorized disclosure as described below
Connection confidentiality
This service provides for the confidentiality of all (N)-user-data on an (N)-connection
Connectionless confidentiality
This service provides for the confidentiality of all (N)-user-data in a single connectionless (N)-SDU
Selective field confidentiality
This service provides for the confidentiality of selected fields within the (N)-user-data on an
(N)-connection or in a single connectionless (N)-SDU.
Traffic flow confidentiality
130
This service provides for the protection of the information which might be derived from observation of
traffic flows.
Data integrity
These services counter active threats and may take one of the forms described below.
Connection integrity with recovery
This service provides for the integrity of all (N)-user-data on an (N)-connection and detects any
modification, insertion, deletion or replay of any data within an entire SDU sequence (with recovery
attempted).
Connection integrity without recovery
As for the previous one but with no recovery attempted.
Selective field connection integrity
This service provides for the integrity of selected fields within the (N)-user data of an (N)-SDU
transferred over a connection and takes the form of determination of whether the selected fields have
been modified, inserted, deleted or replayed.
Connectionless integrity
This service, when provided by the (N)-layer, provides integrity assurance to the requesting (N +
1)-entity. This service provides for the integrity of a single connectionless SDU and may take the form
of determination of whether a received SDU has been modified. Additionally, a limited form of
detection of replay may be provided.
Selective field connectionless integrity
This service provides for the integrity of selected fields within a single connectionless SDU and takes
the form of determination of whether the selected fields have been modified.
Non-repudiation
This service may take one or both of two forms.
Non-repudiation with proof of origin
The recipient of data is provided with proof of the origin of data. This will protect against any attempt
by the sender to falsely deny sending the data or its contents.
Non-repudiation with proof of delivery
The sender of data is provided with proof of delivery of data. This will protect against any subsequent
attempt by the recipient to falsely deny receiving the data or its contents.
Specific security mechanisms
The security services may be provided by means of security mechanism:[1] [3][4]:
•
•
•
•
•
•
•
Encipherment
Digital signature
Access control
Data integrity
Authentication exchange
Traffic padding
Routing control
• Notarization
The table1/X.800 shows the relationships between services and mechanisms
131
132
Illustration of relationship of security services and mechanisms
Service
Mechanism
Encipherment Digital
signature
Access
control
Data
integrity
Authentication
exchange
Traffic
padding
Routing
control
Notarization
Y
Y
·
·
Y
·
·
·
Data origin authentication
Y
Y
·
·
·
·
·
·
Access control service
·
·
Y
·
·
·
·
·
Y
.
·
·
·
·
Y
·
Connectionless
confidentiality
Y
·
·
·
·
·
Y
·
Selective field
confidentiality
Y
·
·
·
·
·
·
·
Y
·
·
·
·
Y
Y
·
Connection Integrity with
recovery
Y
·
·
Y
·
·
·
·
Connection
integritywithout recovery
Y
·
·
Y
·
·
·
·
Selective field connection
integrity
Y
·
·
Y
·
·
·
·
Y
Y
·
Y
·
·
·
·
Selective field
connectionless integrity
Y
Y
·
Y
·
·
·
·
Non-repudiation. Origin
·
Y
·
Y
·
·
·
Y
Y
·
Y
·
·
·
Y
Non-repudiation. Delivery
Some of them can be applied to connection oriented protocols, other to connectionless protocols or both.
The table 2/X.800 illustrates the relationship of security services and layers:[4]:
Illustration of the relationship of security services and layers
Service
Layer
1 2 3 4 5 6 7*
·
·
Y Y ·
·
Y
Data origen authentication
·
·
Y Y ·
·
Y
Access control service
·
·
Y Y ·
·
Y
Y Y Y Y ·
Y Y
Connectionless confidentiality
·
Y Y Y ·
Y Y
Selective field confidentiality
·
·
Connection Integrity with recovery
·
·
Y Y
Y ·
Y ·
·
·
Y
·
·
·
Y ·
·
Y
Connection integrity without recovery ·
·
Y Y ·
·
Y
Selective field connection integrity
·
·
·
Y
·
·
·
·
133
·
·
Y Y ·
·
Y
Selective field connectionless integrity ·
·
·
·
·
·
Y
Non-repudiation Origin
·
·
·
·
·
·
Y
Non-repudiation. Delivery
·
·
·
·
·
·
Y
Other related meanings
Managed Security Service
Managed Security Service (MSS) are network security services that have been outsourced to a service provider.
References
[1] X.800 : Security architecture for Open Systems Interconnection for CCITT applications (http:/ / www. itu. int/ rec/ T-REC-X. 800-199103-I/
e)
[2] ISO 7498-2 (Information processing systems – Open systems interconnection – Basic Reference Model – Part 2: Security architecture) (http:/
/ www. iso. org/ iso/ search. htm?qt=ISO+ 7498-2+ & searchSubmit=Search& sort=rel& type=simple& published=on)
[3] William Stallings Crittografia e sicurezza delle reti Seconda edizione isbn 88-386-6377-7 Traduzione Italiana a cura di Luca Salgarelli di
Cryptography and Network security 4 edition Pearson 2006
[4] Securing information and communications systems: principles, technologies, and applications Steven Furnell, Sokratis Katsikas, Javier
Lopez, Artech House, 2008 - 362 pages
[5] CNSS Instruction No. 4009 (http:/ / www. cnss. gov/ Assets/ pdf/ cnssi_4009. pdf) dated 26 April 2010
[6] W3C Web Services Glossary (http:/ / www. w3. org/ TR/ ws-gloss/ )
[7] NIST Special Publication 800-95 Guide to Secure Web Services (http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-95/ SP800-95. pdf)
[8] Internet Engineering Task Force RFC 2828 Internet Security Glossary
[9] Network security essentials: applications and standards, William Stallings,Prentice Hall, 2007 - 413 pages
[10] X.200 : Information technology - Open Systems Interconnection - Basic Reference Model: The basic model (http:/ / www. itu. int/ rec/
T-REC-X. 200-199407-I/ en)]
[11] Simmonds, A; Sandilands, P; van Ekert, L (2004). "An Ontology for Network Security Attacks". Lecture Notes in Computer Science 3285:
317–323
External links
• Term in FISMApedia (http://fismapedia.org/index.php?title=Term:Countermeasure)
• List of ITU-T Security Activities and Pubblications (http://www.itu.int/itudoc/gs/promo/tsb/86261.pdf)
SHA-1
134
SHA-1
SHA-1
General
Designers
National Security Agency
First published
1993 (SHA-0),
1995 (SHA-1)
Series
(SHA-0), SHA-1, SHA-2, SHA-3
Certification
FIPS
Detail
Digest sizes
160 bits
Structure
Merkle–Damgård construction
Rounds
80
[1]
A 2008 attack by Stéphane Manuel breaks the hash function, as it can produce hash collisions with a complexity of 251 operations.
In cryptography, SHA-1 is a cryptographic hash function designed by the United States National Security Agency
and published by the United States NIST as a U.S. Federal Information Processing Standard. SHA stands for "secure
hash algorithm". The three SHA algorithms are structured differently and are distinguished as SHA-0, SHA-1, and
SHA-2. SHA-1 is very similar to SHA-0, but corrects an error in the original SHA hash specification that led to
significant weaknesses. The SHA-0 algorithm was not adopted by many applications. SHA-2 on the other hand
significantly differs from the SHA-1 hash function.
SHA-1 is the most widely used of the existing SHA hash functions, and is employed in several widely used security
applications and protocols. In 2005, security flaws were identified in SHA-1, namely that a mathematical weakness
might exist, indicating that a stronger hash function would be desirable.[2] Although no successful attacks have yet
been reported on the SHA-2 variants, they are algorithmically similar to SHA-1 and so efforts are underway to
develop improved alternatives.[3][4] A new hash standard, SHA-3, is currently under development — an ongoing
NIST hash function competition is scheduled to end with the selection of a winning function in 2012.
SHA-1
135
The SHA-1 hash function
SHA-1 produces a 160-bit message digest
based on principles similar to those used by
Ronald L. Rivest of MIT in the design of the
MD4 and MD5 message digest algorithms,
but has a more conservative design.
The original specification of the algorithm
was published in 1993 as the Secure Hash
Standard, FIPS PUB 180, by US
government standards agency NIST
(National Institute of Standards and
Technology). This version is now often
referred to as SHA-0. It was withdrawn by
NSA shortly after publication and was
superseded by the revised version, published
in 1995 in FIPS PUB 180-1 and commonly
referred to as SHA-1. SHA-1 differs from
SHA-0 only by a single bitwise rotation in
the message schedule of its compression
function; this was done, according to NSA,
to correct a flaw in the original algorithm
which reduced its cryptographic security.
However, NSA did not provide any further
explanation or identify the flaw that was
corrected. Weaknesses have subsequently
been reported in both SHA-0 and SHA-1.
SHA-1 appears to provide greater resistance
to attacks, supporting the NSA’s assertion
that the change increased the security.
One iteration within the SHA-1 compression function:
A, B, C, D and E are 32-bit words of the state;
F is a nonlinear function that varies;
denotes a left bit rotation by n places;
n
n varies for each operation;
Wt is the expanded message word of round t;
Kt is the round constant of round t;
denotes addition modulo 232.
Comparison of SHA functions
In the table below, internal state means the “internal hash sum” after each compression of a data block.
Further information: Merkle–Damgård construction
Algorithm and variant
Output
size
(bits)
Internal
state
size (bits)
Block
size
(bits)
Max
message
size (bits)
Word
size
(bits)
Rounds
Operations
Collisions
found?
SHA-0
160
160
512
264 − 1
32
80
add, and, or, xor, rotate,
mod
Yes
SHA-1
SHA-2
Theoretical attack
[5]
(251)
SHA-256/224
256/224
256
512
264 − 1
32
64
SHA-512/384
512/384
512
1024
2128 − 1
64
80
add, and, or, xor, shift,
rotate, mod
No
SHA-1
Applications
SHA-1 forms part of several widely used security applications and protocols, including TLS and SSL, PGP, SSH,
S/MIME, and IPsec. Those applications can also use MD5; both MD5 and SHA-1 are descended from MD4. SHA-1
hashing is also used in distributed revision control systems such as Git, Mercurial, and Monotone to identify
revisions, and to detect data corruption or tampering. The algorithm has also been used on Nintendo's Wii gaming
console for signature verification when booting, but a significant implementation flaw allows for an attacker to
bypass the system's security scheme.[6]
SHA-1 and SHA-2 are the secure hash algorithms required by law for use in certain U.S. Government applications,
including use within other cryptographic algorithms and protocols, for the protection of sensitive unclassified
information. FIPS PUB 180-1 also encouraged adoption and use of SHA-1 by private and commercial organizations.
SHA-1 is being retired for most government uses; the U.S. National Institute of Standards and Technology says,
"Federal agencies should stop using SHA-1 for...applications that require collision resistance as soon as practical,
and must use the SHA-2 family of hash functions for these applications after 2010" (emphasis in original).[7]
A prime motivation for the publication of the Secure Hash Algorithm was the Digital Signature Standard, in which it
is incorporated.
The SHA hash functions have been used as the basis for the SHACAL block ciphers.
Cryptanalysis and validation
For a hash function for which L is the number of bits in the message digest, finding a message that corresponds to a
given message digest can always be done using a brute force search in 2L evaluations. This is called a preimage
attack and may or may not be practical depending on L and the particular computing environment. The second
criterion, finding two different messages that produce the same message digest, known as a collision, requires on
average only 2L/2 evaluations using a birthday attack. For the latter reason the strength of a hash function is usually
compared to a symmetric cipher of half the message digest length. Thus SHA-1 was originally thought to have 80-bit
strength.
Cryptographers have produced collision pairs for SHA-0 and have found algorithms that should produce SHA-1
collisions in far fewer than the originally expected 280 evaluations.
In terms of practical security, a major concern about these new attacks is that they might pave the way to more
efficient ones. Whether this is the case is yet to be seen, but a migration to stronger hashes is believed to be prudent.
Some of the applications that use cryptographic hashes, such as password storage, are only minimally affected by a
collision attack. Constructing a password that works for a given account requires a preimage attack, as well as access
to the hash of the original password, which may or may not be trivial. Reversing password encryption (e.g. to obtain
a password to try against a user's account elsewhere) is not made possible by the attacks. (However, even a secure
password hash can't prevent brute-force attacks on weak passwords.)
In the case of document signing, an attacker could not simply fake a signature from an existing document—the
attacker would have to produce a pair of documents, one innocuous and one damaging, and get the private key
holder to sign the innocuous document. There are practical circumstances in which this is possible; until the end of
2008, it was possible to create forged SSL certificates using an MD5 collision.[8]
Due to the block and iterative structure of the algorithms and the absence of additional final steps, all SHA functions
are vulnerable to length-extension and partial-message collision attacks.[9] These attacks allow an attacker to forge a
message, signed only by a keyed hash or
- by extending the
message and recalculating the hash without knowing the key. The simplest improvement to prevent these attacks is
to hash twice (
- zero block, length is equal to block
size of hash function).
136
SHA-1
SHA-0
At CRYPTO 98, two French researchers, Florent Chabaud and Antoine Joux, presented an attack on SHA-0
(Chabaud and Joux, 1998 [10]): collisions can be found with complexity 261, fewer than the 280 for an ideal hash
function of the same size.
In 2004, Biham and Chen found near-collisions for SHA-0—two messages that hash to nearly the same value; in this
case, 142 out of the 160 bits are equal. They also found full collisions of SHA-0 reduced to 62 out of its 80 rounds.
Subsequently, on 12 August 2004, a collision for the full SHA-0 algorithm was announced by Joux, Carribault,
Lemuet, and Jalby. This was done by using a generalization of the Chabaud and Joux attack. Finding the collision
had complexity 251 and took about 80,000 CPU hours on a supercomputer with 256 Itanium 2 processors.
(Equivalent to 13 days of full-time use of the computer.)
On 17 August 2004, at the Rump Session of CRYPTO 2004, preliminary results were announced by Wang, Feng,
Lai, and Yu, about an attack on MD5, SHA-0 and other hash functions. The complexity of their attack on SHA-0 is
240, significantly better than the attack by Joux et al.[11][12]
In February 2005, an attack by Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu was announced which could find
collisions in SHA-0 in 239 operations.[13][14]
SHA-1
In light of the results for SHA-0, some experts suggested that plans for the use of SHA-1 in new cryptosystems
should be reconsidered. After the CRYPTO 2004 results were published, NIST announced that they planned to phase
out the use of SHA-1 by 2010 in favor of the SHA-2 variants.[15]
In early 2005, Rijmen and Oswald published an attack on a reduced version of SHA-1—53 out of 80 rounds—which
finds collisions with a computational effort of fewer than 280 operations.[16]
In February 2005, an attack by Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu was announced.[13] The attacks can
find collisions in the full version of SHA-1, requiring fewer than 269 operations. (A brute-force search would require
280 operations.)
The authors write: "In particular, our analysis is built upon the original differential attack on SHA-0 [sic], the near
collision attack on SHA-0, the multiblock collision techniques, as well as the message modification techniques used
in the collision search attack on MD5. Breaking SHA-1 would not be possible without these powerful analytical
techniques."[17] The authors have presented a collision for 58-round SHA-1, found with 233 hash operations. The
paper with the full attack description was published in August 2005 at the CRYPTO conference.
In an interview, Yin states that, "Roughly, we exploit the following two weaknesses: One is that the file
preprocessing step is not complicated enough; another is that certain math operations in the first 20 rounds have
unexpected security problems."[18]
On 17 August 2005, an improvement on the SHA-1 attack was announced on behalf of Xiaoyun Wang, Andrew Yao
and Frances Yao at the CRYPTO 2005 rump session, lowering the complexity required for finding a collision in
SHA-1 to 263.[19] On 18 December 2007 the details of this result were explained and verified by Martin Cochran.[20]
Christophe De Cannière and Christian Rechberger further improved the attack on SHA-1 in "Finding SHA-1
Characteristics: General Results and Applications,"[21] receiving the Best Paper Award at ASIACRYPT 2006. A
two-block collision for 64-round SHA-1 was presented, found using unoptimized methods with 235 compression
function evaluations. As this attack requires the equivalent of about 235 evaluations, it is considered to be a
significant theoretical break.[22] Their attack was extended further to 73 rounds (of 80) in 2010 by Grechnikov.[23] In
order to find an actual collision in the full 80 rounds of the hash function, however, massive amounts of computer
time are required. To that end, a collision search for SHA-1 using the distributed computing platform BOINC began
August 8, 2007, organized by the Graz University of Technology. The effort was abandoned May 12, 2009 due to
lack of progress.[24]
137
SHA-1
138
At the Rump Session of CRYPTO 2006, Christian Rechberger and Christophe De Cannière claimed to have
discovered a collision attack on SHA-1 that would allow an attacker to select at least parts of the message.[25][26]
In 2008, an attack methodology by Stéphane Manuel may produce hash collisions with an estimated theoretical
complexity of 251 to 257 operations.[27]
Cameron McDonald, Philip Hawkes and Josef Pieprzyk presented a hash collision attack with claimed complexity
252 at the Rump session of Eurocrypt 2009.[28] However, the accompanying paper, "Differential Path for SHA-1
with complexity O(252)" has been withdrawn due to the authors' discovery that their estimate was incorrect.[29]
Marc Stevens runs a project called HashClash[30], implementing a differential path attack against SHA-1. On 8
November 2010, he claimed he had a fully working near-collision attack against full SHA-1 working with an
estimated complexity equivalent to 257.5 SHA-1 compressions.
Official validation
Implementations of all FIPS-approved security functions can be officially validated through the CMVP program,
jointly run by the National Institute of Standards and Technology (NIST) and the Communications Security
Establishment (CSE). For informal verification, a package to generate a high number of test vectors is made
available for download on the NIST site; the resulting verification however does not replace, in any way, the formal
CMVP validation, which is required by law for certain applications.
As of February 2011, there are nearly 1400 validated implementations of SHA-1, with around a dozen of them
capable of handling messages with a length in bits not a multiple of eight (see SHS Validation List [31]).
Examples and pseudocode
Example hashes
These are examples of SHA-1 digests. ASCII encoding is used for all messages.
SHA1("The quick brown fox jumps over the lazy dog")
= 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12
Even a small change in the message will, with overwhelming probability, result in a completely different hash due to
the avalanche effect. For example, changing dog to cog produces a hash with different values for 81 of the 160
bits:
SHA1("The quick brown fox jumps over the lazy cog")
= de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3
The hash of the zero-length string is:
SHA1("")
= da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709
SHA-1 pseudocode
Pseudocode for the SHA-1 algorithm follows:
Note 1: All variables are unsigned 32 bits and wrap modulo 232 when calculating
Note 2: All constants in this pseudo code are in big endian.
Within each word, the most significant byte is stored in the leftmost byte position
Initialize variables:
h0 = 0x67452301
SHA-1
139
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0
Pre-processing:
append the bit '1' to the message
append 0 ≤ k < 512 bits '0', so that the resulting message length (in bits)
is congruent to 448 (mod 512)
append length of message (before pre-processing), in bits, as 64-bit big-endian integer
Process the message in successive 512-bit chunks:
break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words w[i], 0 ≤ i ≤ 15
Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
w[i] = (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1
Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4
[32]
Main loop:
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6
temp = (a leftrotate 5) + f + e + k + w[i]
e = d
d = c
c = b leftrotate 30
b = a
SHA-1
140
a = temp
Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e
Produce the final hash value (big-endian):
digest = hash = h0 append h1 append h2 append h3 append h4
The constant values used are chosen as nothing up my sleeve numbers: the four round constants k are 230 times the
square roots of 2, 3, 5 and 10. The first four starting values for h0 through h3 are the same as the MD5 algorithm,
and the fifth (for h4) is similar.
Instead of the formulation from the original FIPS PUB 180-1 shown, the following equivalent expressions may be
used to compute f in the main loop above:
(0
(0
(0
(0
(40
(40
(40
(40
≤i
≤i
≤i
≤i
≤ 19):
≤ 19):
≤ 19):
≤ 19):
f
f
f
f
=
=
=
=
d xor (b and (c xor d))
(b and c) xor ((not b) and d)
(b and c) + ((not b) and d)
vec_sel(d, c, b)
(alternative
(alternative
(alternative
(alternative
1)
2)
3)
4)
≤i
≤i
≤i
≤i
≤ 59):
≤ 59):
≤ 59):
≤ 59):
f
f
f
f
=
=
=
=
(b
(b
(b
(b
(alternative
(alternative
(alternative
(alternative
1)
2)
3)
4)
and
and
and
and
c)
c)
c)
c)
or (d and (b or c))
or (d and (b xor c))
+ (d and (b xor c))
xor (b and d) xor (c and d)
Max Locktyukhin has also shown[33] that for the rounds 32–79 the computation of:
can be replaced with:
This transformation keeps all operands 64-bit aligned and, by removing the dependency of w[i] on w[i-3],
allows efficient SIMD implementation with a vector length of 4 such as x86 SSE instructions.
SHA-1
References
[1] Stéphane Manuel. Classification and Generation of Disturbance Vectors for Collision Attacks against SHA-1 (http:/ / eprint. iacr. org/ 2008/
469. pdf). .
[2] Schneier on Security: Cryptanalysis of SHA-1 (http:/ / www. schneier. com/ blog/ archives/ 2005/ 02/ cryptanalysis_o. html)
[3] Schneier on Security: NIST Hash Workshop Liveblogging (5) (http:/ / www. schneier. com/ blog/ archives/ 2005/ 11/ nist_hash_works_4.
html)
[4] Hash cracked – heise Security (http:/ / www. heise-online. co. uk/ security/ Hash-cracked--/ features/ 75686/ 2)
[5] Classification and Generation of Disturbance Vectors for Collision Attacks against SHA-1 (http:/ / eprint. iacr. org/ 2008/ 469. pdf)
[6] http:/ / debugmo. de/ ?p=61 Debugmo.de "For verifiying the hash (which is the only thing they verify in the signature), they have chosen to
use a function (strncmp) which stops on the first nullbyte – with a positive result. Out of the 160 bits of the SHA1-hash, up to 152 bits are
thrown away."
[7] National Institute on Standards and Technology Computer Security Resource Center, NIST's Policy on Hash Functions (http:/ / csrc. nist.
gov/ groups/ ST/ hash/ policy. html), accessed March 29, 2009.
[8] Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger, MD5 considered
harmful today: Creating a rogue CA certificate (http:/ / www. win. tue. nl/ hashclash/ rogue-ca/ ), accessed March 29, 2009
[9] Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno, Cryptography Engineering (http:/ / www. schneier. com/ book-ce. html), John Wiley
& Sons, 2010. ISBN 978-0-470-47424-2
[10] http:/ / fchabaud. free. fr/ English/ Publications/ sha. pdf
[11] Freedom to Tinker » Blog Archive » Report from Crypto 2004 (http:/ / www. freedom-to-tinker. com/ archives/ 000664. html)
[12] Google.com (http:/ / groups. google. com/ groups?selm=fgrieu-05A994. 05060218082004@individual. net)
[13] Schneier on Security: SHA-1 Broken (http:/ / www. schneier. com/ blog/ archives/ 2005/ 02/ sha1_broken. html)
[14] (Chinese) Sdu.edu.cn (http:/ / www. infosec. sdu. edu. cn/ paper/ sha0-crypto-author-new. pdf), Shandong University
[15] National Institute of Standards and Technology (http:/ / csrc. nist. gov/ groups/ ST/ toolkit/ documents/ shs/ hash_standards_comments. pdf)
[16] Cryptology ePrint Archive (http:/ / eprint. iacr. org/ 2005/ 010)
[17] MIT.edu (http:/ / theory. csail. mit. edu/ ~yiqun/ shanote. pdf), Massachusetts Institute of Technology
[18] Fixing a hole in security | Tech News on ZDNet (http:/ / news. zdnet. com/ 2100-1009_22-5598536. html)
[19] Schneier on Security: New Cryptanalytic Results Against SHA-1 (http:/ / www. schneier. com/ blog/ archives/ 2005/ 08/ new_cryptanalyt.
html)
[20] Notes on the Wang et al. $2^{63}$ SHA-1 Differential Path (http:/ / eprint. iacr. org/ 2007/ 474)
[21] Christophe De Cannière, Christian Rechberger (2006-11-15). Finding SHA-1 Characteristics: General Results and Applications (http:/ /
www. springerlink. com/ content/ q42205u702p5604u/ ). .
[22] "IAIK Krypto Group – Description of SHA-1 Collision Search Project" (http:/ / www. iaik. tugraz. at/ content/ research/ krypto/ sha1/
SHA1Collision_Description. php). . Retrieved 2009-06-30.
[23] "Collisions for 72-step and 73-step SHA-1: Improvements in the Method of Characteristics" (http:/ / eprint. iacr. org/ 2010/ 413). . Retrieved
2010-07-24.
[24] "SHA-1 Collision Search Graz" (http:/ / boinc. iaik. tugraz. at/ sha1_coll_search/ ). . Retrieved 2009-06-30.
[25] SHA-1 hash function under pressure – heise Security (http:/ / www. heise-online. co. uk/ security/ SHA-1-hash-function-under-pressure--/
news/ 77244)
[26] Crypto 2006 Rump Schedule (http:/ / www. iacr. org/ conferences/ crypto2006/ rumpsched. html)
[27] Stéphane Manuel. Classification and Generation of Disturbance Vectors for Collision Attacks against SHA-1 (http:/ / eprint. iacr. org/ 2008/
469. pdf). . Retrieved 2011-05-19.
[28] SHA-1 collisions now 2^52 (http:/ / eurocrypt2009rump. cr. yp. to/ 837a0a8086fa6ca714249409ddfae43d. pdf)
[29] International Association for Cryptologic Research (http:/ / eprint. iacr. org/ 2009/ 259)
[30] HashClash - Framework for MD5 & SHA-1 Differential Path Construction and Chosen-Prefix Collisions for MD5 (http:/ / code. google.
com/ p/ hashclash/ )
[31] http:/ / csrc. nist. gov/ groups/ STM/ cavp/ documents/ shs/ shaval. htm
[32] http:/ / www. faqs. org/ rfcs/ rfc3174. html
[33] Locktyukhin, Max; Farrel, Kathy (2010-03-31), "Improving the Performance of the Secure Hash Algorithm (SHA-1)" (http:/ / software.
intel. com/ en-us/ articles/ improving-the-performance-of-the-secure-hash-algorithm-1/ ), Intel Software Knowledge Base (Intel), , retrieved
2010-04-02
• Florent Chabaud, Antoine Joux: Differential Collisions in SHA-0. CRYPTO 1998. pp56–71
• Eli Biham, Rafi Chen, Near-Collisions of SHA-0, Cryptology ePrint Archive, Report 2004/146, 2004 (appeared
on CRYPTO 2004), IACR.org (http://eprint.iacr.org/2004/146/)
• Xiaoyun Wang, Hongbo Yu and Yiqun Lisa Yin, Efficient Collision Search Attacks on SHA-0, CRYPTO 2005,
CMU.edu (http://www.cs.cmu.edu/~dbrumley/srg/spring06/sha-0.pdf)
141
SHA-1
142
• Xiaoyun Wang, Yiqun Lisa Yin and Hongbo Yu, Finding Collisions in the Full SHA-1, Crypto 2005 MIT.edu
(http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf)
• Henri Gilbert, Helena Handschuh: Security Analysis of SHA-256 and Sisters. Selected Areas in Cryptography
2003: pp175–193
• http://www.unixwiz.net/techtips/iguide-crypto-hashes.html
• "Proposed Revision of Federal Information Processing Standard (FIPS) 180, Secure Hash Standard" (http://
frwebgate1.access.gpo.gov/cgi-bin/waisgate.cgi?WAISdocID=5963452267+0+0+0&
WAISaction=retrieve). Federal Register 59 (131): 35317–35318. 1994-07-11. Retrieved 2007-04-26.
External links
Standards: SHA-1, SHA-2
• CSRC Cryptographic Toolkit (http://csrc.nist.gov/CryptoToolkit/tkhash.html) – Official NIST site for the
Secure Hash Standard
• FIPS 180-2: Secure Hash Standard (SHS) (http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2withchangenotice.pdf) (PDF, 236 kB) – Current version of the Secure Hash Standard (SHA-1,
SHA-224, SHA-256, SHA-384, and SHA-512), 1 August 2002, amended 25 February 2004
• RFC 3174 (with sample C implementation)
Cryptanalysis
• Interview with Yiqun Lisa Yin concerning the attack on SHA-1 (http://news.zdnet.com/
2100-1009_22-5598536.html)
• Lenstra's Summary of impact of the February 2005 cryptanalytic results (http://cm.bell-labs.com/who/akl/
hash.pdf)
• Explanation of the successful attacks on SHA-1 (http://www.heise-online.co.uk/security/Hash-cracked--/
features/75686) (3 pages, 2006)
• Cryptography Research – Hash Collision Q&A (http://www.cryptography.com/cnews/hash.html)
• Online SHA1 hash crack using Rainbow tables (http://www.OnlineHashcrack.com)
• Hash Project Web Site: software- and hardware-based cryptanalysis of SHA-1 (http://www.hashproject.eu)
• HashClash - Framework for MD5 & SHA-1 Differential Path Construction and Chosen-Prefix Collisions for
MD5 (http://code.google.com/p/hashclash/)
Implementations
jsSHA (http://jssha.sourceforge.net/)
A cross-browser JavaScript library for client-side calculation of SHA digests, despite the fact that JavaScript
does not natively support the 64-bit operations required for SHA-384 and SHA-512.
LibTomCrypt (http://libtom.org/?page=features&newsitems=5&whatfile=crypt)
A portable ISO C cryptographic toolkit, Public Domain.
Intel (http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1/)
Fast implementation of SHA-1 using Intel Supplemental SSE3 extensions, free for commercial or
non-commercial use.
Stream cipher
Stream cipher
In cryptography, a stream cipher is a symmetric
key cipher where plaintext digits are combined
with a pseudorandom cipher digit stream
(keystream). In a stream cipher each plaintext
digit is encrypted one at a time with the
corresponding digit of the keystream, to give a
digit of the cyphertext stream. An alternative
name is a state cipher, as the encryption of each
digit is dependent on the current state. In
practice, a digit is typically a bit and the
combining operation an exclusive-or (xor).
The operation of the keystream generator in A5/1, a LFSR-based stream
The pseudorandom keystream is typically
cipher used to encrypt mobile phone conversations.
generated serially from a random seed value
using digital shift registers. The seed value
serves as the cryptographic key for decrypting the ciphertext stream.
Stream ciphers represent a different approach to symmetric encryption from block ciphers. Block ciphers operate on
large blocks of digits with a fixed, unvarying transformation. This distinction is not always clear-cut: in some modes
of operation, a block cipher primitive is used in such a way that it acts effectively as a stream cipher. Stream ciphers
typically execute at a higher speed than block ciphers and have lower hardware complexity. However, stream ciphers
can be susceptible to serious security problems if used incorrectly: see stream cipher attacks — in particular, the
same starting state (seed) must never be used twice.
Loose inspiration from the one-time pad
Stream ciphers can be viewed as approximating the action of a proven unbreakable cipher, the one-time pad (OTP),
sometimes known as the Vernam cipher. A one-time pad uses a keystream of completely random digits. The
keystream is combined with the plaintext digits one at a time to form the ciphertext. This system was proved to be
secure by Claude Shannon in 1949. However, the keystream must be (at least) the same length as the plaintext, and
generated completely at random. This makes the system very cumbersome to implement in practice, and as a result
the one-time pad has not been widely used, except for the most critical applications.
A stream cipher makes use of a much smaller and more convenient key — 128 bits, for example. Based on this key,
it generates a pseudorandom keystream which can be combined with the plaintext digits in a similar fashion to the
one-time pad. However, this comes at a cost: because the keystream is now pseudorandom, and not truly random, the
proof of security associated with the one-time pad no longer holds: it is quite possible for a stream cipher to be
completely insecure.
143
Stream cipher
Types of stream ciphers
A stream cipher generates successive elements of the keystream based on an internal state. This state is updated in
essentially two ways: if the state changes independently of the plaintext or ciphertext messages, the cipher is
classified as a synchronous stream cipher. By contrast, self-synchronising stream ciphers update their state based on
previous ciphertext digits.
Synchronous stream ciphers
In a synchronous stream cipher a stream of pseudo-random digits is generated independently of the plaintext and
ciphertext messages, and then combined with the plaintext (to encrypt) or the ciphertext (to decrypt). In the most
common form, binary digits are used (bits), and the keystream is combined with the plaintext using the exclusive or
operation (XOR). This is termed a binary additive stream cipher.
In a synchronous stream cipher, the sender and receiver must be exactly in step for decryption to be successful. If
digits are added or removed from the message during transmission, synchronisation is lost. To restore
synchronisation, various offsets can be tried systematically to obtain the correct decryption. Another approach is to
tag the ciphertext with markers at regular points in the output.
If, however, a digit is corrupted in transmission, rather than added or lost, only a single digit in the plaintext is
affected and the error does not propagate to other parts of the message. This property is useful when the transmission
error rate is high; however, it makes it less likely the error would be detected without further mechanisms. Moreover,
because of this property, synchronous stream ciphers are very susceptible to active attacks — if an attacker can
change a digit in the ciphertext, he might be able to make predictable changes to the corresponding plaintext bit; for
example, flipping a bit in the ciphertext causes the same bit to be flipped in the plaintext.
Self-synchronizing stream ciphers
Another approach uses several of the previous N ciphertext digits to compute the keystream. Such schemes are
known as self-synchronizing stream ciphers, asynchronous stream ciphers or ciphertext autokey (CTAK). The
idea of self-synchronization was patented in 1946, and has the advantage that the receiver will automatically
synchronise with the keystream generator after receiving N ciphertext digits, making it easier to recover if digits are
dropped or added to the message stream. Single-digit errors are limited in their effect, affecting only up to N
plaintext digits.
An example of a self-synchronising stream cipher is a block cipher in cipher feedback (CFB) mode.
144
Stream cipher
145
Linear feedback shift register-based stream ciphers
Binary stream ciphers are often constructed using linear feedback shift registers (LFSRs) because they can be easily
implemented in hardware and can be readily analysed mathematically. The use of LFSRs on their own, however, is
insufficient to provide good security. Various schemes have been proposed to increase the security of LFSRs.
Non-linear combining functions
Because LFSRs are inherently linear, one technique for removing the
linearity is to feed the outputs of several parallel LFSRs into a
non-linear Boolean function to form a combination generator. Various
properties of such a combining function are critical for ensuring the
security of the resultant scheme, for example, in order to avoid
correlation attacks.
Clock-controlled generators
Normally LFSRs are stepped regularly. One approach to introducing
non-linearity is to have the LFSR clocked irregularly, controlled by the
output of a second LFSR. Such generators include the stop-and-go
generator, the alternating step generator and the shrinking generator.
One approach is to use n LFSRs in parallel, their
outputs combined using an n-input binary
Boolean function (F).
An alternating step generator comprises three linear feedback shift
registers, which we will call LFSR0, LFSR1 and LFSR2 for
convenience. The output of one of the registers decides which of the other two is to be used; for instance if LFSR2
outputs a 0, LFSR0 is clocked, and if it outputs a 1, LFSR1 is clocked instead. The output is the exclusive OR of the
last bit produced by LFSR0 and LFSR1. The initial state of the three LFSRs is the key.
The stop-and-go generator (Beth and Piper, 1984) consists of two LFSRs. One LFSR is clocked if the output of a
second is a "1", otherwise it repeats its previous output. This output is then (in some versions) combined with the
output of a third LFSR clocked at a regular rate.
The shrinking generator takes a different approach. Two LFSRs are used, both clocked regularly. If the output of the
first LFSR is "1", the output of the second LFSR becomes the output of the generator. If the first LFSR outputs "0",
however, the output of the second is discarded, and no bit is output by the generator. This mechanism suffers from
timing attacks on the second generator, since the speed of the output is variable in a manner that depends on the
second generator's state. This can be alleviated by buffering the output.
Stream cipher
Filter generator
Another approach to improving the security of an LFSR is to pass the entire state of a single LFSR into a non-linear
filtering function.
Other designs
Instead of a linear driving device, one may use a
nonlinear update function. For example, Klimov
and Shamir proposed triangular functions
(T-Functions) with a single cycle on n bit words.
Security
Main article: Stream cipher attack
For a stream cipher to be secure, its keystream
RC4 is one of the most widely used stream cipher designs.
must have a large period and it must be
impossible to recover the cipher's key or internal state from the keystream. Cryptographers also demand that the
keystream be free of even subtle biases that would let attackers distinguish a stream from random noise, and free of
detectable relationships between keystreams that correspond to related keys or related cryptographic nonces. This
should be true for all keys (there should be no weak keys), and true even if the attacker can know or choose some
plaintext or ciphertext.
As with other attacks in cryptography, stream cipher attacks can be certificational, meaning they aren't necessarily
practical ways to break the cipher but indicate that the cipher might have other weaknesses.
Securely using a secure synchronous stream cipher requires that one never reuse the same keystream twice; that
generally means a different nonce or key must be supplied to each invocation of the cipher. Application designers
must also recognize that most stream ciphers don't provide authenticity, only privacy: encrypted messages may still
have been modified in transit.
Short periods for stream ciphers have been a practical concern. For example, 64-bit block ciphers like DES can be
used to generate a keystream in output feedback (OFB) mode. However, when not using full feedback, the resulting
stream has a period of around 232 blocks on average; for many applications, this period is far too low. For example,
if encryption is being performed at a rate of 8 megabytes per second, a stream of period 232 blocks will repeat after
about a half an hour.
Some applications using the stream cipher RC4 are attackable because of weaknesses in RC4's key setup routine;
new applications should either avoid RC4 or make sure all keys are unique and ideally unrelated (e.g., generated by a
cryptographic hash function) and that the first bytes of the keystream are discarded.
Usage
Stream ciphers are often used for their speed and simplicity of implementation in hardware, and in applications
where plaintext comes in quantities of unknowable length—for example, a secure wireless connection. If a block
cipher (not operating in a stream cipher mode) were to be used in this type of application, the designer would need to
choose either transmission efficiency or implementation complexity, since block ciphers cannot directly work on
blocks shorter than their block size. For example, if a 128-bit block cipher received separate 32-bit bursts of
plaintext, three quarters of the data transmitted would be padding. Block ciphers must be used in ciphertext stealing
or residual block termination mode to avoid padding, while stream ciphers eliminate this issue by naturally operating
on the smallest unit that can be transmitted (usually bytes).
146
Stream cipher
147
Another advantage of stream ciphers in military cryptography is that the cipher stream can be generated in a separate
box that is subject to strict security measures and fed to other devices, e.g. a radio set, which will perform the xor
operation as part of their function. The latter device can then be designed and used in less stringent environments.
RC4 is the most widely used stream cipher in software; others include: A5/1, A5/2, Chameleon, FISH, Helix,
ISAAC, MUGI, Panama, Phelix, Pike, SEAL, SOBER, SOBER-128 and WAKE.
Comparison Of Stream Ciphers
Stream
Cipher
Creation
Date
Speed
(cycles per byte)
1989
Voice (Wphone)
54
114
1989
Voice (Wphone)
54
2006
1 (hardware)
FISH
1993
Grain
HC-256
A5/1
A5/2
(bits)
Attack
Effective Initialization Internal
Key-Length
vector
State
Best Known
Computational
Complexity
64
Active KPA OR
KPA Time-Memory Tradeoff
~2 seconds OR
239.91
114
64?
Active
4.6
milliseconds
80/128
80/128
297/351
Brute force for frame lengths
L ≤ 244. Correlation attack for
[1]
L ≥ 248 .
280 resp. 2128
for L ≤ 244.
Quite Fast (Wsoft)
Variable
?
?
Known-plaintext attack
211
Pre-2004
Fast
80
64
160
Key-Derivation
243
Pre-2004
4 (WP4)
256
256
65536
?
?
1996
2.375 (W64-bit) 4.6875 (W32-bit)
8-8288
usually
40-256
N/A
8288
(2006) First-round
Weak-Internal-State-Derivation
4.67×101240
(2001)
1998–2002
?
128
128
1216
N/A (2002)
~282
1998
2
256
128?
1216?
Hash Collisions (2001)
282
Pre-2004
up to 8 (Wx86)
256 + a
128-bit
Nonce
128?
?
Differential (2006)
237
1994
0.9 x FISH (Wsoft)
Variable
?
?
N/A (2004)
N/A (2004)
Pre-2004
2.6
8-2048?
usually
40-256?
64
8320
Cryptanalytic Theory (2006)
275
2003-Feb
3.7(WP3)-9.7(WARM7)
128
64
512
N/A (2006)
N/A (2006)
8-2048
usually
40-256
8
2064
Shamir Initial-Bytes
Key-Derivation OR KPA
213 OR 233
Achterbahn-128/80
ISAAC
MUGI
PANAMA
Phelix
Pike
Py
Rabbit
1987
RC4
Pre-2004
4.24 (WG4) 11.84 (WP4)
256
a 64-bit
Nonce + a
64-bit stream
position
512
Probabilistic neutral bits
method
2251 for 8
rounds (2007)
2002
4 - 5 (Wsoft)
128 + a
128-bit
Nonce
32?
64-bit
round
function
?
?
1997
Very Fast (W32-bit)
?
32?
?
?
?
Salsa20
Scream
SEAL
[2]
7 WP5
Stream cipher
SNOW
148
Pre-2003
Very Good (W32-bit)
128 OR 256
32
?
?
?
2003
?
up to 128
?
?
Message Forge
2−6
SOSEMANUK
Pre-2004
Very Good (W32-bit)
128
128
?
?
?
Trivium
Pre-2004
4 (Wx86) - 8 (WLG)
80
80
288
Brute force attack (2006)
2135
Turing
2000–2003
5.5 (Wx86)
?
160
?
?
?
2005
42 (WASIC) 64 (WFPGA)
Variable
usually
80-256
Variable
usually
80-256
256 800
N/A (2006)
N/A (2006)
1993
Fast
?
?
8192
CPA & CCA
Vulnerable
Creation
Date
Speed
(cycles per byte)
SOBER-128
VEST
WAKE
Stream
Cipher
(bits)
Effective Initialization Internal
Key-Length
vector
State
Attack
Best Known
Computational
Complexity
Trivia
• United States National Security Agency documents sometimes use the term combiner-type algorithms, referring
to algorithms that use some function to combine a pseudorandom number generator (PRNG) with a plaintext
stream.
Notes
[1] http:/ / www. matpack. de/ achterbahn/ Goettfert_Gammel_On_the_frame_length_of_Achterbahn-128-80_ITW2007. pdf
[2] P. Prasithsangaree and P. Krishnamurthy (2003). Analysis of Energy Consumption of RC4 and AES Algorithms in Wireless LANs (http:/ /
www. sis. pitt. edu/ ~is3966/ group5_paper2. pdf). .
References
• Matt J. B. Robshaw, Stream Ciphers Technical Report TR-701, version 2.0, RSA Laboratories, 1995 (PDF) (ftp:/
/ftp.rsasecurity.com/pub/pdfs/tr701.pdf).
• Thomas Beth and Fred Piper, The Stop-and-Go Generator. EUROCRYPT 1984, pp88–92.
• Christof Paar, Jan Pelzl, "Stream Ciphers" (http://wiki.crypto.rub.de/Buch/movies.php), Chapter 2 of
"Understanding Cryptography, A Textbook for Students and Practitioners". (companion web site contains online
cryptography course that covers stream ciphers and LFSR), Springer, 2009.
External links
• RSA technical report on stream cipher operation. (ftp://ftp.rsasecurity.com/pub/pdfs/tr701.pdf)
• Analysis of Lightweight Stream Ciphers (thesis by S. Fischer). (http://biblion.epfl.ch/EPFL/theses/2008/
4040/EPFL_TH4040.pdf)
• SVG Animation of simple stream cipher (http://l-system.net.pl/crypto/simple_stream_cipher.svg)
Symmetric-key algorithms are a class of algorithms for cryptography that use trivially related, often identical,
cryptographic keys for both encryption of plaintext and decryption of ciphertext. The encryption key is trivially
related to the decryption key, in that they may be identical or there is a simple transformation to go between the two
keys. The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a
private information link. Other terms for symmetric-key encryption are secret-key, single-key, shared-key,
one-key, and private-key encryption. Use of the last and first terms can create ambiguity with similar terminology
used in public-key cryptography. Symmetric-key cryptography is to be contrasted with asymmetric-key
cryptography.
Types of symmetric-key algorithms
Symmetric-key encryption can use either stream ciphers or block ciphers.
• Stream ciphers encrypt the bits of a message one at a time.
• Block ciphers take a number of bits and encrypt them as a single unit. Blocks of 64 bits have been commonly
used. The Advanced Encryption Standard (AES) algorithm approved by NIST in December 2001 uses 128-bit
blocks.
Implementations
Examples of popular and well-respected symmetric algorithms include Twofish, Serpent, AES (Rijndael), Blowfish,
CAST5, RC4, 3DES, and IDEA.
Cryptographic primitives based on symmetric ciphers
Symmetric ciphers are often used to achieve other cryptographic primitives than just encryption.
Encrypting a message does not guarantee that this message is not changed while encrypted. Hence often a message
authentication code is added to a ciphertext to ensure that changes to the ciphertext will be noted by the receiver.
Message authentication codes can be constructed from symmetric ciphers (e.g. CBC-MAC).
However, symmetric ciphers also can be used for non-repudiation purposes by ISO 13888-2 standard.
Another application is to build hash functions from block ciphers. See one-way compression function for
descriptions of several such methods.
Construction of symmetric ciphers
Many modern block ciphers are based on a construction proposed by Horst Feistel. Feistel's construction makes it
possible to build invertible functions from other functions that are themselves not invertible.
Security of symmetric ciphers
Symmetric ciphers have historically been susceptible to known-plaintext attacks, chosen plaintext attacks,
differential cryptanalysis and linear cryptanalysis. Careful construction of the functions for each round can greatly
reduce the chances of a successful attack.
149
Key generation
When used with asymmetric ciphers for key transfer, pseudorandom key generators are nearly always used to
generate the symmetric cipher session keys. However, lack of randomness in those generators or in their
initialization vectors is disastrous and has led to cryptanalytic breaks in the past. Therefore, it is essential that an
implementation uses a source of high entropy for its initialization.
Notes
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols
that provide communication security over the Internet.[1] TLS and SSL encrypt the segments of network connections
above the Transport Layer, using asymmetric cryptography for key exchange, symmetric encryption for privacy, and
message authentication codes for message integrity.
Several versions of the protocols are in widespread use in applications such as web browsing, electronic mail,
Internet faxing, instant messaging and voice-over-IP (VoIP).
TLS is an IETF standards track protocol, last updated in RFC 5246, and is based on the earlier SSL specifications
developed by Netscape Communications[2].
Description
The TLS protocol allows client-server applications to communicate across a network in a way designed to prevent
eavesdropping and tampering.
Since most protocols can be used either with or without TLS (or SSL) it is necessary to indicate to the server whether
the client is making a TLS connection or not. There are two main ways of achieving this, one option is to use a
different port number for TLS connections (for example port 443 for HTTPS). The other is to use the regular port
number and have the client request that the server switch the connection to TLS using a protocol specific mechanism
(for example STARTTLS for mail and news protocols).
Once the client and server have decided to use TLS they negotiate a stateful connection by using a handshaking
procedure.[3] During this handshake, the client and server agree on various parameters used to establish the
connection's security.
• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and
presents a list of supported cipher suites (ciphers and hash functions).
• From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of
the decision.
• The server sends back its identification in the form of a digital certificate. The certificate usually contains the
server name, the trusted certificate authority (CA) and the server's public encryption key.
• The client may contact the server that issued the certificate (the trusted CA as above) and confirm the validity of
the certificate before proceeding.
• In order to generate the session keys used for the secure connection, the client encrypts a random number with the
server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private
key.
• From the random number, both parties generate key material for encryption and decryption.
This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key
material until the connection closes.
150
If any one of the above steps fails, the TLS handshake fails and the connection is not created.
Secure Network Programming API
Early research efforts toward transport layer security included the Secure Network Programming (SNP)
application programming interface (API), which in 1993 explored the approach of having a secure transport layer
API closely resembling Berkeley sockets, to facilitate retrofitting preexisting network applications with security
measures.[4]
SSL 1.0, 2.0 and 3.0
The SSL protocol was originally developed by Netscape.[5] Version 1.0 was never publicly released; version 2.0 was
released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL
version 3.0".[6] SSL version 3.0, released in 1996, was a complete redesign of the protocol produced by Paul Kocher
working with Netscape engineers Phil Karlton and Alan Freier. Newer versions of SSL/TLS are based on SSL 3.0.
The 1996 draft of SSL 3.0 was published by IETF as a historic document in RFC 6101.
TLS 1.0
TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade to SSL Version 3.0. As stated in the RFC, "the
differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and
SSL 3.0 do not interoperate." TLS 1.0 does include a means by which a TLS implementation can downgrade the
connection to SSL 3.0, thus weakening security.
On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a "proof of concept" called BEAST
(using a Java Applet to violate "same origin policy" constraints) for a long-known Cipher block chaining (CBC)
vulnerability in TLS 1.0.[7][8] Practical exploits had not been previously demonstrated for this vulnerability, which
was originally discovered by Phillip Rogaway[9] in 2002.
Mozilla updated the development versions of their NSS libraries to mitigate BEAST-like attacks. NSS is used by
Mozilla Firefox and Google Chrome to implement SSL. Some web servers that have a broken implementation of the
SSL specification may stop working as a result.[10]
Microsoft released Security Bulletin MS12-006 on January 10, 2012, which fixed the BEAST vulnerability by
changing the way that the Windows Secure Channel (SChannel) component transmits encrypted network packets.[11]
As a work-around, the BEAST attack can also be prevented by removing all CBC ciphers from one's list of allowed
ciphers—leaving only the RC4 cipher, which is still widely supported on most websites.[12][13] Users of Windows 7
and Windows Server 2008 R2 can enable use of TLS 1.1 and 1.2, but this work-around will fail if it is not supported
by the other end of the connection and will result in a fall-back to TLS 1.0.
151
TLS 1.1
TLS 1.1 was defined in RFC 4346 in April 2006.[14] It is an update from TLS version 1.0. Significant differences in
this version include:
• Added protection against Cipher block chaining (CBC) attacks.
• The implicit Initialization Vector (IV) was replaced with an explicit IV.
• Change in handling of padding errors.
• Support for IANA registration of parameters.
TLS 1.2
TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. Major differences
include:
• The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option
to use cipher-suite specified PRFs.
• The MD5-SHA-1 combination in the Finished message hash was replaced with SHA-256, with an option to use
cipher-suite specific hash algorithms. However the size of the hash in the finished message is still truncated to
96-bits.
• The MD5-SHA-1 combination in the digitally-signed element was replaced with a single hash negotiated during
handshake, defaults to SHA-1.
• Enhancement in the client's and server's ability to specify which hash and signature algorithms they will accept.
• Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and
CCM mode of Advanced Encryption Standard encryption.
• TLS Extensions definition and Advanced Encryption Standard CipherSuites were added.
TLS 1.2 was further refined in RFC 6176 in March 2011 redacting its backward compatibility with SSL such that
TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0.
Applications
In applications design, TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating the
application-specific protocols such as HTTP, FTP, SMTP, NNTP and XMPP. Historically it has been used primarily
with reliable transport protocols such as the Transmission Control Protocol (TCP). However, it has also been
implemented with datagram-oriented transport protocols, such as the User Datagram Protocol (UDP) and the
Datagram Congestion Control Protocol (DCCP), usage which has been standardized independently using the term
Datagram Transport Layer Security (DTLS).
A prominent use of TLS is for securing World Wide Web traffic carried by HTTP to form HTTPS. Notable
applications are electronic commerce and asset management. Increasingly, the Simple Mail Transfer Protocol
(SMTP) is also protected by TLS. These applications use public key certificates to verify the identity of endpoints.
TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN. Many vendors
now marry TLS's encryption and authentication capabilities with authorization. There has also been substantial
development since the late 1990s in creating client technology outside of the browser to enable support for
client/server applications. When compared against traditional IPsec VPN technologies, TLS has some inherent
advantages in firewall and NAT traversal that make it easier to administer for large remote-access populations.
TLS is also a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS can be used to
provide authentication and encryption of the SIP signaling associated with VoIP and other SIP-based applications.
152
Security
TLS has a variety of security measures:
• Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.
• Numbering subsequent Application records with a sequence number and using this sequence number in the
message authentication codes (MACs).
• Using a message digest enhanced with a key (so only a key-holder can check the MAC). The HMAC construction
used by most TLS cipher suites is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC).
• The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by
both parties.
• The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm
(MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of these
algorithms is found to be vulnerable. TLS only.
• SSL 3.0 improved upon SSL 2.0 by adding SHA-1 based ciphers and support for certificate authentication.
From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. The SSL 3.0 cipher suites
have a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hash
function, which is not resistant to collisions and is, therefore, not considered secure. Under TLS 1.0, the master key
that is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak. It is
for this reason that SSL 3.0 implementations cannot be validated under FIPS 140-2.[15]
A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injection
attacks against SSL 3.0 and all current versions of TLS. For example, it allows an attacker who can hijack an https
connection to splice their own requests into the beginning of the conversation the client has with the web server. The
attacker can't actually decrypt the client-server communication, so it is different from a typical man-in-the-middle
attack. A short-term fix is for web servers to stop allowing renegotiation, which typically will not require other
changes unless client certificate authentication is used. To fix the vulnerability, a renegotiation indication extension
was proposed for TLS. It will require the client and server to include and verify information about previous
handshakes in any renegotiation handshakes.[16] When a user doesn't pay attention to their browser's indication that
the session is secure (typically a padlock icon), the vulnerability can be turned into a true man-in-the-middle
attack.[17] This extension has become a proposed standard and has been assigned the number RFC 5746. The RFC
has been implemented in recent OpenSSL[18] and other libraries [19] .[20]
There are some attacks against the implementation rather than the protocol itself:[21]
• In the earlier implementations, some CAs[22] did not explicitly set basicConstraints CA=FALSE for leaf nodes.
As a result, these leaf nodes could sign rogue certificates. In addition, some early software (including IE6 and
Konqueror) did not check this field altogether. This can be exploited for man-in-the-middle attack on all potential
SSL connections.
• Some implementations (including older versions of Microsoft Cryptographic API, Network Security Services and
GnuTLS) stop reading any characters that follow the null character in the name field of the certificate, which can
be exploited to fool the client into reading the certificate as if it were one that came from the authentic site, e.g.
paypal.com\0.badguy.com would be mistaken as the site of paypal.com rather than badguy.com.
• Browsers implemented SSL/TLS protocol version fallback mechanisms for compatibility reasons. The protection
offered by the SSL/TLS protocols against a downgrade to a previous version by an active MITM attack can be
rendered useless by such mechanisms.[23]
SSL 2.0 is flawed in a variety of ways:
• Identical cryptographic keys are used for message authentication and encryption.
• SSL 2.0 has a weak MAC construction that uses the MD5 hash function with a secret prefix, making it vulnerable
to length extension attacks.
153
• SSL 2.0 does not have any protection for the handshake, meaning a man-in-the-middle downgrade attack can go
undetected.
• SSL 2.0 uses the TCP connection close to indicate the end of data. This means that truncation attacks are possible:
the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL
3.0 fixes this problem by having an explicit closure alert).
• SSL 2.0 assumes a single service and a fixed domain certificate, which clashes with the standard feature of virtual
hosting in Web servers. This means that most websites are practically impaired from using SSL.
SSL 2.0 is disabled by default in Internet Explorer 7,[24] Mozilla Firefox 2, Mozilla Firefox 3, Mozilla Firefox 4[25]
Opera and Safari. After it sends a TLS ClientHello, if Mozilla Firefox finds that the server is unable to complete the
handshake, it will attempt to fall back to using SSL 3.0 with an SSL 3.0 ClientHello in SSL 2.0 format to maximize
the likelihood of successfully handshaking with older servers.[26] Support for SSL 2.0 (and weak 40-bit and 56-bit
ciphers) has been removed completely from Opera as of version 9.5.[27]
Modifications to the original protocols, like False Start (adopted and enabled by Google Chrome[28] ) or Snap Start,
have been reported to introduce limited TLS protocol version rollback attacks[29] or to allow modifications to the
cipher suite list sent by the client to the server (an attacker may be able influence the cipher suite selection in an
attempt to downgrade the cipher suite strength, to use either a weaker symmetric encryption algorithm or a weaker
key exchange[30] ).
TLS handshake in detail
The TLS protocol exchanges records, which encapsulate the data to be exchanged. Each record can be compressed,
padded, appended with a message authentication code (MAC), or encrypted, all depending on the state of the
connection. Each record has a content type field that specifies the record, a length field and a TLS version field.
When the connection starts, the record encapsulates another protocol — the handshake messaging protocol — which
has content type 22.
Simple TLS handshake
A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated
by its certificate:
1. Negotiation phase:
• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random
number, a list of suggested CipherSuites and suggested compression methods. If the client is attempting to
perform a resumed handshake, it may send a session ID.
• The server responds with a ServerHello message, containing the chosen protocol version, a random number,
CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed
handshakes the server may send a session ID. The chosen protocol version should be the highest that both the
client and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1
should be selected; SSL 3.0 should not be selected.
• The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the
server).[31]
• The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
• The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key,
or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public
key of the server certificate.
• The client and server then use the random numbers and PreMasterSecret to compute a common secret, called
the "master secret". All other key data for this connection is derived from this master secret (and the client- and
server-generated random values), which is passed through a carefully designed pseudorandom function.
154
2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now
on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The
ChangeCipherSpec is itself a record-level protocol with content type of 20.
• Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over
the previous handshake messages.
• The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the
decryption or verification fails, the handshake is considered to have failed and the connection should be torn
down.
3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be
authenticated (and encrypted, if encryption was negotiated)."
• The server sends its authenticated and encrypted Finished message.
• The client performs the same decryption and verification.
4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content
type of 23. Application messages exchanged between client and server will also be authenticated and optionally
encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not
authenticate.
Client-authenticated TLS handshake
The following full example shows a client being authenticated (in addition to the server like above) via TLS using
certificates exchanged between both peers.
1. Negotiation Phase:
number, a list of suggested cipher suites and compression methods.
cipher suite and compression method from the choices offered by the client. The server may also send a
session id as part of the message to perform a resumed handshake.
• The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the
server).[31]
• The server requests a certificate from the client, so that the connection can be mutually authenticated, using a
CertificateRequest message.
• The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
• The client responds with a Certificate message, which contains the client's certificate.
• The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or
nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key
of the server certificate.
• The client sends a CertificateVerify message, which is a signature over the previous handshake messages
using the client's certificate's private key. This signature can be verified by using the client's certificate's public
key. This lets the server know that the client has access to the private key of the certificate and thus owns the
certificate.
• The client and server then use the random numbers and PreMasterSecret to compute a common secret, called
the "master secret". All other key data for this connection is derived from this master secret (and the client- and
server-generated random values), which is passed through a carefully designed pseudorandom function.
on will be authenticated (and encrypted if encryption was negotiated)." The ChangeCipherSpec is itself a
record-level protocol and has type 20 and not 22.
155
• Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous
handshake messages.
down.
authenticated (and encrypted if encryption was negotiated)."
• The server sends its own encrypted Finished message.
type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their
Finished message. The application will never again return TLS encryption information without a type 32 apology.
Resumed TLS handshake
Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure
shortcut in the handshake mechanism to avoid these operations. In an ordinary full handshake, the server sends a
session id as part of the ServerHello message. The client associates this session id with the server's IP address and
TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In
the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master
secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an
eavesdropper from using a session id). The random data in the ClientHello and ServerHello messages virtually
guarantee that the generated connection keys will be different than in the previous connection. In the RFCs, this type
of handshake is called an abbreviated handshake. It is also described in the literature as a restart handshake.
1. Negotiation phase:
number, a list of suggested cipher suites and compression methods. Included in the message is the session id
from the previous TLS connection.
cipher suite and compression method from the choices offered by the client. If the server recognizes the
session id sent by the client, it responds with the same session id. The client uses this to recognize that a
resumed handshake is being performed. If the server does not recognize the session id sent by the client, it
sends a different value for its session id. This tells the client that a resumed handshake will not be performed.
At this point, both the client and server have the "master secret" and random data to generate the key data to be
used for this connection.
on will be encrypted." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
• Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous
handshake messages.
down.
encrypted."
• The server sends its own encrypted Finished message.
156
157
type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their
Finished message.
Apart from the performance benefit, resumed sessions can also be used for single sign-on as it is guaranteed that
both the original session as well as any resumed session originate from the same client. This is of particular
importance for the FTP over TLS/SSL protocol which would otherwise suffer from a man in the middle attack in
which an attacker could intercept the contents of the secondary data connections.[32]
TLS record protocol
This is the general format of all TLS records.
+
Byte +0
Byte
0
Content type
Bytes
1..4
Byte +1
Byte +2
Version
(Major)
Byte +3
Length
(Minor) (bits 15..8) (bits 7..0)
Bytes
5..(m-1)
Protocol message(s)
Bytes
m..(p-1)
MAC (optional)
Bytes
p..(q-1)
Padding (block ciphers only)
Content type
This field identifies the Record Layer Protocol Type contained in this Record.
Content types
Hex Dec
Type
0x14 20
ChangeCipherSpec
0x15 21
Alert
0x16 22
Handshake
0x17 23
Application
Version
This field identifies the major and minor version of TLS for the contained message. For a ClientHello
message, this need not be the highest version supported by the client.
158
Versions
Major Minor Version Type
Version Version
3
0
SSL 3.0
3
1
TLS 1.0
3
2
TLS 1.1
3
3
TLS 1.2
Length
The length of Protocol message(s), not to exceed 214 bytes (16 KiB).
Protocol message(s)
One or more messages identified by the Protocol field. Note that this field may be encrypted depending on the
state of the connection.
MAC and Padding
A message authentication code computed over the Protocol message, with additional key material included.
Note that this field may be encrypted, or not included entirely, depending on the state of the connection.
No MAC or Padding can be present at end of TLS records before all cipher algorithms and parameters have
been negotiated and handshaked and then confirmed by sending a CipherStateChange record (see below) for
signalling that these parameters will take effect in all further records sent by the same peer.
Handshake protocol
Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning
occurs and needs to be signalled by an Alert protocol record (see below), or the encryption mode of the session is
modified by another record (see ChangeCipherSpec protocol below).
+
Byte +0
Byte
0
22
Bytes
1..4
Bytes
5..8
Bytes
9..(n-1)
Byte +1
Version
(Major)
(bits 15..8) (bits 7..0)
Handshake message data length
(bits 23..16) (bits 15..8) (bits 7..0)
Handshake message data
Bytes Message type
n..(n+3)
Bytes
(n+4)..
Byte +3
Length
(Minor)
Message type
Byte +2
(bits 23..16) (bits 15..8) (bits 7..0)
Handshake message data
Message type
This field identifies the Handshake message type.
159
Message Types
Code
Description
0
HelloRequest
1
ClientHello
2
ServerHello
11
Certificate
12
ServerKeyExchange
13
CertificateRequest
14
ServerHelloDone
15
CertificateVerify
16
ClientKeyExchange
20
Finished
This is a 3-byte field indicating the length of the handshake data, not including the header.
Note that multiple Handshake messages may be combined within one record.
Alert protocol
This record should normally not be sent during normal handshaking or application exchanges. However, this
message can be sent at any time during the handshake and up to the closure of the session. If this is used to signal a
fatal error, the session will be closed immediately after sending this record, so this record is used to give a reason for
this closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that the
session is not reliable enough for its needs (before doing so, the remote may also send its own signal).
+
Byte +0
Byte
0
21
Bytes
1..4
Bytes
5..6
Byte +1
Byte +2 Byte +3
Version
(Major)
(Minor)
Level
Description
Length
0
Bytes
7..(p-1)
MAC (optional)
Bytes
p..(q-1)
2
Level
This field identifies the level of alert. If the level is fatal, the sender should close the session immediately.
Otherwise, the recipient may decide to terminate the session itself, by sending its own fatal alert and closing
the session itself immediately after sending it. The use of Alert records is optional, however if it is missing
before the session closure, the session may be resumed automatically (with its handshakes).
Normal closure of a session after termination of the transported application should preferably be alerted with
at least the Close notify Alert type (with a simple warning level) to prevent such automatic resume of a new
session. Signalling explicitly the normal closure of a secure session before effectively closing its transport
160
layer is useful to prevent or detect attacks (like attempts to truncate the securely transported data, if it
intrinsically does not have a predetermined length or duration that the recipient of the secured data may
expect).
Alert level types
Code Level type
Connection state
1
warning
connection or security may be unstable.
2
fatal
connection or security may be compromised, or an unrecoverable error has occurred.
Description
This field identifies which type of alert is being sent.
Alert description types
Code
Description
Level types
Note
0
Close notify
warning/fatal
10
Unexpected message
fatal
20
Bad record MAC
fatal
Possibly a bad SSL implementation, or payload has been tampered with e.g. FTP
firewall rule on FTPS server.
21
Decryption failed
fatal
TLS only, reserved
22
Record overflow
fatal
TLS only
30
Decompression failure
fatal
40
Handshake failure
fatal
41
No certificate
warning/fatal SSL 3.0 only, reserved
42
Bad certificate
warning/fatal
43
Unsupported certificate
warning/fatal E.g. certificate has only Server authentication usage enabled and is presented as a
client certificate
44
Certificate revoked
warning/fatal
45
Certificate expired
warning/fatal Check server certificate expire also check no certificate in the chain presented has
expired
46
Certificate unknown
warning/fatal
47
Illegal parameter
fatal
48
Unknown CA (Certificate
authority)
fatal
TLS only
49
Access denied
fatal
TLS only - E.g. no client certificate has been presented (TLS: Blank certificate
message or SSLv3: No Certificate alert), but server is configured to require one.
50
Decode error
fatal
TLS only
51
Decrypt error
warning/fatal TLS only
60
Export restriction
fatal
TLS only, reserved
70
Protocol version
fatal
TLS only
71
Insufficient security
fatal
TLS only
80
Internal error
fatal
TLS only
90
User cancelled
fatal
TLS only
161
100
No renegotiation
warning
TLS only
110
Unsupported extension
warning
TLS only
111
Certificate unobtainable
warning
TLS only
112
Unrecognized name
warning
TLS only; client's Server Name Indicator specified a hostname not supported by the
server
113
Bad certificate status response
fatal
TLS only
114
Bad certificate hash value
fatal
TLS only
115
Unknown PSK identity (used in
TLS-PSK and TLS-SRP)
fatal
TLS only
ChangeCipherSpec protocol
+
Byte +0
Byte
0
20
Bytes
1..4
Byte +1 Byte +2 Byte +3
Version
(Major)
Length
(Minor)
0
1
Byte CCS protocol type
5
CCS protocol type
Currently only 1.
Application protocol
+
Byte
0
Bytes
1..4
Byte +0 Byte +1
Byte +2
Byte +3
23
Version
Length
(Major) (Minor) (bits 15..8) (bits 7..0)
Bytes
5..(m-1)
Application data
Bytes
m..(p-1)
MAC (optional)
Bytes
p..(q-1)
Length
Length of Application data (excluding the protocol header and including the MAC and padding trailers)
MAC
20 bytes for the SHA-1-based HMAC, 16 bytes for the MD5-based HMAC.
Padding
Variable length ; last byte contains the padding length.
Support for name-based virtual servers
From the application protocol point of view, TLS belongs to a lower layer, although the TCP/IP model is too coarse
to show it. This means that the TLS handshake is usually (except in the STARTTLS case) performed before the
application protocol can start. The name-based virtual server feature being provided by the application layer, all
co-hosted virtual servers share the same certificate because the server has to select and send a certificate immediately
after the ClientHello message. This is a big problem in hosting environments because it means either sharing the
same certificate among all customers or using a different IP address for each of them.
There are two known workarounds provided by X.509:
• If all virtual servers belong to the same domain, a wildcard certificate can be used. Besides the loose host name
selection that might be a problem or not, there is no common agreement about how to match wildcard certificates.
Different rules are applied depending on the application protocol or software used.[33]
• Add every virtual host name in the subjectAltName extension. The major problem being that the certificate needs
to be reissued whenever a new virtual server is added.
In order to provide the server name, RFC 4366 Transport Layer Security (TLS) Extensions allow clients to include a
Server Name Indication extension (SNI) in the extended ClientHello message. This extension hints the server
immediately which name the client wishes to connect to, so the server can select the appropriate certificate to send to
the client.
Implementations
SSL and TLS have been widely implemented in several free and open source software projects. Programmers may
use the PolarSSL, CyaSSL, OpenSSL, NSS, or GnuTLS libraries for SSL/TLS functionality. Microsoft Windows
includes an implementation of SSL and TLS as part of its Secure Channel package. Delphi programmers may use a
library called Indy. Comparison of TLS Implementations provides a brief comparison of features of different
implementations.
Browser implementations
All the most recent web browsers support TLS:
• Apple's Safari supports TLS, but it’s not officially specified which version.[34] On operating systems (Safari uses
the TLS implementation of the underlying OS) like Mac OS X 10.5.8, Mac OS X 10.6.6, Windows XP, Windows
Vista or Windows 7, Safari 5 has been reported to support TLS 1.0.[35]
• Mozilla Firefox, versions 2 and above, support TLS 1.0.[36] As of January 2012 Firefox does not support TLS 1.1
or 1.2.[37]
• Microsoft Internet Explorer always uses the TLS implementation of the underlying Microsoft Windows Operating
System, a service called SChannel Security Service Provider. Internet Explorer 8 in Windows 7 and Windows
Server 2008 R2 supports TLS 1.2. Windows 7 and Windows Server 2008 R2 use the same code (Microsoft
Windows Version 6.1 (build 7600)) similar to how Windows Vista SP1 uses the same code as Windows 2008
Server.[38]
• As of Presto 2.2, featured in Opera 10, Opera supports TLS 1.2.[39]
• Google's Chrome browser supports TLS 1.0, but not TLS 1.1 or 1.2.[40]
162
Standards
The current approved version of TLS is version 1.2, which is specified in:
• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.
The current standard replaces these former versions, which are now considered obsolete:
• RFC 2246: “The TLS Protocol Version 1.0”.
• RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.
as well as the never standardized SSL 3.0:
• RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”.
Other RFCs subsequently extended TLS.
Extensions to TLS 1.0 include:
• RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Specifies an extension to the IMAP, POP3 and ACAP
services that allow the server and client to use transport-layer security to provide private, authenticated
communication over the Internet.
• RFC 2712: “Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)”. The 40-bit cipher suites
defined in this memo appear only for the purpose of documenting the fact that those cipher suite codes have
already been assigned.
• RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade mechanism in HTTP/1.1 to
initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured
HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443).
• RFC 2818: “HTTP Over TLS”, distinguishes secured traffic from insecure traffic by the use of a different 'server
port'.
• RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Specifies an extension to
the SMTP service that allows an SMTP server and client to use transport-layer security to provide private,
authenticated communication over the Internet.
• RFC 3268: “AES Ciphersuites for TLS”. Adds Advanced Encryption Standard (AES) cipher suites to the
previously existing symmetric ciphers.
• RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for negotiating protocol extensions
during session initialisation and defines some extensions. Made obsolete by RFC 4366.
• RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the framework for compression
methods and the DEFLATE compression method.
• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.
• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4217: “Securing FTP with TLS”.
• RFC 4279: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds three sets of new cipher
suites for the TLS protocol to support authentication based on pre-shared keys.
• RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works over datagram protocols
(such as UDP).
• RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of specific extensions and a generic
extension mechanism.
• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.
• RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.
• RFC 4680: “TLS Handshake Message for Supplemental Data”.
• RFC 4681: “TLS User Mapping Extension”.
163
• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.
• RFC 5054: “Using the Secure Remote Password (SRP) Protocol for TLS Authentication”. Defines the TLS-SRP
ciphersuites.
• RFC 5081: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication”, obsoleted by RFC 6091.
•
•
•
•
•
RFC 5746: “Transport Layer Security (TLS) Renegotiation Indication Extension”.
RFC 5878: “Transport Layer Security (TLS) Authorization Extensions”.
RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“.
RFC 6176: “Prohibiting Secure Sockets Layer (SSL) Version 2.0”.
RFC 6209: “Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)”.
References and footnotes
[1] T. Dierks, E. Rescorla (August 2008). "The Transport Layer Security (TLS) Protocol, Version 1.2" (http:/ / tools. ietf. org/ html/ rfc5246). .
[2] A. Freier, P. Karlton, P. Kocher (August 2011). "The Secure Sockets Layer (SSL) Protocol Version 3.0" (http:/ / tools. ietf. org/ html/
rfc6101). .
[3] " SSL/TLS in Detail (http:/ / technet. microsoft. com/ en-us/ library/ cc785811. aspx)". Microsoft TechNet. Updated July 31, 2003.
[4] Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming
Proceedings USENIX Summer Technical Conference, June 1994
[5] "THE SSL PROTOCOL" (http:/ / web. archive. org/ web/ 19970614020952/ http:/ / home. netscape. com/ newsref/ std/ SSL. html). Netscape
Corporation. 2007. Archived from the original (http:/ / home. netscape. com/ newsref/ std/ SSL. html) on 14 June 1997. .
[6] Rescorla 2001
[7] Dan Goodin (2011-09-19). "Hackers break SSL encryption used by millions of sites" (http:/ / www. theregister. co. uk/ 2011/ 09/ 19/
beast_exploits_paypal_ssl/ ). .
[8] "Y Combinator comments on the issue" (http:/ / news. ycombinator. com/ item?id=3015498). 2011-09-20. .
[9] "Security of CBC Ciphersuites in SSL/TLS" (http:/ / www. openssl. org/ ~bodo/ tls-cbc. txt). 2004-05-20. .
[10] Brian Smith (2011-09-30). "(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets
-76)" (https:/ / bugzilla. mozilla. org/ show_bug. cgi?id=665814). .
[11] "Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)" (http:/ / technet. microsoft. com/ en-us/ security/ bulletin/
ms12-006). 2012-01-10. .
[12] "Safest ciphers to use with the BEAST? (TLS 1.0 exploit)" (http:/ / serverfault. com/ questions/ 315042/ ). 2011-09-24. .
[13] "First solutions for SSL/TLS vulnerability" (http:/ / www. h-online. com/ security/ news/ item/
First-solutions-for-SSL-TLS-vulnerability-1349813. html). 2011-09-26. .
[14] Dierks, T. and E. Rescorla (April 2006). "The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346" (http:/ / tools. ietf. org/
html/ rfc5246#ref-TLS1. 1). .
[15] National Institute of Standards and Technology (December 2010). "Implementation Guidance for FIPS PUB 140-2 and the Cryptographic
Module Validation Program" (http:/ / csrc. nist. gov/ groups/ STM/ cmvp/ documents/ fips140-2/ FIPS1402IG. pdf). .
[16] Eric Rescorla (2009-11-05). "Understanding the TLS Renegotiation Attack" (http:/ / www. educatedguesswork. org/ 2009/ 11/
understanding_the_tls_renegoti. html). Educated Guesswork. . Retrieved 2009-11-27.
[17] McMillan, Robert (2009-11-20). "Security Pro Says New SSL Attack Can Hit Many Sites" (http:/ / www. pcworld. com/ article/ 182720/
security_pro_says_new_ssl_attack_can_hit_many_sites. html). PC World. . Retrieved 2009-11-27.
[18] "SSL_CTX_set_options SECURE_RENEGOTIATION" (http:/ / www. openssl. org/ docs/ ssl/ SSL_CTX_set_options.
html#SECURE_RENEGOTIATION). OpenSSL Docs. 2010-02-25. . Retrieved 2010-11-18.
[19] "GnuTLS 2.10.0 released" (http:/ / article. gmane. org/ gmane. network. gnutls. general/ 2046). GnuTLS release notes. 2010-06-25. .
[20] "NSS 3.12.6 release notes" (https:/ / developer. mozilla. org/ NSS_3. 12. 6_release_notes). NSS release notes. 2010-03-03. . Retrieved
2011-07-24.
[21] Various (2002-08-10). "IE SSL Vulnerability" (http:/ / www. mail-archive. com/ bugtraq@securityfocus. com/ msg08807. html). Educated
Guesswork. . Retrieved 2010-11-17.
[22] "Defeating SSL" (https:/ / www. blackhat. com/ presentations/ bh-dc-09/ Marlinspike/ BlackHat-DC-09-Marlinspike-Defeating-SSL. pdf). .
[23] Adrian, Dimcev. "SSL/TLS version rollbacks and browsers" (http:/ / www. carbonwind. net/ blog/ post/
Random-SSLTLS-101–SSLTLS-version-rollbacks-and-browsers. aspx). Random SSL/TLS 101. . Retrieved 9 March 2011.
[24] Lawrence, Eric (2005-10-22). "IEBlog : Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2" (http:/ / blogs. msdn. com/ ie/
archive/ 2005/ 10/ 22/ 483795. aspx). MSDN Blogs. . Retrieved 2007-11-25.
[25] "Bugzilla@Mozilla — Bug 236933 - Disable SSL2 and other weak ciphers" (https:/ / bugzilla. mozilla. org/ show_bug. cgi?id=236933).
Mozilla Corporation. . Retrieved 2007-11-25.
164
[26] "Firefox still sends SSLv2 handshake even though the protocol is disabled" (https:/ / bugzilla. mozilla. org/ show_bug. cgi?id=454759).
2008-09-11. .
[27] Pettersen, Yngve (2007-04-30). "10 years of SSL in Opera — Implementer's notes" (http:/ / my. opera. com/ yngve/ blog/ 2007/ 04/ 30/
10-years-of-ssl-in-opera). Opera Software. . Retrieved 2007-11-25.
[28] Wolfgang, Gruener. "False Start: Google Proposes Faster Web, Chrome Supports It Already" (http:/ / www. conceivablytech. com/ 3299/
products/ false-start-google-proposes-faster-web-chrome-supports-it-already). . Retrieved 9 March 2011.
[29] Brian, Smith. "Limited rollback attacks in False Start and Snap Start" (http:/ / www. ietf. org/ mail-archive/ web/ tls/ current/ msg06933.
html). . Retrieved 9 March 2011.
[30] Adrian, Dimcev. "False Start" (http:/ / www. carbonwind. net/ blog/ post/ Random-SSLTLS-101-False-Start. aspx). Random SSL/TLS 101. .
Retrieved 9 March 2011.
[31] These certificates are currently X.509, but there is also a draft specifying the use of OpenPGP based certificates.
[32] vsftpd-2.1.0 released (http:/ / scarybeastsecurity. blogspot. com/ 2009/ 02/ vsftpd-210-released. html) Using TLS session resume for FTPS
data connection authentication. Retrieved on 2009-04-28.
[33] Named-based SSL virtual hosts: how to tackle the problem (https:/ / www. switch. ch/ pki/ meetings/ 2007-01/ namebased_ssl_virtualhosts.
pdf), SWITCH.
[34] Apple (2009-06-10). "Features" (http:/ / www. apple. com/ safari/ features. html). . Retrieved 2009-06-10.
[35] Adrian, Dimcev. "Common browsers/libraries/servers and the associated cipher suites implemented" (http:/ / www. carbonwind. net/
TLS_Cipher_Suites_Project/ tls_ssl_cipher_suites_annex_a1_main. docx). TLS Cipher Suites Project. .
[36] Mozilla (2008-08-06/). "Security in Firefox 2" (https:/ / developer. mozilla. org/ en/ Security_in_Firefox_2). . Retrieved 2009-03-31.
[37] "Bug 480514 - Implement support for TLS 1.2 (RFC 5246)" (https:/ / bugzilla. mozilla. org/ show_bug. cgi?id=480514). 2010-03-17. .
[38] Microsoft (2009-02-27). "MS-TLSP Appendix A" (http:/ / msdn. microsoft. com/ en-us/ library/ dd208005(PROT. 13). aspx). . Retrieved
2009-03-19.
[39] Yngve Nysæter Pettersen (2009-02-25). "New in Opera Presto 2.2: TLS 1.2 Support" (http:/ / my. opera. com/ core/ blog/ 2009/ 02/ 25/
new-in-opera-presto-2-2-tls-1-2-support). . Retrieved 2009-02-25.
[40] Chromium Project (2011-07-25). "No TLS 1.2 (SHA-2) Support" (http:/ / code. google. com/ p/ chromium/ issues/ detail?id=90392). .
Further reading
• Wagner, David; Schneier, Bruce (November 1996). "Analysis of the SSL 3.0 Protocol" (http://www.schneier.
com/paper-ssl.pdf). The Second USENIX Workshop on Electronic Commerce Proceedings. USENIX Press.
• Eric Rescorla (2001). SSL and TLS: Designing and Building Secure Systems. United States: Addison-Wesley Pub
Co. ISBN 0-201-61598-3.
• Joshua Davies (2011). Implementing SSL/TLS Using Cryptography and PKI. New York: Wiley.
ISBN 978-0470920411.
• Stephen A. Thomas (2000). SSL and TLS essentials securing the Web. New York: Wiley. ISBN 0-471-38354-6.
• Bard, Gregory (2006). "A Challenging But Feasible Blockwise-Adaptive Chosen-Plaintext Attack On Ssl" (http:/
/eprint.iacr.org/2006/136). International Association for Cryptologic Research (136). Retrieved 2011-09-23.
• Canvel, Brice. "Password Interception in a SSL/TLS Channel" (http://lasecwww.epfl.ch/memo/memo_ssl.
shtml). Retrieved 2007-04-20.
• IETF Multiple Authors. "RFC of change for TLS Renegotiation" (http://tools.ietf.org/html/rfc5746). Retrieved
2009-12-11.
• Creating VPNs with IPsec and SSL/TLS (http://www.linuxjournal.com/article/9916) Linux Journal article by
Rami Rosen
165
External links
•
•
•
•
•
•
•
•
•
SSL 2 specification (http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html) (published 1994)
Early drafts of SSL 3.0 specification (http://tools.ietf.org/html/draft-freier-ssl-version3-00) (published 1995)
The Secure Sockets Layer (SSL) Protocol Version 3.0 (2011) (http://tools.ietf.org/html/rfc6101)
The IETF (Internet Engineering Task Force) TLS Workgroup (http://www.ietf.org/html.charters/tls-charter.
html)
SSL tutorial (http://www2.rad.com/networks/2001/ssl/index.htm)
ECMAScript Secure Transform (Web 2 Secure Transform Method) (http://www.semnanweb.com/
ecmast-ecmascript-secure-transform/)
OWASP: Transport Layer Protection Cheat Sheet (http://www.owasp.org/index.
php?title=Transport_Layer_Protection_Cheat_Sheet)
A talk on SSL/TLS that tries to explain things in terms that people might understand. (http://computing.ece.vt.
edu/~jkh/Understanding_SSL_TLS.pdf)
SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/
ssl.html)
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed
under the GFDL.
X.509
In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) and Privilege Management
Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate
revocation lists, attribute certificates, and a certification path validation algorithm.
History and usage
X.509 was initially issued on July 3, 1988 and was begun in association with the X.500 standard. It assumes a strict
hierarchical system of certificate authorities (CAs) for issuing the certificates. This contrasts with web of trust
models, like PGP, where anyone (not just special CAs) may sign and thus attest to the validity of others' key
certificates. Version 3 of X.509 includes the flexibility to support other topologies like bridges and meshes (RFC
4158). It can be used in a peer-to-peer, OpenPGP-like web of trust, but was rarely used that way as of 2004. The
X.500 system has only ever been implemented by sovereign nations for state identity information sharing treaty
fulfillment purposes, and the IETF's Public-Key Infrastructure (X.509), or PKIX, working group has adapted the
standard to the more flexible organization of the Internet. In fact, the term X.509 certificate usually refers to the
IETF's PKIX Certificate and CRL Profile of the X.509 v3 certificate standard, as specified in RFC 5280, commonly
referred to as PKIX for Public Key Infrastructure (X.509).
Certificates
In the X.509 system, a certification authority issues a certificate binding a public key to a particular distinguished
name in the X.500 tradition, or to an alternative name such as an e-mail address or a DNS-entry.
An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI
system. Browsers such as Internet Explorer, Netscape/Mozilla, Opera, Safari and Chrome come with root certificates
pre-installed, so SSL certificates from larger vendors will work instantly; in effect the browsers' developers
determine which CAs are trusted third parties for the browsers' users.
166
X.509
167
X.509 also includes standards for certificate revocation list (CRL) implementations, an often neglected aspect of PKI
systems. The IETF-approved way of checking a certificate's validity is the Online Certificate Status Protocol
(OCSP). Firefox 3 enables OCSP checking by default along with versions of Windows including Vista and later.
Structure of a certificate
The structure foreseen by the standards is expressed in a formal language, namely Abstract Syntax Notation One.
The structure of an X.509 v3 digital certificate is as follows:
• Certificate
•
•
•
•
•
Version
Serial Number
Algorithm ID
Issuer
Validity
• Not Before
• Not After
• Subject
• Subject Public Key Info
• Public Key Algorithm
• Subject Public Key
• Issuer Unique Identifier (optional)
• Subject Unique Identifier (optional)
• Extensions (optional)
• ...
• Certificate Signature Algorithm
• Certificate Signature
Each extension has its own id, expressed as Object identifier, which is a set of values, together with either a critical
or non-critical indication. A certificate-using system MUST reject the certificate if it encounters a critical extension
that it does not recognize, or a critical extension that contains information that it cannot process. A non-critical
extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.
The structure of Version 1 is given in RFC 1422 [1].
ITU-T introduced issuer and subject unique identifiers in version 2 to permit the reuse of issuer or subject name after
some time. An example of reuse will be when a CA goes bankrupt and its name is deleted from the country's public
list. After some time another CA with the same name may register itself, even though it is unrelated to the first one.
However, IETF recommends that no issuer and subject names be reused. Therefore, version 2 is not widely deployed
in the Internet.
Extensions were introduced in version 3. A CA can use extensions to issue a certificate only for a specific purpose
(e.g. only for signing digital object). Each extension can be critical or non-critical. If an extension is critical and the
system processing the certificate does not recognize the extension or cannot process it, the system MUST reject the
entire certificate. A non-critical extension, on the other hand, can be ignored while the system processes the rest of
the certificate.
In all versions, the serial number MUST be unique for each certificate issued by a specific CA (as mentioned in RFC
2459).
X.509
168
Extensions informing a specific usage of a certificate
• Basic Constraints are used to indicate whether the certificate belongs to a CA.
• Key usage is used to specify the usage of the public key contained in the certificate.
• Extended key usage is used to indicate the purpose of the public key contained in the certificate. NSS uses this to
specify the certificate type.
As mentioned in RFC 5280, if key usage and extended key usage extensions are both present, both MUST be
processed and the certificate can only be utilized if both extensions are coherent in specifying the usage of a
certificate. For example, NSS uses both extensions to specify certificate usage.[2]
Certificate filename extensions
Common filename extensions for X.509 certificates are:
• .pem - (Privacy Enhanced Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN
CERTIFICATE-----" and "-----END CERTIFICATE-----"
• .cer, .crt, .der - usually in binary DER form, but Base64-encoded certificates are common too (see .pem
above)
• .p7b, .p7c - PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
• .p12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected)
• .pfx - PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated
in IIS)
PKCS#7 is a standard for signing or encrypting (officially called "enveloping") data. Since the certificate is needed
to verify signed data, it is possible to include them in the SignedData structure. A .P7C file is a degenerated
SignedData structure, without any data to sign.
PKCS#12 evolved from the personal information exchange (PFX) standard and is used to exchange public and
private objects in a single file.
Sample X.509 certificates
This is an example of a decoded X.509 certificate for www.freesoft.org, generated with OpenSSL—the actual
certificate is about 1 kB in size. It was issued by Thawte (since acquired by VeriSign), as stated in the Issuer field. Its
subject contains many personal details, but the most important part is usually the common name (CN), as this is the
part that must match the host being authenticated. Also included is an RSA public key (modulus and public
exponent), followed by the signature, computed by taking a MD5 hash of the first part of the certificate and signing
it (applying the encryption operation) using Thawte's RSA private key.
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/[email protected]
Validity
Not Before: Jul
9 16:04:02 1998 GMT
Not After : Jul
9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/[email protected]
X.509
169
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
To validate this certificate, one needs a second certificate that matches the Issuer (Thawte Server CA) of the first
certificate. First, one verifies that the second certificate is of a CA kind; that is, that it can be used to issue other
certificates. This is done by inspecting a value of the CA attribute in the X509v3 extension section. Then the RSA
public key from the CA certificate is used to decode the signature on the first certificate to obtain a MD5 hash, which
must match an actual MD5 hash computed over the rest of the certificate. An example CA certificate follows:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
Validity
Not Before: Aug 1 00:00:00 1996 GMT
Not After : Dec 31 23:59:59 2020 GMT
Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
X.509
170
00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
3a:c2:b5:66:22:12:d6:87:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
70:47
This is an example of a self-signed certificate, as the issuer and subject are the same. There's no way to verify this
certificate except by checking it against itself; instead, these top-level certificates are manually stored by web
browsers. Thawte is one of the root certificate authorities recognized by both Microsoft and Netscape. This
certificate comes with the web browser and is trusted by default. As a long-lived, globally trusted certificate that can
sign anything (as there are no constraints in the X509v3 Basic Constraints section), its matching private key has to be
closely guarded.
Security
There are a number of publications about PKI problems by Bruce Schneier, Peter Gutmann and other security
experts.[3][4][5]
Specification: Complexity and lack of quality
The X.509 standard was primarily designed to support the X.500 structure, but today's use cases center around the
web. Many features are of little or no relevance today. The X.509 specification suffers from being over-functional
and underspecified and the normative information is spread across many documents from different standardization
bodies. Several profiles were developed to solve this, but these introduce interoperability issues and did not fix the
problem.
X.509
171
Architectural flaws
•
•
•
•
•
Use of blacklisting invalid certificates (using CRLs and OCSP) instead of whitelisting
CRLs are particularly poor because of size and distribution patterns
Ambiguous OCSP semantics and lack of historical revocation status
Revocation of root certificates not addressed
Aggregation problem: Identity claim (authenticate with an identifier), attribute claim (submit a bag of vetted
attributes) and policy claim are combined in a single container. This raises privacy, policy mapping and
maintenance issues.
• Delegation problem: CAs cannot technically restrict subCAs to issue only certificates within a limited
namespaces and attribute set – this feature of X.509 is not in use. Therefore a large number of CAs exist on the
Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an
organization cannot be handled at all, as in common business practice.
• Federation problem: Certificate chains that are the result of sub-CAs, bridge- and cross-signing make validation
complex and expensive in terms of processing time. Path validation semantics may be ambiguous. Hierarchy with
3rd-party trusted party is the only model. This is inconvenient when a bilateral trust relationship is already in
place.
Problems of Commercial Certificate Authorities
• Flawed business model: The subject, not the relying party, purchases certificates. The RA will usually go for the
cheapest offer; quality is not being paid for in the competing market.
• CAs deny almost all warranties to the user.
• Expiration date: Should be used to limit the time the key strength is deemed sufficient. Abused by CAs to charge
the client an extension fee. Places unnecessary burden on user with key roll-over.
• In browsers, the security is that of the weakest CA. There are very weak CAs.
• "Users use an undefined certification request protocol to obtain a certificate which is published in an unclear
location in a nonexistent directory with no real means to revoke it." [5]
Implementation issues
Implementations suffer from design flaws, bugs, different interpretations of standards and lack of interoperability of
different standards. Some problems are:
• Many implementations turn off revocation check:
•
•
•
•
•
•
•
• Seen as obstacle, policies are not enforced
• If it was turned on in all browsers by default, including code signing, it would probably crash the
infrastructure.
DNs are complex and little understood (lack of canonicalization, internationalization problems, ..)
rfc822Name has 2 notations
Name and policy constraints hardly supported
Key usage ignored, first certificate in a list being used
Enforcement of custom OIDs is difficult
Attributes should not be made critical because it makes clients crash.
Unspecified length of attributes lead to product-specific limits
X.509
Exploits
• MD2-based certificates were used for a long time and were vulnerable to preimage attacks. Since the root
certificate already had a self-signature, attackers could use this signature and use it for an intermediate certificate.
Dan Kaminsky at 26C3.
• In 2005, Arjen Lenstra and Benne de Weger demonstrated "how to use hash collisions to construct two X.509
certificates that contain identical signatures and that differ only in the public keys", achieved using a collision
attack on the MD5 hash function.[6]
• In 2008, Alexander Sotirov and Marc Stevens presented at the Chaos Communication Congress a practical attack
that allowed them to create a rogue Certificate Authority, accepted by all common browsers, by exploiting the
fact that RapidSSL was still issuing X.509 certificates based on MD5.[7]
• X.509 certificates based on SHA-1 had been deemed to be secure up until very recent times. In April 2009 at the
Eurocrypt Conference [8], Australian Researchers of Macquarie University presented "Automatic Differential Path
Searching for SHA-1" [9]. The researchers were able to deduce a method which increases the likelihood of a
collision by several orders of magnitude.[10]
• Domain-validated certificates ("Junk certificates") are still trusted by web browsers, and can be obtained with
little effort from commercial CAs.
• EV-certificates are of very limited help, because Browsers do not have policies that disallow DV-certificates,
Zusman and Sotirov Blackhat 2009 [11]
• There are implementation errors with X.509 that allow e.g. falsified subject names using null-terminated strings
Marlinspike Blackhat 2009 [12] or code injections attacks in certificates.
• By using illegal[13] 0x80 padded subidentifiers of Object Identifiers, wrong implementations or by using
integer-overflows, an attacker can include an unknown attribute in the CSR, which the CA will sign, which the
client wrongly interpretes as "CN" (OID=2.5.4.3). Dan Kaminsky at 26C3.
PKI standards for X.509
• PKCS7 (Cryptographic Message Syntax Standard - public keys with proof of identity for signed and/or encrypted
message for PKI)
• Secure Sockets Layer (SSL) - cryptographic protocols for internet secure communications
• Online Certificate Status Protocol (OCSP) / Certificate Revocation List (CRL) - this is for validating proof of
identity
• PKCS12 (Personal Information Exchange Syntax Standard) - used to store a private key with the appropriate
public key certificate
Certification authority
A certification authority (CA) is an entity which issues digital certificates for use by other parties. It is an example of
a trusted third party. CAs are characteristic of many public key infrastructure (PKI) schemes.
There are many commercial CAs that charge for their services. Institutions and governments may have their own
CAs, and there are free CAs.
Public-Key Infrastructure (X.509) Working Group
The Public-Key Infrastructure (X.509) working group (PKIX) is a working group of the Internet Engineering Task
Force dedicated to creating RFCs and other standard documentation on issues related to public key infrastructure
based on X.509 certificates. PKIX was established in Autumn 1995 in conjunction with the National Institute of
Standards and Technology.[14]
172
X.509
173
Protocols and standards supporting X.509 certificates
•
•
•
•
•
•
•
•
•
•
•
•
•
Transport Layer Security (TLS/SSL)
Secure Multipurpose Internet Mail Extensions (S/MIME)
IPsec
SSH
Smart card
HTTPS
Extensible Authentication Protocol (EAP)
Lightweight Directory Access Protocol (LDAP)
Trusted Computing Group (TNC TPM NGSCB)
CableLabs (North American Cable Industry Technology Forum)
WS-Security
XMPP
Microsoft Authenticode
References
[1] http:/ / www. ietf. org/ rfc/ rfc1422
[2]
[3]
[4]
[5]
All About Certificate Extensions (http:/ / www. mozilla. org/ projects/ security/ pki/ nss/ tech-notes/ tn3. html)
Top 10 PKI risks (http:/ / hackerproof. org/ technotes/ pki/ pki_risks. pdf)
Peter Gutmann, PKI: it's not dead, just resting (http:/ / ieeexplore. ieee. org/ xpl/ freeabs_all. jsp?arnumber=1023787)
Gutmann, Peter. "Everything you Never Wanted to Know about PKI but were Forced to Find Out" (http:/ / www. cs. auckland. ac. nz/
~pgut001/ pubs/ pkitutorial. pdf). . Retrieved 14 November 2011.
[6] http:/ / www. win. tue. nl/ ~bdeweger/ CollidingCertificates/ ddl-full. pdf
[7] http:/ / www. win. tue. nl/ hashclash/ rogue-ca/
[8] http:/ / www. iacr. org/ conferences/ eurocrypt2009/
[9] http:/ / eurocrypt2009rump. cr. yp. to/ 837a0a8086fa6ca714249409ddfae43d. pdf
[10] SHA-1 Collision Attacks Now 252 (http:/ / www. secureworks. com/ research/ blog/ index. php/ 2009/ 6/ 3/ sha-1-collision-attacks-now-252/
)
[11] http:/ / www. blackhat. com/ presentations/ bh-usa-09/ SOTIROV/ BHUSA09-Sotirov-AttackExtSSL-PAPER. pdf
[12] http:/ / www. blackhat. com/ presentations/ bh-usa-09/ MARLINSPIKE/ BHUSA09-Marlinspike-DefeatSSL-SLIDES. pdf
[13] Rec. ITU-T X.690, clause 8.19.2
[14] http:/ / www. ietf. org/ dyn/ wg/ charter/ pkix-charter. html, PKIX Charter, 2/18/2010
• ITU-T Recommendation X.509 (http://www.itu.int/rec/T-REC-X.509) (2005): Information Technology Open Systems Interconnection - The Directory: Authentication Framework, 08/05.
• C. Adams, S. Farrell, "Internet X.509 Public Key Infrastructure: Certificate Management Protocols", RFC 2510,
March 1999
• Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL
Profile", RFC 3280, April 2002. Obsoleted by RFC 5280, Obsoletes RFC 2459/ updated by RFC 4325, RFC
4630.
• Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL
Profile", RFC 2459, January 1999. Obsoleted by RFC 3280.
• Arjen Lenstra, Xiaoyun Wang and Benne de Weger, On the possibility of constructing meaningful hash collisions
for public keys, full version, with an appendix on colliding X.509 certificates, 2005 (http://www.win.tue.nl/
~bdeweger/CollidingCertificates/) (see also (http://eprint.iacr.org/2005/067)).
X.509
External links
• ITU-T Recommendation X.509 : Information technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks (http://www.itu.int/rec/T-REC-X.509/en)
• Peter Gutmann's articles, an overview of PKI (http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.
pdf), X.509 implementation notes X.509 Style Guide (http://www.cs.auckland.ac.nz/~pgut001/pubs/
x509guide.txt)
• PKIX website (http://www.ietf.org/html.charters/pkix-charter.html)
• Enterprise Trust Integration and Web Services Security standards and demos (http://www.trustedwebservices.
org)
• FAQ from RSA Labs (http://www.rsasecurity.com/rsalabs/node.asp?id=2155)
• Sun Inc. - Secure code guidelines (http://java.sun.com/security/seccodeguide.html)
• RFC 4158 - Internet X.509 Public Key Infrastructure: Certification Path Building
• CSR Decoder and Certificate Decoder (http://certlogik.com/decoder) - can be used to decode and examine an
encoded CSR or certificate.
• SSL Checker (http://certlogik.com/sslchecker/) - can be used to test a certificate and that it has been installed
correctly
174
Advanced Encryption Standard Source: http://en.wikipedia.org/w/index.php?oldid=472506811 Contributors: *drew, ++Martin++, 16@r, 216.150.138.xxx, 403forbidden, AXRL, Adoniscik,
Afog, Ahoerstemeier, Aither, Ajithabraham.m, AlephGamma, Algocu, [email protected], AlistairMcMillan, Amoss, Andrei Stroe, Andy Dingley, AniLoveBe, Ansell, Antimatter15, Apapadop,
Apokrif, Arichnad, ArnoldReinhold, Arrowoftime, Arturj, Ashley Y, Ashmoo, Astronaut, Audriusa, Austin Hair, Avocade, Basawala, Batty, Bender235, BenjaminGittins, Bhny, Bile43113,
Binba, Blackvisionit, BrokenSegue, Bryan Derksen, Bsdaemon, CDV, CSWarren, Caligatio, Centrx, ChlkDstTtr, Chotchki, Chrisahn, Chrylis, Ciphergoth, ClementSeveillac, Climbon, Collard,
Conseguenza, Conversion script, Cralar, Cwmhiraeth, DMS, Daggilli, DanBealeCocks, Daniel.Cardenas, Danny, Darrien, DataWraith, David-Sarah Hopwood, Davidgothberg, Dawnseeker2000,
Dchristle, Dcoetzee, Denisutku, DerEikopf, Dermeister, Desnacked, Df1, Dimawik, Dirkx, Dispenser, Dmitriid, DocWatson42, Doctorhook, Donarreiskoffer, DopefishJustin, Dougher, Dougluce,
DrHok, Drj, EamonnAG, Ed g2s, Eike, ElBenevolente, ElectroKitty, Endareth, Ennan, Ericbg05, Farnik, Fintler, Flamurai, Flib0, Frencheigh, Frysalebald, Fudoreaper, Fxbx, Gaius Cornelius,
Galoubet, Gavia immer, George A. M., Gerbrant, Giftlite, Gndurant, Gogo Dodo, GoldKanga, Graham87, Grauw, Greg Tyler, GregorB, Gudguy1, Guy Macon, Haakon, Hadal, Hannes Röst,
Harishmalgae, Haseo9999, Hashar, Hashproduct, Hede2000, Hellisp, Hermes17, Hoho, Hugh Emberson, Hydrogen Iodide, IByte, Ianneub, Imran, Inkling, Intgr, Intractable, Itusg15q4user, James
mcl, James.nvc, Jaredwf, Jarhed, Jasper Chua, Jay, JayTau, Jeff G., Jeffz1, Jesse Viviano, Jestep, JidGom, Jim10701, Jmnbatista, Johnteslade, [email protected], Josh Liu,
Julesd, KTC, Kenyon, Kravietz, Kwamikagami, L33th4x0rguy, Lee Carre, Legios, Lightmouse, LinkTiger, Loadmaster, LodeRunner, LouScheffer, Luckyherb, Lukejamesoconnor, M@,
Malbrain, Manuel Anastácio, Marcel Augustus, Marcushan, MarioS, Marygillwiki, Mathiastck, Matt Crypto, Matusz, Maxgrin, Maximus Rex, Melchoir, MentalForager, Meridian, Mewtu, MiG,
Michael Shields, Michaelwagnercanberra, Mike Rosoft, Mike Schwartz, Mikolajpodbielski, Minna Sora no Shita, Miserlou, Mmernex, Mmtux, Moonradar, Mordemur, Msoos, NTF, Nabokov,
Nageh, Nat.latos, Netsnipe, Niyazlife, Nneonneo, Norm mit, Ntsimp, Numbo3, Nuwewsco, Ojigiri, Oleg1899, Ospalh, Pakaran, Paranoid123, Paulb73, Paulehoffman, PizzaMan, Pne, Poor
Yorick, Populus, Posix memalign, Pot, Powerlife, Prosfilaes, Pttam, Ptyantai, Puchiko, Quadell, Quallyjiang, Quantumor, Qutezuce, RP88, RainbowOfLight, Rajeshksv37, RealWorldExperience,
Rich Farmbrough, Richard506, Rjwilmsi, Roadrunner, Rob*, Robert Brockway, RobertG, Rodzilla, Romualdo Juan Caruso, Ross Burgess, RoySmith, Rprpr, SColombo, SKJDh, SLi, Sam
Hocevar, Samboy, SchreyP, Scovetta, Seb az86556, Sebastian Goll, Sfdev, Shadowborg, Sharcho, Shaul1, ShaunMacPherson, Sietse Snel, Simetrical, Singpolyma, SiobhanHansa, Sleske,
Sourcejedi, Starwiz, Steve Checkoway, Stevenj, Stevertigo, Stoive, Stolsvik, Superm401, Svick, Tassedethe, Template namespace initialisation script, TenPoundHammer, Teorth, TestPilot, The
Anome, The Thing That Should Not Be, Thelb4, Themfromspace, Thomas Springer, Thorwald, Threeafterthree, Tibti, Timeineurope, Timwi, Tom harrison, Tomcully, Tomstdenis, TonyW,
Torzsmokus, Vicarious, Volkan YAZICI, VvV, Wbm1058, Whkoh, Wikiborg, Wikisux, Wind73, Wingedsubmariner, Wj32, Wk muriithi, Wperdue, Ww, X-N2O, XFireRaidX, Xizhi.zhu,
ZipoBibrok5x10^8, Zvn, ‫דוד‬, शिव, 576 anonymous edits
Block cipher Source: http://en.wikipedia.org/w/index.php?oldid=467362535 Contributors: 203.37.81.xxx, Andrei Stroe, Anon lynx, Antikon, ArnoldReinhold, Arvindn, Beetstra,
Capitalistpiglet, Chris the speller, Conversion script, Davidgothberg, Derek Ross, DnetSvg, Dolovis, E090, Eurleif, Farnik, Frap, GBL, Gaius Cornelius, GregorB, Hellisp, Hephaestos, Ian
Kelling, Imran, Inkling, Intgr, Isomorphic, James Foster, Jesse Viviano, Joe12387, Kate, Keycard, Lightmouse, Liorma, LittleDan, Lunkwill, Mabdul, Mageaere, Marj Tiefert, Matt Crypto,
Michael Hardy, Miguel, Mitch Ames, Mmernex, Moink, Mordemur, Mxn, NZM, Nikai, Nixdorf, Nolaviz, Nslocum, Ntsimp, Phr, Pne, Purplie, Quarl, Qutezuce, Rich Farmbrough, Sam Hocevar,
Securiger, Sinar, Sverdrup, Taemyr, Tarmle, Tawker, Template namespace initialisation script, The Anome, TonyW, Varuna, Wfeidt, Ww, Xompanthy, ZipoBibrok5x10^8, 61 anonymous edits
Block cipher modes of operation Source: http://en.wikipedia.org/w/index.php?oldid=472160335 Contributors: A2800276, Acabre, Ahruman, Al Lemos, Andlaus, Andrejbuday, Arvindn,
BD2412, BenjaminGittins, Bharnish, Blaisorblade, Bmuzal, Bobrayner, Bunnyhop11, Calestyo, Cameltrader, CanisRufus, Cgouguen, Chester Markel, Chin50971, Chris the speller, Chrismiceli,
Ciphergoth, Ciphergoth2, ClementSeveillac, CommonsDelinker, Cootiequits, Dake, Daniel.Cardenas, Danroa, Davidgothberg, Drore, Ebonmuse, Edward Z. Yang, El jefe, Estr4ng3d, Faraz2444,
Finlay McWalter, Fireice, Flooey, GBL, Gareth Jones, Giftlite, Gmaxwell, Gustavb, Hannes Röst, Hao2lian, Hardikjshah07, Henning Makholm, Imran, Inkling, Intgr, Jdthood, Jigen III,
Jsmethers, Kleuske, L Kensington, Lennarth, Liiiii, Limninal, Loadmaster, Lunkwill, MarioS, Mark Zinthefer, Markusfnx, Matt Crypto, Michael Hardy, Michael93555, Miracle Pen, Miserlou,
Myria, Nageh, Nhianhchu, Noloader, Ntsimp, Pedro, Peyna, Phyburn, Piano non troppo, Pichote, Purplie, Qutezuce, R'n'B, R3m0t, Ra.ravi.rav, Reikon, Securiger, Shellreef, Sinar, Skintigh,
Sverdrup, Talion86, Template namespace initialisation script, TerraFrost, ThinkingInBinary, Ustadny, Veinor, WasAPasserBy, Whosyourjudas, William Radcliffe, Wingedsubmariner, Ww,
Zetawoof, ZipoBibrok5x10^8, 180 anonymous edits
Certificate authority Source: http://en.wikipedia.org/w/index.php?oldid=468667110 Contributors: A520, Acodring, Ahill.four, AlephGamma, [email protected], Anon lynx, Armandeh,
ArnoldReinhold, Astonishment, Azure, BAlfson, Badanedwa, Banano03, Bigjdady, Bmearns, Borgx, Brookehamilton, Btyner, Cameronpit, Comfortably Paranoid, Cryptoki, Dav-FL-IN-AZ-id,
Dawnseeker2000, Digi-cs, Doedoejohn, Druckles, Eiku, Espadrine, ExportRadical, Femto113, Fluff, Fredrik, GCW50, Gadiandi, Gerry Ashton, Globalsign, Gorgonzilla, Guido Arnold, Haakon,
Halloko, Howardjp, Hu12, Iida-yosiaki, Intgr, Jackzhp, Jc3s5h, Jeremy Reeder, Jleedev, Jnc, Jncraton, JohnHinsdale, JonHarder, Kenimaru, Kenschry, Kingturtle, LFaraone, Lakshmin, Ldardini,
Leobold1, Leotohill, Lezek, Lijnema, MER-C, Manawar4, Martin.komunide.com, Matt Crypto, Metalim, Michael Hardy, Mnemo, Mr. Sinister, MrWeeble, Mrbakerfield, Nabber00, Nealmcb,
Nickdc, Noq, Nurg, OpinionPerson, Pafciu, Pde, Peashy, PedanticSophist, Ppelleti, Pradeep itan, Primetomas, Ram Moskovitz, Rchandra, Reuben, Rich Farmbrough, Rmeneda, Robertrem, Ruud
Koot, SEWilco, Saucepan, Seungbaeim, Sinafe, SiobhanHansa, Smyth, Sroylance, Startcom, Sweerek, Texaswebscout, The Thing That Should Not Be, Thenthornthing, Tide rolls, Tjdw, Toniher,
TonyW, Velle, Vlad, Webguynik, Ww, Xanga, Yadirh, Yaronf, Zazpot, Zundark, Île flottante, 166 anonymous edits
CMAC Source: http://en.wikipedia.org/w/index.php?oldid=433644386 Contributors: Charles Matthews, DMJ001, Davidgothberg, GBL, Henning Makholm, RL0919, Radagast83, Robbieisfun,
Rydel7, 15 anonymous edits
Cryptographic hash function Source: http://en.wikipedia.org/w/index.php?oldid=473598272 Contributors: 83d40m, A930913, AP61, ATBS, Alienus, Amit 9b, Amol kulkarni,
Analoguedragon, AndyKali, Anirvan, Apokrif, Appleseed, Arakunem, ArchiSchmedes, Are you ready for IPv6?, Arjun024, ArnoldReinhold, Arvindn, Astronautics, Avinava, Bachrach44,
Bdragon, BenjaminGittins, BiT, Bobo192, Bomazi, Boredzo, Bpeps, Brian Gunderson, BrianWren, Bryan Derksen, Bsmntbombdood, C4chandu, Caltas, Capricorn42, Cenarium, CesarB,
CesarB's unpriviledged account, Chalst, Champloo11, Charles Matthews, Chuunen Baka, Ciphergoth, Ciphergoth2, Clark89, Colonies Chris, Coolhandscot, CryptoDerk, Cube444, CygnusPius,
Daemorris, DaishiHarada, Damian Yerrick, Danhash, Davidgothberg, Dbfirs, Dcljr, Deeb, Download, Eliz81, Enviroboy, Erianna, Erodium, FT2, Feedmecereal, Fils du Soleil, Firealwaysworks,
Fredrik, FrenchIsAwesome, Froth, Fuzzypeg, Gaius Cornelius, Gavia immer, Ggia, Giftlite, Guruparan18, H2g2bob, Harmil, Ianhowlett, Imjustmatthew, Imran, Infomade, Inkling, Instinct, Intgr,
JWilk, Jafet, Jamelan, January, Jasonsewall, Javidjamae, JensAlfke, Jesse Viviano, Jok2000, Jorge Stolfi, Jsaenznoval, JuanPechiar, Kotra, Kyz, Lambiam, Laurinavicius, Lee Carre, Leobold1,
Leonard G., Leszek Jańczuk, Lichtspiel, Lightst, Lotje, Lowellian, Lunkwill, MIT Trekkie, Mandarax, MarioS, Marios.agathangelou, Matt Crypto, Maurice Carbonaro, Maxal, Mdd4696, Mellery,
Michael Hardy, Michaelfavor, Mindmatrix, Mmernex, MoleculeUpload, Mrand, Myria, N5iln, Nbarth, Nipisiquit, NoDepositNoReturn, NormHardy, Ohnoitsjamie, Oli Filth, OnBeyondZebrax,
Optimist on the run, Oswald Glinkmeyer, Oxwil, Paranoid, Patriot8790, Pingveno, Plfernandez, PseudonympH, Quelrod, Quintus, Rabbler, Ratsbane, Rich Farmbrough, Robertgreer, RobinK,
Ruptor, SMC, ST47, Salvidrim, Samboy, Schneier, ShaunMacPherson, Sietse Snel, Simetrical, Sligocki, SmallPotatoes, Sroc, SteveJothen, Strongriley, Superm401, SwisterTwister, Sylletka,
Taxman, Teddyb, Tehsha, Thinking Stone, Tjfulopp, Tjwood, Tom Lougheed, TooTallSid, TreasuryTag, Tsihonglau, Twredfish, Twsx, VBGFscJUn3, Vssun, WLU, Whisky drinker, Wigie,
Wikipedian314, Wolfmankurd, Wordsmith, Ww, Xvsn, YUL89YYZ, ZipoBibrok5x10^8, Zsinj, Zundark, 311 ,.‫ תומר א‬,‫ קול ציון‬anonymous edits
Diffie–Hellman key exchange Source: http://en.wikipedia.org/w/index.php?oldid=464229141 Contributors: 2ndjpeg, A3RO, AlistairMcMillan, Anrie Nord, Armando, Arvindn, Autopilot,
AxelBoldt, Bcorr, Bigbluefish, Blokhead, Bobo192, Brentdax, Burningstarfour, Captain Segfault, CatherineMunro, Combatentropy, Conversion script, Cophus, Courcelles, CryptoDerk, Cyan,
Dalf, Dan Granahan, Dav-FL-IN-AZ-id, DavidJablon, Davidgothberg, Dispenser, Djadams35, Doh5678, Dokaspar, Don4of4, Doru001, Dreish, Dub13, ENeville, Ed g2s, Etu, Fbriere, Flex,
Flugaal, Fredrik, Frenchwhale, Garde, Giftlite, Gogo Dodo, Grahamrichter, Grammrsnob, GregorB, Haakon, Hagedis, Hawk777, HughNo, Inkling, Itusg15q4user, Jerry Segers, Jr., Jheiv,
JidGom, Jklamo, Jleedev, JoshuaZ, Kineticabstract, Kurykh, Larry_Sanger, Leonard G., Littleman TAMU, Looxix, Louelle, Lowellian, Lunkwill, MagnusPI, Malcolm Farmer, Mark Bergsma,
Matt Crypto, Meuston, Michael Hardy, MichaelBillington, Michel SALES, Minimac, Mmernex, Momet, Montpelier Vermont, Moshahmed, MrDomino, Mrogalski, NerdyScienceDude,
Neustradamus, Nmichaels, Noloader, Nuno Tavares, OwenX, Pakaran, Peashy, Peter Hendrickson, Pfaff9, Phil Holmes, PhilipMW, PierreAbbat, Piotrus, Plato, Plustgarten, PrimeFan, Pythomit,
Qartis, Quentin X, Raul654, Rfellows, Rich Farmbrough, Rs-leo, Samwb123, Saqib, Sashagolin, Shanes, Signalhead, Simetrical, Sin1man, Soliloquial, Stern, Thecrypto, Tim-J.Swan, Timwi,
TonyW, Torla42, Travis.m.granvold, Tuntable, Uncle Dick, Vacuum, Van Rijn, [email protected], Vishayv, WhiteAvenger, Wiso, Wrs1864, Ww, Yaronf, 194 anonymous edits
Digital signature Source: http://en.wikipedia.org/w/index.php?oldid=470238255 Contributors: .:Ajvol:., 5 albert square, [email protected], Acdx, Acprisip, Adrian, Adriatikus,
Ahoerstemeier, Akarkera, Akkida, Akma72, AlephGamma, Alex ruff, Alex756, Alvin Seville, Anomie, Antti29, Armando, ArnoldReinhold, Arvindn, AxelBoldt, Bah23, Bentogoa,
Bigdavesmith, Binarybits, Bluemoose, Bobo192, Bradshaws1, Bryan Derksen, Bsmith2008, Bugbee, Burlefot, C0dergirl, CKlunck, Cabouchonne, Calder, Can't sleep, clown will eat me,
Canadian Monkey, CecilWard, Ceyockey, Chaojoker, Chealer, Cherkash, Chris the speller, ClementSeveillac, Cpartners, Curps, DARTH SIDIOUS 2, David Shay, DavidJablon, Davidgothberg,
Dawnseeker2000, Devayon, Discospinster, DivineAlpha, Dokaspar, Elocktech, Epbr123, Equendil, Erianna, Etienne.navarro, Excirial, Farbicky, Fdbtwiki, FlyingToaster, Frau K, Fritz Saalfeld,
Funky Monkey, GCW50, Gadgetinspector, Gaius Cornelius, Gbiten, Gbroiles, Gcdinsmore, Gdo01, GeoffMacartney, Gerry Ashton, Gerson1875, Ggia, Ghettoblaster, Giftlite, Ginsengbomb,
GoingBatty, Guysha, Hariva, Infomade, Intgr, Isaacbowman, Isnow, J-Star, Jc3s5h, Jkcpop, Joffeloff, Jok2000, Josang, KAtremer, Klamber, Klausner, LapoLuchini, Liberty4u, Ligulem, Liridon,
Lotte Monz, Lošmi, Magioladitis, Malinaccier, Mangojuice, Mark J, Markush8, Martin.langhoff, Matt Crypto, Mboverload, Memark, Michael Hardy, Michael James Boyle, Michael miceli,
Modulatum, Mordemur, Mormegil, Mouse Nightshirt, MrOllie, Mrceylon, Myanw, Nachovaca, Nageh, Nichalp, Nickj, Nikai, Ninly, Nisiguti, Ntsimp, Ontargettaxsmile, Pak21, Palosirkka,
Peashy, Pekaje, Pharaoh of the Wizards, Philip Trueman, PierreAbbat, Pinethicket, Prabhuhari, ProfessorBaltasar, Rahulbud, Ramel.levin, Raven4x4x, RedWolf, RedWordSmith, Reetep, RexNL,
Rhoerbe, Rhsatrhs, Rich Farmbrough, Rijndael, RobyWayne, Rohasnagpal, Ronhjones, Ronz, Rootxploit, SCWM, Sam Hocevar, Sandstein, SchnitzelMannGreek, Scottham15, Seizethedave,
Serkon, Settinghead, Shadowjams, Shoseido, Siddhant, Sintaku, Sjjupadhyay, Skippydo, Some jerk on the Internet, Sparky132, Spitfire, Sspecter, Steinsky, Stephenb, Stuartroebuck, Svetovid,
Tabbelio, Taejo, TastyPoutine, Technopat, Thryduulf, Tkynerd, Tobias Bergemann, Toolnut, TreasuryTag, Turnstep, Txuspe, VBGFscJUn3, Varuna, Vary, Vashtihorvat, Viola16, Vito Genovese,
Viv5431, Vrenator, Vssun, WaltTFB, WereSpielChequers, Wiki alf, Wine Guy, Wintermute314, Wotnarg, Wtmitchell, Ww, Xiquet, Xyzmo, Z.E.R.O., ZamorakO o, Zazpot, Zeimusu, Zorro CX,
175
510 anonymous edits
Digital Signature Algorithm Source: http://en.wikipedia.org/w/index.php?oldid=459236085 Contributors: A.R., Airunp, AlistairMcMillan, Anharrington, Bill411432, Brownout, David-Sarah
Hopwood, Davidgothberg, Dd11, Dispenser, Dycedarg, Elf, Ellmist, Eric Sandholm, FBarber, Fantasy, Ferridder, Freddy436, GBL, Gabbe, Gapple, Geni, Greba, Guru, Henning Makholm,
Hephaestos, Inkling, Iulianu, Jozwiakjohn, Kb, Lobner, Matchups, Matt Crypto, Maxal, Metricopolus, Michael Hardy, Michalsjx, Neo2006, Nilmerg, Obscuranym, Optikos, Rich Farmbrough,
Rmigneron, Samboy, Siddhant, Stern, Stuuf, The Literate Engineer, TonyW, TreasuryTag, Unyoyega, Wapcaplet, Wolfmankurd, Ww, YumOooze, Zeno Gantner, 87 anonymous edits
HMAC Source: http://en.wikipedia.org/w/index.php?oldid=473515523 Contributors: Acdx, Angela, Aquntus, ArnoldReinhold, Arvindn, AxelBoldt, BenjaminGittins, BorkaD, Caligatio,
Capricorn42, CesarB's unpriviledged account, Chrismiceli, Conseguenza, Conversion script, CraSH, Crcklssp, Cvk, Cybercobra, DRLB, Daf, Daverocks, David-Sarah Hopwood, Davidgothberg,
Don4of4, Drake Redcrest, Drzepka, Ed Brey, Ehn, Firealwaysworks, Fluffy 543, Frap, GBL, Grignaak, Grr82, Gurch, Hanche, Heandel, IFaqeer, J-Wiki, Jafet, Jaydec, Jdcc, Jesse Viviano, Jsnx,
Kate, Kbk, Khazar, Lee J Haywood, Martijnthie, Matt Crypto, Michael miceli, Mmernex, Modbus.ug, MrOllie, Mrzaius, Nichalp, Northox, Ntsimp, ORBIT, Oli Filth, Pedro, Pgimeno,
Plfernandez, Polymorphm, Quadrescence, RJFJR, Reikon, Rettetast, Rich Farmbrough, Rjwilmsi, Runtime, Saimhe, Schnolle, Shd, Sinar, VegKilla, Voltin, Waxmop, Ww, Yaronf, ZamorakO o,
ZeroOne, 127 anonymous edits
HTTP Secure Source: http://en.wikipedia.org/w/index.php?oldid=474111652 Contributors: -jkb-, Acdx, Acodring, Adashiel, Af.pf, Alansohn, Aldie, AlefZet, AlistairMcMillan, Allamiro,
Allaryin, Allen4names, Anclation, Andonic, Andre Engels, Andrew4u, Angela, Angus Lepper, Annysmith001, Anonymous Dissident, Arcade, Arvindn, Ashley Y, Barakw, Bassbonerocks,
Beetstra, Ben-Zin, Bevo, BiT, Blood sliver, Bobo192, Bongwarrior, Bozoid, Brainsuccess, BrianGV, Brianhe, BrunoHarbulot, Buss, C. A. Russell, Calm, Caltas, Can't sleep, clown will eat me,
Canon, Card, Chainz, Chaos5023, Cherlin, Chowbok, Chriswiki, Clumpidy, Cocytus, Codetiger, Contentasaurus, Conversion script, Courcelles, Cybercobra, DARTH SIDIOUS 2, DStoykov,
DVD R W, Dabomb87, Damian Yerrick, Daniel1, DarwinPeacock, Dazmax, Dbenbenn, Ddas, Demiurge, Denisarona, Dequid, DerHexer, Destynova, Dibblethewrecker, Dnicolaou, DougWare,
EditorsChoice, Edoe, Edwin, EncMstr, Epbr123, Erik9, Esb, Everyking, Excirial, Favonian, Felipe1982, Filing Flunky, Fnielsen, FrankAndProust, Fred Bradstadt, Fubar Obfusco, Furrykef, GHe,
Gabipetrovay, Gaurav1424, Gautier lebon, Geneb1955, Ghettoblaster, Glane23, Gogo Dodo, GrahamJAT, Grawity, GringoCroco, HaeB, Halvorsen brian, Hdt83, Helixer, HenryLi, Heymid,
Hrvoje Simic, Hut 8.5, IMSoP, IRedRat, Iggytko, Immunize, Insanity Incarnate, Inspire22, Intgr, Irishguy, JGXenite, JPG-GR, JTN, Jebba, Jeffhos, Jeltz, Jeremy Visser, Jesse Viviano, Jim10701,
Johan Burati, John of Reading, JonHarder, Jordan Gray, Jredmond, Jshadias, Kain Nihil, Ke din, Kevin, Kevin B12, Kingpin13, Kne1p, Koavf, Ksn, Kst2005, KuduIO, Kvng, Kwertii, LCarl,
Lachlan Hunt, Lakshmin, LapoLuchini, LeonardoGregianin, Logical2u, Lord Pistachio, Lord Snoeckx, Loren.wilton, Lorenzarius, LorenzoB, MER-C, MICKLEK, Mac, Magioladitis, Mahewa,
Malo, Mandarax, Maros, Martinwguy, Matagascar, Matt Crypto, McGeddon, Meskalitos, Metamorph123, MetsFan76, Mike Rosoft, Mindmatrix, Minna Sora no Shita, Mjscud, Mmernex,
Mormegil, Mortein, MrBoo, Mrqcho, Msiebuhr, Mysidia, N419BH, NERIC-Security, Nageh, Neilka, Netzen, NewEnglandYankee, NiceGuyAlberto, Noishe, Nurg, Oiudfgogsdf,
Omicronpersei8, OpenInfoForAll, OrangeDog, Otto42, OwenX, Pako, Parsecboy, Patrick, Peanut.pookie, Peterl, Piano non troppo, Pimlottc, PinchasC, Planecrash111, Plugwash, Porchcorpter,
Produke, Profoss, Prolog, Ps ttf, Quinxorin, Qxz, RP459, RaCha'ar, Raeky, Ragimiri, RainbowOfLight, Randy Johnston, Rannpháirtí anaithnid, Rbb l181, Redrose64, Reisio, Remember the dot,
Rick Block, Rjwilmsi, Rnicoll, RockMFR, RossPatterson, Royalguard11, Rrburke, Rrjanbiah, S.K., SURIV, Safety Cap, Scott5114, Senator2029, Shanes, Shirishag75, SimonMorgan, Sixmeters,
Slach, Smalljim, Snowolf, Socrates2008, Some jerk on the Internet, Someguy1221, Spezied, Srose, StaticVision, StephenBuxton, Stephenb, Stubblyhead, Stwalkerster, Subsume, SupaStarGirl,
Sweeper tamonten, Tambarge, The Anome, The Thing That Should Not Be, TheJosh, Thecheesykid, Thingg, Thomas Springer, Thomasyen, Tigga en, Tlaresch, TomasBat, TonyW, Topaz,
Toussaint, Trusilver, Varlaam, Veraladeramanera, Versageek, Versus22, Vrenator, Wenli, Wereon, Wikingtubby, Wmahan, WojPob, WookieInHeat, WorldlyWebster, Ww, YUL89YYZ,
Yamamoto Ichiro, Yaronf, Yonatan, Zachlipton, Zeno Gantner, Zfr, Ziggymarley01, Zizomis, Zntrip, Zollerriia, Zzuuzz, Zzyzx11, ‫ﺃﺣﻤﺪ‬, ‫ﻣﺎﻧﻲ‬, とある白い猫, 551 anonymous edits
IPsec Source: http://en.wikipedia.org/w/index.php?oldid=472108915 Contributors: (, 00110001, 28421u2232nfenfcenc, AShadowed, AVand, Aaronbrick, Abdull, Abune, Aldie, AlephGamma,
Alvestrand, Anon lynx, Ashdurbat, Asteffen, B, Beland, BenAveling, Bender235, Betbest1, Borgx, Brian Patrie, Bryan Derksen, Can't sleep, clown will eat me, Captain panda, Cburnett, CesarB,
Cfleisch, Cheungpat, Chuq, Cnadig, Cokoli, Comatose51, CommonsDelinker, Crakkpot, Cschlatt, Cwolfsheep, CyberSkull, Cybercobra, DGtlRift, Dandorid, DataWraith, Daveg1k,
Davidvandebunte, DomQ, Drangon, Dugauthier, ElKevbo, Elimerl, Elsendero, Enjoi4586, EnzoMatrix, Falcon9x5, Falconsgladiator, Flockmeal, Flyer 13, Fornn50386503, Fragglet, Frap, Fylke,
Gadget850, Giftlite, Grahame, Gudeldar, Haakon, Hairy Dude, Hawaiian717, Hede2000, Herbertxu, Het, Hmwith, Htrstc, Hu12, Huitema, Ilia Kr., Int21h, Intgr, Isilanes, J.delanoy, Janizary,
Jdeg, Jearle, Jedikaiti, Jengelh, JidGom, Johnuniq, Jonathanbenari, Jtdowney, Karn, Kbrose, KenBailey, KentTong, Ketiltrout, Kgfleischmann, Kimvais, Kinema, Ksylian, Kwiki, Liberty Miller,
LilHelpa, Limbo socrates, M. B., Jr., Mange01, Marek69, MarioS, Markaci, Materialscientist, Mator, Matt Crypto, Mbaer3000, Mcr314, Meand, Mecki78, Menkalos, Mike Rosoft, Mindmatrix,
Minesweeper, Mintleaf, MitRouting, Mmernex, Mout, MrOllie, Nabber00, NapoliRoma, Nate Silva, Ncbhavsar, Nealmcb, Neillucas, Niceguyedc, Nichtich, Nick Number, Nikicat, Niteowlneils,
Novasource, Ntsimp, Pabouk, Paul Koning, Paulehoffman, Phatom87, Philmonty, Plat'Home, Plustgarten, Pol098, Postrach, Pwouters, Quanstro, Racaille, Rafigordon, Rchandra, Rearden9,
RedWolf, RexNL, Reza 2638, Rich257, Rjsrjs, Rjwilmsi, RossPatterson, Royhills, Rsrikanth05, Samikamel, Scott.somohano, Sietse Snel, Soltwisch, SpaceFlight89, Spearhead, Srinikal, Stan
Shebs, Stephan Leeds, Storkk, Subrata23, Sunny256, Suruena, THF, Taral, Tech editor007, Thane Eichenauer, The Anome, TheProject, Tje, TonyW, Victor, Vil, Vjardin, Vtomic85, Wellithy,
Whitepaw, Whkoh, Wiki alf, Wikieditor06, Wilcho, WillDeed, Wilson.canadian, Winterst, Wmahan, Writermonique, Ww, Xpclient, YUL89YYZ, Yachtsman1, Yaronf, Ykanada, Ynhockey,
Zareous, Zoicon5, 414 anonymous edits
Kerberos (protocol) Source: http://en.wikipedia.org/w/index.php?oldid=473597500 Contributors: Abune, Agou, Aldie, AlexHajnal, AlistairMcMillan, Amux, Andareed, Andrejj, Angela,
Ankurcha, Anon lynx, ArnoldReinhold, Aron Håkanson, Arvindn, AySz88, B.wilson, Bergsten, Blonkm, Bovineone, Bubba nuts, Bunnyhop11, Camaro889, Camelium, Cdinesh, Chealer, Choas,
Christopher G Lewis, Chuunen Baka, Clemente, Cmglee, Colonies Chris, Conversion script, Crakkpot, Crono logical, Ctrlsoft, Danakil, David McBride, Dawnseeker2000, Deflective, Doug A.
Hole, Dsonck92, Duhang, Eranb, Ericmc783, FleetCommand, Frits.a.m.storms, Fudoreaper, Fyyer, Gareth Jones, Gingekerr, Gioto, Gkf101z, Glenn, Grafor, Grawity, GregorB, Gronky,
Guoguo12, Hadal, Haikz, Hede2000, IanHarvey, Ignacioerrico, Int21h, Intgr, InverseHypercube, Ishi Gustaedr, Isilanes, IvanLanin, JLaTondre, JTN, Jdthood, Jerome Charles Potts, Jjplaya209,
Jldugger, Jmorgan, Joegreen, JonHarder, Jordan Brown, Julesd, Karlosian, Ke4roh, Kernel.package, Kl4m-AWB, Knguyeniii, Kowh, Koyaanis Qatsi, Kwamikagami, Liorma, Lovemachine,
LucienBoland, MITalum, Makaristos, Mariehuynh, Matt Crypto, Meetabu, Mezzaluna, Michael Hardy, Mikemaccana, Mindmatrix, Miremare, Mirror Vax, Mitsuhirato, Modify, MrBlueSky,
Mrwojo, Mwtoews, Nikai, Noloader, Nono64, Ntrval, OS2Warp, Omicronpersei8, OrangeDog, P40tomahawk, Pedant17, Petko, Petrb, Peyna, Pgan002, PhilipMW, Piet Delport, Piperx, Pmsyyz,
Pne, Pnm, PseudoSudo, RDBrown, RPage, RanchoRosco, Rebroad, RedWolf, Redhanker, Reelrt, Rfc1394, Richi, Rick.G, Romal, Ronark, Rsukhija, Sajjen, SamHartman, Saqib, Schultz.Ryan,
Scotto-san, Seeker68, Sergey Sergeevich Bondarenko, Shepard, Shreyasjoshis, Simon80, Stephan Leeds, StewartNetAddict, Strait, Tedp, The Storm Surfer, Thecheesykid, Tin, Tina scr, Tipiac,
Trasz, Treekids, Vectro, Verrai, Vladislav Artukov, Wandie, We64, Werson, West Brom 4ever, Wiglaf, WikHead, Wildzd01, Winryder, Wknight94, Ww, Wwwwolf, Xinconnu, Yaronf, Yoe,
Yonkie, Zac439, Zeroshell, Zntrip, 308 anonymous edits
Key distribution center Source: http://en.wikipedia.org/w/index.php?oldid=459608090 Contributors: Angela, ArnoldReinhold, Bongwarrior, CanisRufus, DARTH SIDIOUS 2, Damalexandra,
Ento, Fredrik, Gardar Rurak, Matt Crypto, Northamerica1000, Pb30, Pnm, Puckly, Sietse Snel, Ww, 15 anonymous edits
Message authentication code Source: http://en.wikipedia.org/w/index.php?oldid=473489609 Contributors: Abatakar, Ablewisuk, AdjustShift, Andris, Benizi, Bobo192, Callwithme, Ceyockey,
Ciphergoth, Connelly, Conny, CryptoDerk, Dachshund, Darkfight, David spector, Davidgothberg, Dimawik, DividedByNegativeZero, Dougher, Ed Brey, Edipo, Emufarmers, Gareth Jones,
Giftlite, HamburgerRadio, Henning Makholm, Iridescent, Jesse Viviano, Jorge Stolfi, KnightRider, Kotepho, Linas, Loadmaster, Macabu, Mandarax, Manscher, Matb, Matt Crypto, Maurice
Carbonaro, Merovingian, Messiah7, Michael Hardy, Mindmatrix, Mitch Ames, Nealmcb, Nroets, PabloCastellano, Pi.C.Noizecehx, Quarl, Qutezuce, Rasmus Faber, Robertgreer, RonaldDuncan,
Schnolle, Sh00tr, Shiningfm, Signalhead, Smilerpt, TLange, TonyW, TreasuryTag, Twisp, Varuna, Verloc, Wonderstruck, Ww, Xvani, Y(J)S, 56 anonymous edits
Needham–Schroeder protocol Source: http://en.wikipedia.org/w/index.php?oldid=466928111 Contributors: .snoopy., Alexei Kopylov, Bah23, Bender235, Chrismiceli, Danny, Econrad,
Epbr123, Gareth Jones, IanHarvey, Imran, KennethJ, Leobold1, Matt Crypto, Michael Hardy, PabloCastellano, Pnm, Soltwisch, Steffen Michels, Strait, The Anome, Tobias Bergemann,
Topbanana, Velle, Yaronf, 35 anonymous edits
Pretty Good Privacy Source: http://en.wikipedia.org/w/index.php?oldid=469957636 Contributors: -- April, 163.151.0.xxx, Aaliyah Stevens, Aarchiba, Abune, AdamRaizen, Aerion, Akrachev,
Alex.tan, Alphax, Alvestrand, Ambarish, Amckeen, Andrewpgp, Angela, Antandrus, Appraiser, Arj, Armando, ArnoldReinhold, Asa Winstanley, AustinKnight, Autopilots, BENNYSOFT, BRG,
Badams5115, Baffclan, Banes, Barefootguru, Baskerville, Bender235, Betacommand, Bevo, BewareofDoug, Bikepunk2, Birkett, Bkell, Blaxthos, Bobblewik, Boredzo, Brachiator,
Brendonjwilson, Brighterorange, Brindalv, C14, CSumit, CanOfWorms, Causa sui, Celarnor, Chemturion, Chetvorno, Chithecynic, ClementSeveillac, Coffee2theorems, CommonsDelinker,
Condem, Conversion script, Cosmia, Crimson30, CyberShadow, DanielPharos, David Gerard, David.turing, DavidLam, Dcodco, Dcraig, Dcshank, Derobert, Desk003, Dngrogan, DocWatson42,
Donreed, Dori, Doug, Dtwong, Duffman, Dyork, EEMIV, EclecticWriter, Edward Z. Yang, Electrolite, Electroshaman, Elf, Elvey, Epictive, Espoo, Euphrosyne, Evanluxzenburg, Evil saltine,
Ewlyahoocom, Fastfission, Feedmecereal, Feezo, Feldermouse, Ferdinand Pienaar, Ffaker, FlamingSilmaril, Flyguy649, Folajimi, Forgott3n, Frap, Fredrik, FreplySpang, Gaius Cornelius,
Gallaiis, Gatemansgc, Gerbrant, Gioto, Glenn, Gobonobo, Graham87, Grawity, Greenshed, Gregb, GregorB, Guyjohnston, Haakon, Hairy Dude, Hajhouse, Happyisenough, Harley peters,
Hchiari, Helixblue, Heron, Hnandrew, Hydrargyrum, Iain Cheyne, Insecurity, Instinct, Intgr, Isilanes, Islandboy99, Isomorphic, Ivan Štambuk, JTN, JacquesDemien, Janizary, Jdashca, Jdcc,
Jdforrester, Jeremy Visser, JidGom, Jim62sch, Joeblakesley, John L. Clark, Jonathan de Boyne Pollard, [email protected], Jsmethers, Jth299, Julie Deanna, KTC, Kaldosh,
Kanonkas, Keoki, Keycard, Kfitzner, Kimiko, Kmolnar, Korath, KrakatoaKatie, Kravietz, LOL, Lamentin, Leafyplant, Lee Vonce, LenaBerlin, Liftarn, Lissajous, Loadmaster, Lodders,
Logariasmo, Looper5920, LordBleen, Loren.wilton, Lotje, Lsi, Lupin, Luís Felipe Braga, MC10, MITalum, Malcolm Farmer, Markofvero, Martin451, Martinp23, Masgatotkaca, Matt Crypto,
Maurice Carbonaro, Maximaximax, Maxt, Mayevski, McGeddon, Megaboz, Melloss, Mentifisto, Mfinky, Michael Doherty, Michael Hardy, Minghong, Mintguy, Mitchumch, Mkallas,
Mmoneypenny, Moonradar, Moxfyre, Mrholybrain, Mszudzik, Muchosucko, My76Strat, NZM, Nabokov, Nagy, Nanoman, Ndurkes, Neelvk, Newmanbe, Nickshanks, Nikai, Niteowlneils,
Nixeagle, Noah Salzman, Ntsimp, Nuwewsco, Old Moonraker, OldakQuill, Orborde, Parhamr, Patrick Townsend Security Solutions, Pdw44wiki, Peter Karlsen, Peterl, Pgan002, Phishphan86,
Phoenix-forgotten, Phr, Piano non troppo, Pinkadelica, Pit, Pjacklam, Pne, Privacy is good, Prz, Puckly, PureFire, QuantumEleven, Quarl, RCVenkat, RabidDeity, Radiojon, Raggha, Raviaulakh,
Rchamberlain, Rearden9, Red Winged Duck, RedWolf, Requestion, Reset Smith, Reskusic, Rfportilla, Rholton, Rich Farmbrough, Richi, Rick Block, Ringbang, Rklawton, Rlaager, Rschen7754,
176
RyanDesign, Saheemg, Saniya al, SarekOfVulcan, Sbeyer, SciCorrector, Scubacuda, Selfsame, Shadowjams, Shalom Yechiel, SheeEttin, Shuipzv3, Sir Vicious, SirGrant, Skeptic za, Skysmith,
Spe88, Spiffytech, Spinteractive, Sppence, SquidSK, Starnestommy, Stephen Gilbert, StephenFerg, Stevietheman, Surv1v4l1st, Sutch, Sv1xv, Svetovid, Sx19216811, Taeshadow, Teferi, Telso,
Tempshill, Thearcher4, Tins128, Tobias Bergemann, ToddMiner, Toddst1, TooTallSid, Tothwolf, Tristanb, Turnstep, Ugen64, Veridis1348, Versageek, Vgranucci, VicVega123, Volty,
Vreemdst, WJBscribe, Warfieldian, Warren, Waveguide1360, Wavelength, Webmeischda, Weichbrodt, Wesley, Whitepaw, Wingman4l7, Woohookitty, Wrs1864, Ww, X1987x, XVertigox,
YYT, Yamla, Youssefsan, Yvh11a, Zeptomoon, Zven, Маркушя, ‫ﺃﺣﻤﺪ‬, 流氓兔老大, 端くれの錬金術師, 461 anonymous edits
Public key certificate Source: http://en.wikipedia.org/w/index.php?oldid=471967690 Contributors: Acyclopedic, Aerowolf, Alexei Kojenov, Anon lynx, Armando, ArnoldReinhold, Aryaniae,
BKoteska, BWikime, BazookaJoe, Blutrot, Bryan Derksen, Chatfecter, ClementSeveillac, Cody Cooper, Daniel.Cardenas, Davish Krail, Gold Five, Ddas, DeekGeek, Delta 51, Doberek,
Downwards, Dvorak.typist, Ecemaml, Egret, Eus Kevin, FlippyFlink, Folajimi, Fuzzy Logic, Gr8dude, Grawity, Gryszkalis, Guysha, HDCase, Haakon, Het, Hlkii, Hundred and half, Hut 8.5,
Intgr, Isnow, Itahmed, Ixfd64, JTN, Javidjamae, Jdthood, JidGom, Jlascar, Jonathanbenari, Jordav, Julesd, Kenschry, Klausner, Kokamomi, Leobold1, LimoWreck, Linktolonkar, Loxlie, MER-C,
Matt Crypto, Michael Hardy, Mindmatrix, Mnemeson, Mohsens, Mr alibebe, Mydogategodshat, Nabieh, Nailed, Nixdorf, Notmicro, Nurg, Paulsheer, PhilipMW, Pmetzger, Pxma, RP459,
Rasmus Faber, Remember the dot, Rentzepopoulos, Robertbowerman, Runningboffin, SPS1962W, Schnolle, Shinton, Sinar, Smaines, Steven Weston, Strait, Sydius, TOMTOM1974, Tabletop,
Teemuk, TonyW, Trammell, Ulrich Müller, Wrs1864, Ww, Xanga, Yaronf, Zarutian, ZimZalaBim, 159 anonymous edits
Public key infrastructure Source: http://en.wikipedia.org/w/index.php?oldid=474125709 Contributors: 123Hedgehog456, 2011superbowlarlington, ARUNKUMAR P.R, Aaliyah Stevens,
Aapo Laitinen, Abeynf, Acodring, Akurn, Albedo, Angeltoribio, Armando, ArnoldReinhold, Asterion, Atgbcn, Barfoos, Boblord, ByM4k5, CALR, Capi, Captain-n00dle, Ccpearson, Cdc,
Chinwan, Chris the speller, Chrkl, ClementSeveillac, Cracker017, Cryptoki, DRLB, Dan Austin, DanBlick, Dancter, Dav-FL-IN-AZ-id, Davidgothberg, Drbrain, Dysprosia, EagleOne, Edgerck,
Edward, Eeekster, Elocktech, Emeagvw, Emre D., Euagelos, Evil saltine, Farnik, Francs2000, Frap, Fyrael, GDibyendu, Galloping Moses, Giftlite, Gkf101z, Glines, Grendelkhan, HOYS, Haya
shiloh, Hires an editor, Howardjp, Ifconfig, Ilikedoraemon, Imran, Intgr, JForget, JH2010, Jarhed, Jc3s5h, JdKinne, Jeltz, Jessiema, Jmkim dot com, JonHarder, Jules.lt, Katharine908, Kdz,
Kenschry, Kim Bruning, Klausner, LTejas, Laurarekete, Leeannedy, Lukejamesoconnor, Lycurgus, MarkBrooks, Matt Crypto, Merlin1974, Mesoderm, Michael Hardy, Monicaready, Mordemur,
Morte, Mosca, MrOllie, Mrbakerfield, Muphry, Nabeth, Nabieh, NarSakSasLee, Neutrality, Ntsimp, Nyg212530, Ozmn, Pasky, Paulsheer, Peak, Pedronet, Ppatters, Primetomas, Quarl, RMehra,
Ramel.levin, Rasmus Faber, Reginald Gillins, RenniePet, Rhoerbe, Ronz, Sam Korn, Shinmawa, Siddhant, Simon naylor, Sinar, Skippydo, SkyRocketMedia, Slaniel, SpuriousQ, Stewartadcock,
Strait, Strbenjr, Stuartyeates, Subtosilencio, SunSw0rd, Tati-maranhao, Tdomhan, TheLDrinker, Thursbysoftware, ToastieIL, Tobias Bergemann, Tommy, Trey Stone, Turnstep, Uidzero,
Ultraexactzz, Unyoyega, Whkoh, Wimvanpuyvelde, Wkussmaul, Woupsi, Wrs1864, Ww, Xtrawings, Yaronf, ZebraMonkey, ZeiZai6Y, 362 anonymous edits
Public-key cryptography Source: http://en.wikipedia.org/w/index.php?oldid=469645347 Contributors: 28421u2232nfenfcenc, 8-Ball, Abdull, AbsolutDan, Adamd1008, Algebraist, Alpha
Quadrant, Alphax, Althepal, Alvin-cs, Andre Engels, AndrewGarber, Anomie, Anon lynx, Apokrif, Aravinthanjohn, Archer3, ArchiSchmedes, Armando, ArnoldReinhold, Arthur Rubin,
AxelBoldt, Baselsm, Bigbluefish, Birkett, Blouis79, Brec, Brianegge, Buzz-tardis, CBM, CRGreathouse, Calder, Cavan, Ccpearson, Cedgin, Chenyu, Chester Markel, Chocolateboy, Chomwitt,
Chris Capoccia, ChristopherThorpe, ChromiumCurium, ClementSeveillac, Cloudswrest, Conversion script, Corti, Craig t moore, CryptoDerk, Cryptonaut, DRLB, Daniel.Cardenas, Darksentinel,
David Oliver, David-Sarah Hopwood, DavidJablon, Davidgothberg, DeadEyeArrow, Delta G, Djordjes, Donreed, Drphilharmonic, Dsspiegel, Dtwong, Duoduoduo, Duplico, E235, Emansije,
Erichsu, Etienne.navarro, Excirial, Fat64, Faustnh, FeatherPluma, Ferkel, Fg, Frap, Gabe19, Garde, Geoffreybernardo, Ghimireabhinawa, Giftlite, Giles.reid, Gillespie09, Goncalopp, Graham87,
Gtg204y, Half price, Harley peters, Hashbrowncipher, Hmmwhatsthisdo, Hvs, Ihope127, Incredibly Obese Black Man, InformatoSaurus, Intgr, Isilanes, Isnow, J.delanoy, Jbening, Jd4v15, Jed
20012, JeremyR, Jfdwolff, Jjron, Jnc, Jobarts, John lindgren, Jomsr, Jonathanstray, Jredmond, Js coron, Juliano, KHamsun, Kaiserb, Katalaveno, Kember, Kingpin13, Kiwi128, Kkddkk, Klaws,
KohanX, Koveras, Kralizec!, Kratos 84, Kvamsi82, La goutte de pluie, Larry V, LedgendGamer, Lee J Haywood, Loadmaster, Loren.wilton, Luqui, MPerel, Magnificat, Manishsahni2000,
Manishtripathi.uno, Marj Tiefert, Markaci, Markskilbeck, Martarius, Marteau, MastCell, Matt Crypto, Maxis ftw, Mboverload, Mdwyer, Mentisock, Metamorph123, Metaprimer, Michael Hardy,
Michael miceli, Microprocessor Man, Mikaey, Mike Rosoft, Mindloss, Mmull, Mo ainm, MrArt, MrOllie, Mrendo, Mìthrandir, Necroticist, Ninly, Njan, Now3d, Octahedron80, Olegos,
Oliepedia, Ottomatic99, OutRIAAge, Oxymoron83, Pakaran, Paul August, PearlSt82, Peashy, Peter Hendrickson, Petr Kopač, Phaldo, Phatom87, Philipp Weis, Phr, PierreAbbat, Pinkadelica,
Pne, Poodah, Prz, Psychotic Spoon, Qwerty0, R Math, R'n'B, RMFan1, Radius, Raph79, Rasmus Faber, Robertgreer, Rossj81, Rprpr, Rror, Runefrost, Ryulong, Sander123, Schlafly, Schoen,
Scott McNay, Seipher, ShaSheng, Shenoybipin, Siddhant, Simetrical, Skarebo, Skippydo, Skomorokh, Skulvis, StevieNic, Stigmj, Stormie, Strbenjr, Stux, Tagesk, TastyPoutine, Tati-maranhao,
Tbc, The Rambling Man, TheCoffee, Thefisker, Thesfisker, Thric3, Tiptoety, TooTallSid, Torla42, TreasuryTag, Tumbarumba, Turnstep, UFMace, Urdutext, Vary, Vikreykja, Vonzack,
Wadlooper, Wesino, Wikidrone, Wilkie2000, Wireless friend, Wolfkeeper, Wshun, Ww, Yaronf, Youandme, Yuxin19, Zodon, 431 ,‫ דניאל צבי‬anonymous edits
RSA (algorithm) Source: http://en.wikipedia.org/w/index.php?oldid=473268006 Contributors: .:Ajvol:., 10metreh, 134.132.115.xxx, 137.205.8.xxx, 203.37.81.xxx, 213.253.39.xxx,
63.210.212.xxx, ANONYMOUS COWARD0xC0DE, Accurrent, Acyclopedic, Addshore, AdjustShift, Admp, Alastair Carnegie, Alexanderwdark, Alexwell, Ali'i, Allenc28, Alvin-cs,
AmiDaniel, Andrei Stroe, Anna512, Annie Yousar, Anon117, Apparition11, Aranherunar, Arctic Fox, ArielGold, ArnoldReinhold, Arronax50, Arvindn, Ash211, Astgtciv, Audriusa, AvicAWB,
Avuasku, Awesomepenguin, AxelBoldt, Axeloide, B.d.mills, Bart133, Ben-Zin, BenediktWildenhain, Big Smooth, BigaZon, Bigbluefish, Bigcheesegs, Birge, Bkell, Booyabazooka, Bryanclair,
Bullzeye, Burgercat, CALR, CTC1000, CWii, CYD, Cameron Dewe, Capt. James T. Kirk, Catgut, CesarB, Ceyockey, Chenzw, ChrisHodgesUK, Ciphergoth, Ciphergoth2, Clamster5,
ClementSeveillac, ColtM4, Comfortably Paranoid, Conversion script, CryptoDerk, Cryptonaut, Cspan64, Cyde, D, DJ Clayworth, DMJ001, DO11.10, Dachshund, Daftblight, Damian Yerrick,
DancingPhilosopher, Daniel.Cardenas, DarkFalls, Darkwind, Davidgothberg, Dcoetzee, Ddas1989, Debastein, Deflective, DerHexer, Diberri, Dirkbb, Dmeranda, Doeboy278x, DonDiego,
Donreed, Doomstars, Dririan, Edcolins, Elmer Clark, Elsurexiste, Endo999, Erianna, Eric Kvaalen, Etienne.navarro, F, Faithtear, Fang Aili, Farbicky, Feezo, Fgrieu, Fleminggatan, Fly by Night,
FrankFlanagan, Franl, Frap, Frazzydee, Fredrik, Freelance Intellectual, Fæ, GDallimore, Gail, Garde, Gargaj, Gensanders, Geremia, GiM, Giftlite, Gogo Dodo, Goodeffort, Goodnightmush,
Graham87, Haakon, Haikupoet, Hairy Dude, HamburgerRadio, HereToHelp, HermanFinster, Heron, Heyjune1407, Ianhowlett, Immunize, Inkling, Insrisg, Ishboyfay, Ixfd64, J. Finkelstein,
Jackol, Jameboy, Jaredwf, Jariola, Jdgilbey, Jeffz1, Jeltz, Jenovazero, Jesse Viviano, Jethro 82, Jitse Niesen, Jleedev, Jll, Jmobarak, Jngnyc, JoachimSchipper, JoeBruno, Joerite, Jogloran,
JohSpaeth, Johnpseudo, Jok2000, Josisb, Jpkotta, Jq4bagiq, Jredmond, Julesd, JuneGloom07, Jushi, Kalebdf, Kapilab, Katmaikni, Kencf0618, Kenyon, Kernel.package, Kkkhaha, Kravietz, Krun,
Kumar.varanasi, Kuteni, LC, LOL, Laurentius, Leafyplant, Lee Daniel Crocker, Ligulem, Limeheadnyc, Longhair, Luk, Lunkwill, Lzur, MOO, Maartenvanrooijen, Maddog Battie, Madman91,
MagnaMopus, Mani1, MarioS, Marlasdad, Matt Crypto, Maurogiachero, Mav, Mckoss, Melab-1, Mentifisto, Meuston, Michael Hardy, Michael Shields, Michael miceli, Michaelkourlas,
Mido41854, Mikeblas, Mikhail Ryazanov, Mindmatrix, Mipadi, Mjacobsz, Mkooy, Mmernex, Moonrabbit, MoraSique, Mormegil, MrDolomite, Museerouge, Mydogategodshat, NPrice,
NathanBeach, Nealmcb, Nedaljo, Neilc, Neoeinstein, Nihil novi, Nishkid64, Nomad421, Ntsimp, Nuesken, Octahedron80, Ohad.cohen, Orange Suede Sofa, OwenX, Oxymoron83, Pakaran,
Pandas, Papadopa, Papppfaffe, Paulcheffers, PegArmPaul, Perey, Perogi, Peyna, Pfortuny, Pgan002, Phildm, Pne, Possum, Protoclysm, QuantumEngineer, Ramiki, Random user 8384993, Ray
andrew, Rfellows, Ricardv46, Rljacobson, Rlove, RobHar, Rockfang, Ronhjones, Rorro, Rouenpucelle, S7evyn, Samaraga, Sasquatch, Saucam, Sdsouza, Seb az86556, Securiger, Shadypalm88,
Shannon bohle, ShaunMacPherson, Shinojvsekharan, Shiroi Hane, Shmoolik, Shreevatsa, Shreyasjoshis, Siddhant, Silverxxx, Sissssou, Sivar, Skippydo, Skysmurf, Sneakums, Snowolf, Spiff,
Stealth500, Stealthound, Stefan2, Steven Zhang, Stolsvik, Stuidge, Superm401, Suwa, Svick, Svm1 63, TGOO, TLange, TankMiche, Tarquin, TerraFrost, Tg, The Thing That Should Not Be,
TheCoffee, Thematrixeatsyou, ThomasStrohmann, Tim1988, Timwi, Tinctorius, Toolnut, Trevjos, Trevor Goodyear, Trou, Tuntable, Twas Now, Tyler, Tyler.szabo, Tylerl, UU, Uiteoi, Uncle G,
Ungvichian, Urhixidur, Utcursch, Velle, White Trillium, Wiener's Attack, Wiki alf, Wikidrone, Willguzzo, Willy411432, Wolfkeeper, Wolfmankurd, Wrp103, Ww, Xed, Yellowdesk, Zarius,
Zelmerszoetrop, Zntrip, 897 anonymous edits
S/MIME Source: http://en.wikipedia.org/w/index.php?oldid=472685016 Contributors: Aerowolf, Ale2006, Alvarogonzalezsotillo, ArnoldReinhold, Ary29, Asbirdi, Barefootguru, Brennanhay,
Btyner, CecilWard, Chu Jetcheng, Chzz, Cjkporter, CommonsDelinker, Comodo, DStoykov, DaBraunBird, Danimo, DarinHawley, Dast, EJNorman, Earle Martin, Elz dad, Frap, FredHyden,
Gogo Dodo, GoingBatty, Gorgonzilla, Gracefool, Gutza, Haakon, Ignacioerrico, Incnis Mrsi, Intgr, Isilanes, JRaue, Jallison, Jeltz, Jerome Charles Potts, Jim Craigie, Jpd, Jschot, Jvdzon, Kku,
Ksn, Leedar, Lkstrand, LotfiIT89, M.brinkers, Maetrics, Marygillwiki, Matt Crypto, Mayevski, Metafax1, Michaelfowler, Mr. Zdeeck, Mukake, Nealmcb, Ninly, Nneuman, Omniplex, PCStuff,
Phocks, Pnm, RCVenkat, Ram Moskovitz, Randomandy, SPKirsch, Saoshyant, Suseelan, Sverdrup, Tammojan, Teemuk, Tero, The Anome, ThurnerRupert, Venullian, Winchelsea, Wrs1864,
YUL89YYZ, Yaronf, 98 anonymous edits
Secure Electronic Transaction Source: http://en.wikipedia.org/w/index.php?oldid=431183512 Contributors: Alansohn, Argilo, Axel.fois, Becheung, David Gerard, Deville, Grimey109,
Ignacioerrico, Jarjoura, Juanpdp, Luismgarcia, MainFrame, Matt Crypto, MuffledThud, RJaguar3, SWAdair, Sbisolo, Shadowjams, Sietse Snel, SkyWalker, SouthernNights, Tad Lincoln, Tcncv,
Urdna, Vicky Ng, WMXX, Wk muriithi, Yun-Yammka, Zollerriia, 67 anonymous edits
Secure Shell Source: http://en.wikipedia.org/w/index.php?oldid=473652232 Contributors: 194.237.150.xxx, 4lex, 613crazydude, 72Dino, @modi, AThing, Adi4094, AeonicOmega,
AgentPeppermint, Aillema, Alan J Shea, Alerante, Alexav8, AlistairMcMillan, Allens, Alynna Kasmira, Amakuha, Analogue73, Andre Engels, AndriuZ, Anon lynx, Apokrif, Armando, Arthena,
Artorius, Astronouth7303, Audriusa, B4hand, BD2412, Ben Ben, Benjaminevans82, Beno1000, Bentogoa, Bernium, Bill.D Nguyen, Biot, Bomac, Borgx, Bovineone, Bpence, C.Fred,
CCFreak2K, CWenger, Caltas, Captainjackfromgermany, Captainspalding, Cdc, Cflm001, Chealer, Chowbok, Cisguy, CommonsDelinker, Controloye, Conversion script, Corpx,
Crazycomputers, CyrilB, [email protected], DStoykov, Dan Austin, Dan Forward, Daniel.Cardenas, Davidsxls, Dawnseeker2000, DeadEyeArrow, Demonburrito, Denis bider, DerHexer,
Dionyziz, Dissolve, Dlonceveau, Dmarquard, Doniago, Drinking.coffee, Drrngrvy, Drt1245, Dtwong, Dwlegg, EEMIV, EEPROM Eagle, Earthpigg, Eddie Nixon, Eeekster, Efa, Ehheh, Ehn,
EmilSit, Emperorbma, Ency, Enjoi4586, Equendil, Ernstdehaan, Faradayplank, Finavon, Fleminra, Flo422, Folajimi, Frap, Galactic Dominator, Galoubet, Gardar Rurak, Gary63, Gbeeker,
Gilesmorant, Giygas73, Glenn, Gosub, GotaForce, Grawity, Gronky, Guy Harris, Gwking, Hankwang, Harani66, Hawaiian717, Helix84, Hfastedge, Hobart, Honta, Hu12, Hugo 87, Hyad,
Icarus4586, Inkling, Interiot, InverseHypercube, IvanLanin, JLaTondre, JTN, Jackal242, Janizary, Jdthood, Jemocri, Jerome Charles Potts, Jesse Viviano, JesseHogan, Jfromcanada, Jgrahn,
JidGom, Jinlei, John Vandenberg, Jonkerz, KJRehberg, Karnesky, Kbrose, Kenguest, Kgfleischmann, Knarrff, Kotepho, Kravietz, Krellis, Krischik, Krithin, Kukini, Kwi, Kyng, L Kensington,
L33th4x0rguy, LFaraone, LOL, Larry V, Laukster, Laurusnobilis, Lbecque, Ledow, Lerdthenerd, Lightdarkness, Ligulem, LittleDan, Lklundin, Lord Bob, Lord Heinrich, Lotje, Lysdexia,
MCBastos, Mabdul, Manuel Anastácio, Markpeak, Markskilbeck, Matt Crypto, Mayevski, Mcaruso, Mchirico, Mdupont, MeekMark, MegaHasher, Mentifisto, Merriam, Michael Hardy,
MichaelBillington, Midnightcomm, Mikeblas, Mileswu, Mindmatrix, Mmernex, Mobystar, Mr.sanjibdhar, MrOllie, Mwtoews, NONCENSORED Popeye, Nandhpm, Nanshu, Nbauman,
Nealmcb, Nicolas1981, NilsB, Nixdorf, Nk, Noahspurrier, Noya Watan, Nurg, Ohconfucius, Olaf Davis, Olivier, Omniplex, Only2sea, Ortzinator, Pascalv, Pearle, Peppergrower, Perspective,
177
PhilipMW, Phoe6, Piepie, Pierremb, Plugwash, Prikryl, PrisonerOfIce, Profoss, Pseudometric, Qji, QueenCake, Quiddity, Random seed, Reconsider the static, ReiDx, Rich Farmbrough, Rifleman
82, Rjwilmsi, Robert Merkel, Rock drum, Romal, Romanm, Root2, Rootless, Rpresser, Schneelocke, SecurityBulletins.com, Seifried, Shd, Shellreef, Shibboleth, Shikaga, Siddhant, SimonEast,
Sleske, Sohailms, Solvedo, Stannered, Stephan Leeds, Steven Luo, Superm401, Suruena, Suso, Sverdrup, Syp, TakuyaMurata, Tarquin, TastyPoutine, TerraFrost, The Thing That Should Not Be,
The Zig, Thue, Tianjiao, TinaSDCE, Tirwhan, Tlroche, Tobias Bergemann, Tristanb, Tyrel, UncleBubba, Unixguy, Unixtastic, Urhixidur, Varnav, Verbose, WakiMiko, Welsh, Weregeek,
Wiehenkm, WikiFlier, Winryder, Wjmallard, WojPob, Wojtekmejor, Wronkiew, Wrs1864, Ww, Youssefsan, Yueni, ZachPruckowski, ZeroOne, 436 anonymous edits
Security service (telecommunication) Source: http://en.wikipedia.org/w/index.php?oldid=472106123 Contributors: Chris the speller, Drbreznjev, Mindmatrix, Pastore Italy
SHA-1 Source: http://en.wikipedia.org/w/index.php?oldid=471458555 Contributors: 216.150.138.xxx, 2mcm, 51kwad, AMK152, Aaboelela, Ace Frahm, Ahy1, Alex mayorga,
AlistairMcMillan, Almacha, Amitverma, Anastrophe, Anders Kaseorg, Are you ready for IPv6?, Armahmood786, ArnoldReinhold, Arto B, Arvindn, AstroHurricane001, Bblfish,
BenJWoodcroft, Benandorsqueaks, Bender235, Bernard Ladenthin, Bludpojke, Bobkart, Boredzo, Bovineone, Bryan Derksen, CALR, Caligatio, CanisRufus, Christopherlin, Ciphergoth,
Closedmouth, ColdWind, Colipon, Connelly, Conseguenza, Conversion script, Coolhandscot, CosineKitty, Creptes, Css, DMJ001, Dake, Dan East, Danpritts, Dark Mage, Darrien, David
Eppstein, Davidgothberg, Dawnseeker2000, Dcoetzee, Dffgd, Dimawik, Doradus, Download, Dynabee, Dzhim, Edward Z. Yang, Emurphy42, EncMstr, Encryptola, Erebus Morgaine, Evercat,
ExportRadical, FT2, Fabartus, Facorread, FatalError, Feedmecereal, Feezo, FelipeVargasRigo, Fetch, Fgrosshans, Filipvanlaenen, FireDemon, Firealwaysworks, FironDraak, Foant, Fredrik,
Furrykef, Gavia immer, Gennaro Prota, George Makepeace, Gerbrant, Gracefool, Graham87, GregorB, Greisby, GreyTeardrop, H2g2bob, Haakon, HeiseUK, Hephaestos, Hetzer, Hoho,
Hook43113, Hqb, Hrishikes, Huaiwei, ISGTW, Iamthenew!!, Imran, Inkling, Intgr, Ippopotamus, J-Wiki, JJC1138, Jacosoft apps, James A. Donald, Jaredwf, Javawizard, Jaymacdonald, Jcvox93,
Jdowland, Jeffz1, JeppeOland, Jerome Charles Potts, Jesse Viviano, Jk2q3jrklse, Jonabbey, Jonelo, Josesun, Jospedia, Jpkotta, Jrlevine, Jt, JulesH, KTC, Kazayta, Kevinmarks, KlaudiuMihaila,
Krayzray, Kricxjo, Ktr101, Kxx, LOL, LeaW, Lee Carre, Leonard G., Leotohill, Loadmaster, Lolden, Lotje, Lumingz, Lunkwill, MER-C, MKoltnow, Magnus.de, Makavelimx, Malbrain, MarioS,
Martin.cochran, Matt Crypto, Maurice Carbonaro, MauriceTrainer, MaxDZ8, Maxx573, Mbarulli, Mdd4696, Message From Xenu, Mhotas, Mike74, Millstream3, Mindmatrix, Miserlou, Mlutfi,
Mmernex, Modify, Moe Epsilon, Monarchy of Byzantium, Monowiki, Monterey Bay, Morten, Mr Heine, MrOllie, MrVacBob, Ms2ger, Msikma, Muhandis, Multani0, Myria, Navigatr85,
Nealmcb, Neelix, Neochoon, Ni fr, Nikai, Njaard, Noah Salzman, Noloader, Nova77, Ntsimp, Nutster, Ojcit, Olathe, Oli Filth, Omegatron, Optimisteo, Ota, OverQuantum, Pakaran, Paul August,
Paulschou, Peak, PerryTachett, PierreAbbat, Piet Delport, Polarina, Poposhka, Pretzelpaws, Prius 2, Protonk, Psychonaut, Psz, Python eggs, Qatter, Quelrod, Ra2007, Rabbler, Ram Moskovitz,
Random832, Rbk, Rdsmith4, Reidhoch, Rhobite, Rst, SCHLEGEBAGLE, ST47, Sadads, Samboy, Saqib, Sbeyer, Sceptre, Scheerer, Schneier, Schnolle, Sebastian Goll, Securiger, Shirifan,
Shreyasjoshis, Sietse Snel, Sinar, Sincedayone, Slashme, Smalku, Sommers, Speight, Spinal007, Splintercellguy, Stangaa, Storm Rider, Stormie, Supercoop, Supertouch, SuzieDerkins,
TakuyaMurata, Tarotcards, Taw, Tbsmith, Tcncv, TedAnderson, Tempodivalse, Thedjatclubrock, Themfromspace, Theta682, Timwi, Tobenvontoben, Tomstdenis, Tuxcrafter, Twipley, Veinor,
Virtual Particle, VladV, W2bh, Waldoalvarez00, Wavelength, Wilsonpenn, Ww, Xenophrenic, Xizhi.zhu, Xnquist, Xvani, Xylaan, YUL89YYZ, Ysangkok, Zarius, Zodon, Zundark, ‫תומר א‬., शिव,
555 anonymous edits
Stream cipher Source: http://en.wikipedia.org/w/index.php?oldid=472311501 Contributors: Alan smithee, Almit39, ArnoldReinhold, Arvindn, Bryan Derksen, Chetvorno, Chrumps,
Ciphergoth, Courcelles, Davidgothberg, Decrypt3, Derekgillespie, Dispenser, Edggar, Eisnel, Ep1973, Erik Zenner, Fintler, Frap, Freewol, Fudoreaper, GeorgeLouis, Gmaxwell, Inkling, Intgr,
Jeltz, Jesse Viviano, Jnc, Kvng, Lemma, Leotohill, Liustream, Loadmaster, Locutus Borg, Malcolm Farmer, Matejhowell, Matt Crypto, Mick Knapton, Mlaffs, Myria, Nageh, NathanKP,
NickShaforostoff, Nikai, Nixdorf, Pakaran, Petri Krohn, Peyna, Phil Boswell, Phr, PierreAbbat, Quondum, Rodzilla, Ruptor, SDC, Samuelcampos, SchreyP, Securiger, Sinar, Sjorford, Stannered,
Sverdrup, The Anome, Travis.m.granvold, Tsaitgaist, Wbm1058, Ww, Zetawoof, Zundark, 104 anonymous edits
Symmetric-key algorithm Source: http://en.wikipedia.org/w/index.php?oldid=473996011 Contributors: -Ozone-, 216.150.138.xxx, Abune, Acather96, Addis amara, Anonymous Dissident, Ap,
Arvindn, Bernard François, Bobski101, Brion VIBBER, BrokenSegue, Bsdlogical, Chameleon, Charles Matthews, Chris Capoccia, Ciphers, Conversion script, Daniel.Cardenas, Danielx,
Davidgothberg, Ddoomdoom, Dr. WTF, EamonnAG, Edd Porter, Eldawg, Fender123, Fetofs, Frap, GBL, Ggia, Giftlite, Graham87, GreatWhiteNortherner, Gurch, Hagedis, Hamoodi,
Hathawayc, ImMAW, Intgr, Isilanes, Jandalhandler, JeLuF, Knutux, Konstable, Kvng, Lerdsuwa, Maniadis, MarioS, Marj Tiefert, MarkSweep, Materialscientist, Matt Crypto, Michael Hardy,
Modify, Nuno Tavares, Octahedron80, Optimisteo, Pen1234567, Peruvianllama, Petr Kopač, Poli, Rich Farmbrough, RobertG, Runehol, Rythie, Schuetzm, Sciurinæ, Shadowjams, Shultzc, Sinar,
Snoyes, SunnyBingoMe, Sverdrup, Taw, That Guy, From That Show!, The Anome, The Rambling Man, The-mart, Tremilux, Twipley, Vanis, Wikidrone, WiseWoman, Wolfkeeper, Ww, 124
anonymous edits
Transport Layer Security Source: http://en.wikipedia.org/w/index.php?oldid=473622419 Contributors: 0x6adb015, 5ko, 806f0F, Abaybas, Abdull, AbsolutDan, Acodring, Adam Conover,
Adrianfd, Aka042, Akebinho, Albedo, Aldie, Alec it, Alias Flood, AlistairMcMillan, Amenel, Anclation, Andre Engels, Andrei.wap, Andrew Hampe, Andrzej P. Wozniak, Anna512, Anon lynx,
Ant honey, Antientropic, Apankrat, Aprogrammer, Arkoon, Arman Cagle, Armour Hotdog, Arsenikk, Ashdurbat, Avbentem, AxelBoldt, Barakw, Barek, Beetstra, Beland, Bender235, Beno1000,
Biot, Blackbearded, BlindWanderer, Blodulv, Boblord, Boomboombi, Borb, Bovineone, Branko, Branlon, Bryan Derksen, Btrzupek, Bunnyhop11, Burke Libbey, Bxj, C1010, CKlunck,
Cajunbill, Calton, CanadianLinuxUser, CanisRufus, Cellmate707, Cf. Hay, Cfp, Chealer, Chester Markel, Chris conlon, Ciphers, ClementSeveillac, Colenso, Colonies Chris, Comet Tuttle,
CommonsDelinker, Complicated1, Conseguenza, Conversion script, Crossland, Czhower, DARTH SIDIOUS 2, David-Sarah Hopwood, Davidfstr, Davidoff, Davodd, Dawnseeker2000,
Debresser, Devon Sean McCullough, Dictouray, Digi-cs, Discospinster, Doedoejohn, Dogbyter, Dougjih, Dreamafter, Ed Brey, Edward, Emperorbma, Enjoi4586, Ercrt, Ericnay, Erth64net,
Eruionnyron, Etu, Everyking, Evice, ExportRadical, Eyreland, FBarber, Falcon8765, Feezo, Felixcatuk, FlippyFlink, FloydRTurbo, Frap, Freyr, Fritzophrenic, Fryed-peach, Furrykef, GABaker,
Gerbrant, Ghalas, Ghettoblaster, Gidoca, Giftlite, GoodStuff, Graham87, Greatwhitesharkbear, GreyCat, Groovy12, Guthrg007, Gzorg, Haakon, HaeB, Haham hanuka, Hairy Dude,
HamburgerRadio, Hanche, Hawk-Eagle, Hgfernan, Hottdee, Iangfc, Iida-yosiaki, Imroy, Int21h, Interiot, Intgr, Isilanes, Itahmed, J-p krelli, JTN, JWilk, JaGa, Jamelan, Jas4711, Jc monk,
Jclemens, Jdthood, Jef-Infojef, Jesse Viviano, Jigen III, Jjplaya209, Jlehen, Jmaister, Jmorgan, JoanneB, JoaoRicardo, Joblack, JonHarder, Jpinkerton88, Juhovh, Julie Deanna, Kbrose, Kelson,
Kgaughan, Kgfleischmann, Kinema, Koektrommel, Koeplinger, Kpsmithuk, Krellis, Ksn, Kyng, Lakshmin, LeoNomis, Leotohill, Levin, LittleBenW, Loftenter, Lotje, Lradrama, Lukegilman,
Lundse, Lunkwill, Lzyiii, M. B., Jr., Maartenvanrooijen, Mabdul, Mac, Madigral, Magioladitis, MagnetiK, Mange01, Mani1, Marrowmonkey, Martinkunev, Matt Crypto, Matthew V Ball, Maxim
Razin, Mayevski, Meetabu, Meowimasexycat, Mgcsinc, Michael Hardy, MichaelCoates, Michaelfowler, Michaelkrauklis, Mickraus, Mike Rosoft, Mild Bill Hiccup, Mindmatrix,
MinorContributor, Mischling, MisterSSL, Mmernex, Molf, Moocha, Mpvdm, Mr Heine, Mrbbking, Msiddalingaiah, Mundocani, Mwanner, Mydogategodshat, Mårten Berglund, N.MacInnes,
Nagle, Nealcardwell, Nealmcb, Nerwal, Nikai, Nill smith, Nils, Ninels, Niqueco, Nitrogenx, Nk, Nmav, Nonno88, Noq, Ntsimp, Nubiatech, Nurg, Nuujinn, Nyco, ObscurO, Oconnor663, Olegos,
Olivier Debre, Omniplex, Oscardt, PHansen, Papadopa, Pasi Eronen, Paul Foxworthy, Paul1337, PeterB, Pfortuny, Phoenix-forgotten, Pilotguy, Plugwash, Plustgarten, Pmsyyz, Ppelleti, Produke,
Psz, Qslack, RP459, Raanoo, Rafigordon, Rarut, Rasmus Faber, Raviaulakh, Ray Dassen, Remember the dot, Rettetast, ReyBrujo, Rholton, Rich Farmbrough, RichiH, Rick Block, Ripsss,
Rlcantwell, Robertssh, Robinalden, SCΛRECROW, SPCartman, SSLcertificatesecurity, Sachuraju, Sanxiyn, Sara Wright, Scetoaux, Schlafly, Schmalls, Seneces, Sesu Prime, Sfisher, Shaddack,
Shadowjams, ShakataGaNai, Siddhant, Simetrical, Simon.may.007, Sleske, Smyth, Spartan-James, Speaker to Lampposts, SpeedyGonsales, Star General, Startcom, Stefonic, Stephan Leeds,
Stupid Corn, SunCreator, Superm401, Suruena, Swagatata, Sweeper tamonten, TDM, THEN WHO WAS PHONE?, TJJFV, Ta bu shi da yu, Tacke, Tbutzon, Ternto333, The Anome, TheWishy,
Themfromspace, Thomas Springer, Thomasgud, Thorne, Thumperward, Thunderbritches, Tim Ivorson, Titiri, Tommy2010, Tony esopi patra, Toyotabedzrock, Tqbf, Traveler100, TwelveBaud,
Twkd, Typhoonhurricane, UncleBubba, Unixman83, Uogl, Usaguruman, VAcharon, Verdy p, Versageek, VictorAnyakin, Vijay.kotari, Vinayr rao, VishalJBhatt, WLU, Webguynik, Weyes,
Wiarthurhu, Wilfrednilsen, William Avery, Winterst, Wizofaus, Wmahan, Wmasterj, WojPob, Writermonique, Wutherings, Ww, Xizhi.zhu, Yadirh, Yaronf, Youremyjuliet, Ysimonson, Yuhong,
Zigkill, Zimbabweed, Zr40, Zundark, Zzuuzz, 책읽는달팽, 798 anonymous edits
X.509 Source: http://en.wikipedia.org/w/index.php?oldid=474110112 Contributors: Abdull, Aerowolf, Alan J Shea, Alan U. Kennington, AlistairMcMillan, Altermike, Andreiko, Angeltoribio,
Angusmca, Armando, Azollman, [email protected], Bomazi, C960657, Captain panda, Cjcollier, Commander, Corti, Craiged, Cryptoki, D.w.chadwick, Daniel.Cardenas, Darac, David
Woolley, DeTreville, Digi-cs, Dkgdkg, Drondent, Dysprosia, Dzlabing, E2eamon, EagleOne, Eus Kevin, EvgeniGolov, Eyreland, Feezo, Fenring, Frap, Gorgonzilla, Grawity, Grendelkhan,
Gunn1, Gurch, Hoylen, Iida-yosiaki, Imran, Inkling, JTN, Jasuus, Jeff J. Snider, JidGom, John Vandenberg, JonHarder, Jonash, Judesba, Jwilkinson, KAtremer, Kdz, Kenschry, Kku, Klausner,
Kusma, Kw27, Libraequilibra, LightStarch, LilHelpa, MarkWahl, Matt Crypto, Mesoderm, Michael Hardy, Minghong, MoraSique, MrOllie, Mrbakerfield, Msct, Narayan82es, Nealmcb,
Neustradamus, Nono64, Nopherox, Nuwewsco, Orborde, OverlordQ, Pastore Italy, Pdejuan, PerryTachett, Racaille, Ram Moskovitz, Rasmus Faber, Rhoerbe, Rich Farmbrough, Robert Illes,
Rochus, Rohanuk, Samuel J. Howard, Saqib, Schnolle, Scorpiuss, Sega381, Siryendor, SkyRocketMedia, Sligocki, Smyth, Stevag, Stewartadcock, The Thing That Should Not Be, Thierrytung,
Tnshibu, Vegarwe, Vspaceg, Wgd, Whmac, Whophd, Wiarthurhu, Wik, WikiReviewer.de, Wrs1864, Ww, Xandi, YUL89YYZ, Zeroshell, Zundark, 156 anonymous edits
178
Image:AES-SubBytes.svg Source: http://en.wikipedia.org/w/index.php?title=File:AES-SubBytes.svg License: Public Domain Contributors: User:Matt Crypto
Image:AES-ShiftRows.svg Source: http://en.wikipedia.org/w/index.php?title=File:AES-ShiftRows.svg License: Public Domain Contributors: User:Matt Crypto
Image:AES-MixColumns.svg Source: http://en.wikipedia.org/w/index.php?title=File:AES-MixColumns.svg License: Public Domain Contributors: User:Matt Crypto
Image:AES-AddRoundKey.svg Source: http://en.wikipedia.org/w/index.php?title=File:AES-AddRoundKey.svg License: Public Domain Contributors: User:Matt Crypto
File:Ecb encryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Ecb_encryption.png License: Public Domain Contributors: ArnoldReinhold, Dr Juzam, Sdornan
File:Ecb decryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Ecb_decryption.png License: Public Domain Contributors: ArnoldReinhold, Dr Juzam, Sdornan
File:Tux.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Tux.jpg License: Attribution Contributors: Billz, Nilfanion, PL Przemek, Papa November, Rosenzweig, Sissssou, Ske,
WikipediaMaster
File:Tux ecb.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Tux_ecb.jpg License: Attribution Contributors: en:User:Lunkwill
File:Tux secure.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Tux_secure.jpg License: Attribution Contributors: en:User:Lunkwill
File:Cbc encryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Cbc_encryption.png License: Public Domain Contributors: ArnoldReinhold, Dr Juzam, Sdornan
File:Cbc decryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Cbc_decryption.png License: Public Domain Contributors: ArnoldReinhold, Dr Juzam, Sdornan
File:Pcbc encryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Pcbc_encryption.png License: Public Domain Contributors: Loadmaster (David R. Tribble)
File:Pcbc decryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Pcbc_decryption.png License: Public Domain Contributors: Loadmaster (David R. Tribble)
File:cfb encryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Cfb_encryption.png License: Public Domain Contributors: Gwenda
File:cfb decryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Cfb_decryption.png License: Public Domain Contributors: Gwenda
File:ofb encryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Ofb_encryption.png License: Public Domain Contributors: Gwenda
File:ofb decryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Ofb_decryption.png License: Public Domain Contributors: Gwenda
File:Ctr encryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Ctr_encryption.png License: Public Domain Contributors: Gwenda
File:Ctr decryption.png Source: http://en.wikipedia.org/w/index.php?title=File:Ctr_decryption.png License: Public Domain Contributors: Gwenda
Image:Cryptographic Hash Function.svg Source: http://en.wikipedia.org/w/index.php?title=File:Cryptographic_Hash_Function.svg License: Public Domain Contributors: User:Jorge Stolfi
based on Image:Hash_function.svg by Helix84
Image:Merkle-Damgard hash big.svg Source: http://en.wikipedia.org/w/index.php?title=File:Merkle-Damgard_hash_big.svg License: Public Domain Contributors: Davidgothberg
File:Diffie-Hellman Key Exchange.svg Source: http://en.wikipedia.org/w/index.php?title=File:Diffie-Hellman_Key_Exchange.svg License: Public Domain Contributors: Flugaal
Image:Digital Signature diagram.svg Source: http://en.wikipedia.org/w/index.php?title=File:Digital_Signature_diagram.svg License: Creative Commons Attribution-Sharealike 3.0
Contributors: Acdx
File:Shahmac.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Shahmac.jpg License: Creative Commons Attribution 2.0 Contributors: Bender235, Danhash, Dawnseeker2000,
ESkog, It Is Me Here, Jonerworm, Miserlou, Peachey88, Sfan00 IMG, 1 anonymous edits
File:Firefox 3 rc1 Extended Validation SSL address bar and certificate detail.PNG Source:
http://en.wikipedia.org/w/index.php?title=File:Firefox_3_rc1_Extended_Validation_SSL_address_bar_and_certificate_detail.PNG License: GNU General Public License Contributors: Original
uploader was GoddersUK at en.wikipedia
File:Firefox 3.0 error on svn.boost.org.png Source: http://en.wikipedia.org/w/index.php?title=File:Firefox_3.0_error_on_svn.boost.org.png License: unknown Contributors: Mozilla
Foundation
File:Loudspeaker.svg Source: http://en.wikipedia.org/w/index.php?title=File:Loudspeaker.svg License: Public Domain Contributors: Bayo, Gmaxwell, Husky, Iamunknown, Mirithing,
Myself488, Nethac DIU, Omegatron, Rocket000, The Evil IP address, Wouterhagens, 18 anonymous edits
File:Kerberos.svg Source: http://en.wikipedia.org/w/index.php?title=File:Kerberos.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:Dsonck92
Image:Kerberos.png Source: http://en.wikipedia.org/w/index.php?title=File:Kerberos.png License: Creative Commons Attribution-Sharealike 3.0 Contributors: User:AppleEx
Image:MAC.svg Source: http://en.wikipedia.org/w/index.php?title=File:MAC.svg License: Public Domain Contributors: Twisp
Image:Usage-of-Digital-Certificate.svg Source: http://en.wikipedia.org/w/index.php?title=File:Usage-of-Digital-Certificate.svg License: Creative Commons Attribution-Sharealike 3.0
Contributors: Eus Kevin (talk)
Image:Public-Key-Infrastructure.svg Source: http://en.wikipedia.org/w/index.php?title=File:Public-Key-Infrastructure.svg License: GNU Free Documentation License Contributors: Chris
論
File:Public-key-crypto-1.svg Source: http://en.wikipedia.org/w/index.php?title=File:Public-key-crypto-1.svg License: Public Domain Contributors: KohanX (talk)
Image:Public key signing.svg Source: http://en.wikipedia.org/w/index.php?title=File:Public_key_signing.svg License: Public Domain Contributors: Davidgothberg, 1 anonymous edits
Image:Public key shared secret.svg Source: http://en.wikipedia.org/w/index.php?title=File:Public_key_shared_secret.svg License: Public Domain Contributors: Davidgothberg
File:Adi Shamir 2009.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Adi_Shamir_2009.jpg License: Creative Commons Attribution-Sharealike 2.0 Contributors: Ira Abramov
from Even Yehuda, Israel
File:X11 ssh tunnelling.png Source: http://en.wikipedia.org/w/index.php?title=File:X11_ssh_tunnelling.png License: Creative Commons Attribution-ShareAlike 3.0 Unported Contributors:
Grön, Jleedev, Suwa, Sven, 1 anonymous edits
File:OpenWrtPuTTY.png Source: http://en.wikipedia.org/w/index.php?title=File:OpenWrtPuTTY.png License: unknown Contributors: Casablanca
File:Ssh binary packet alt.svg Source: http://en.wikipedia.org/w/index.php?title=File:Ssh_binary_packet_alt.svg License: Creative Commons Attribution 2.5 Contributors: Traced by
User:Stannered, original by en:User:Verbose using RFC4253 as source.
File:lll.png Source: http://en.wikipedia.org/w/index.php?title=File:Lll.png License: Public Domain Contributors: Matt Crypto
Image:Boxplus.png Source: http://en.wikipedia.org/w/index.php?title=File:Boxplus.png License: Public Domain Contributors: Grafite, Maksim
File:SHA-1.svg Source: http://en.wikipedia.org/w/index.php?title=File:SHA-1.svg License: Creative Commons Attribution-Sharealike 2.5 Contributors: User:Matt Crypto
Image:A5-1 GSM cipher.svg Source: http://en.wikipedia.org/w/index.php?title=File:A5-1_GSM_cipher.svg License: Public Domain Contributors: A5-1.png: User:Matt Crypto derivative
work: Tsaitgaist (talk)
Image:Nonlinear-combo-generator.png Source: http://en.wikipedia.org/w/index.php?title=File:Nonlinear-combo-generator.png License: Public Domain Contributors: Matt Crypto, Spoon!
Image:RC4.svg Source: http://en.wikipedia.org/w/index.php?title=File:RC4.svg License: Public Domain Contributors: Traced by User:Stannered, original by User:Matt Crypto
179
License
License
Creative Commons Attribution-Share Alike 3.0 Unported
//creativecommons.org/licenses/by-sa/3.0/
180

Security Articles from Wikipedia

Transcription

Similar documents

Certificate of Registration Evans Chemetics LP

ISO 9001

Certificate of Registration Glasseal Products Inc.

Certificate of Registration Cosmotronic Inc.

Certificate of Registration Lyn

Certificate of Registration Crissair, Inc.

Certificate of Registration Sealtron, Inc.

ISO 9001:2008 Certified - AFC

Certificate of Registration Aero Metals Inc

Sealtron AS9100 - ametek interconnect