Security Articles from Wikipedia

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


Advanced Encryption Standard 

AES 

The SubBytes step, one of four stages in a round of AES 

General 

Designers Vincent Rijmen, Joan Daemen 

First published 1998 

Derived from Square 

Successors Anubis, Grand Cru 

Certification AES winner, CRYPTREC, NESSIE, NSA 

Key sizes 

Block sizes 

Cipher detail 

128, 192 or 256 bits [1] 

128 bits [2] 

Structure Substitution-permutation network 

Rounds 10, 12 or 14 (depending on key size) 

Best public cryptanalysis 

All known attacks are computationally infeasible. For AES-128, the key can be recovered with a computational complexity of 2 126.1 using bicliques. 

For biclique attacks on AES-192 and AES-256, the computational complexities of 2 189.7 and 2 254.4 respectively apply. Related-key attacks can break 

AES-192 and AES-256 with complexities 2 176 and 2 99.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


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(2 8 ), known to have 

good non-linearity properties. To avoid 

attacks based on simple algebraic 

properties, the S-box is constructed by 

combining the inverse function with an 

invertible affine transformation. The 

S-box is also chosen to avoid any fixed 

points (and so is a derangement), and also any opposite fixed points. 

The ShiftRows step 

The ShiftRows step operates on the 

rows of the state; it cyclically shifts the 

bytes in each row by a certain offset. 

For AES, the first row is left 

unchanged. Each byte of the second 

row is shifted one to the left. Similarly, 

the third and fourth rows are shifted by 

offsets of two and three respectively. 

For the block of size 128 bits and 192 

bits the shifting pattern is the same. In 

this way, each column of the output 

In the SubBytes step, each byte in the state is replaced with its entry in a fixed 8-bit 

lookup table, S; b ij = S(a ij ). 

In the ShiftRows step, bytes in each row of the state are shifted cyclically to the left. 

The number of places each byte is shifted differs for each row. 

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.


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(2 8 ) and is then multiplied modulo x 4 +1 with 

a fixed polynomial c(x) = 0x03 · x 3 + x 2 + 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, 

and transforming them into a sequence 

of table lookups. This requires four 

256-entry 32-bit tables, which utilizes a 

In the AddRoundKey step, each byte of the state is combined with a byte of the round 

subkey using the XOR operation (⊕). 

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]


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 2 200 operations (compared to 

2 256 possible keys) would be considered a break, even though 2 200 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 2 119 . In December 2009 it was improved to 2 99.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 2 96 for one out of 

every 2 35 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 2 39 time to recover the complete 256-bit key of a 

9-round version, or 2 45 time for a 10-round version with a stronger type of related subkey attack, or 2 70 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 2 48 , 

and a memory complexity of 2 32 . 

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


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.


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). .


[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)


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, E K 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 K i as second input, which are derived from the original key: 

where is the plaintext and the ciphertext, with r being the round number. 

Frequently, key whitening is used in addition to this. At the beginning and the end, the data is modified with key 

material (often with XOR, but simple arithmetic operations like adding and subtracting are also used):


Many block ciphers can be categorised as Feistel networks, or, as more general substitution-permutation networks. 

Arithmetic operations, logical operations (especially XOR), S-boxes and various permutations are all frequently used 

as components. 

History 

Lucifer is generally considered to be the first civilian block cipher, developed at IBM in the 1970s based on work 

done by Horst Feistel. A revised version of the algorithm was adopted as a US government FIPS standard, the DES. 

It was chosen by the US National Bureau of Standards (NBS) after a public invitation for submissions and some 

internal changes by NBS (and, potentially, the NSA). DES was publicly released in 1976 and has been widely used. 

DES was designed to, among other things, resist a certain cryptanalytic attack known to the NSA and rediscovered 

by IBM, though unknown publicly until rediscovered again and published by Eli Biham and Adi Shamir in the late 

1980s. The technique is called differential cryptanalysis and remains one of the few general attacks against block 

ciphers; linear cryptanalysis is another, but may have been unknown even to the NSA, prior to its publication by 

Mitsuru Matsui. DES prompted a large amount of other work and publications in cryptography and cryptanalysis in 

the open community and it inspired many new cipher designs. 

DES has a block size of 64 bits and a key size of 56 bits. 64-bit blocks became common in block cipher designs after 

DES. Key length depended on several factors, including government regulation. Many observers in the 1970s 

commented that the 56-bit key length used for DES was too short. As time went on, its inadequacy became apparent, 

especially after a special purpose machine designed to break DES was demonstrated in 1998 by the Electronic 

Frontier Foundation. A variant of DES, Triple DES, triple-encrypts blocks with either two different keys (2 key 

TDES, resulting in a 112-bit keys and 80-bit security) or three keys (3 key TDES, resulting in a 168-bit key and 

112-bit security). It was widely adopted as a replacement. As of 2011, the three-key version is still considered 

secure, though National Institute of Standards and Technology(NIST) standards no longer permit the use of the 

two-key version in new applications, due to its 80 bit security level. 

DES has been superseded as a United States Federal Standard by the AES, adopted by National Institute of 

Standards and Technology (NIST) in 2001 after a 5-year public competition. The cipher was developed by two 

Belgian cryptographers, Joan Daemen and Vincent Rijmen, and submitted under the name Rijndael. AES has a block 

size of 128 bits and three possible key sizes, 128, 192 and 256 bits. The US Government permits the use of AES to 

protect classified information in systems approved by NSA. 

Cryptanalysis 

In addition to linear and differential cryptanalysis, there is a growing catalog of attacks: truncated differential 

cryptanalysis, partial differential cryptanalysis, integral cryptanalysis, which encompasses square and integral 

attacks, slide attacks, boomerang attacks, the XSL attack, impossible differential cryptanalysis and algebraic attacks. 

For a new block cipher design to have any credibility, it must demonstrate evidence of security against known 

attacks. 

Tweakable block ciphers 

M. Liskov, R. Rivest, and D. Wagner have described a generalized version of block ciphers called "tweakable" block 

ciphers. A tweakable block cipher accepts a second input called the tweak along with its usual plaintext or ciphertext 

input. The tweak, along with the key, selects the permutation computed by the cipher. If changing tweaks is 

sufficiently lightweight (compared with a usually fairly expensive key setup operation), then some interesting new 

operation modes become possible. The disk encryption theory article describes some of these modes.


Block 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). 


• 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


Block cipher modes of operation 

In cryptography, modes of operation is the procedure of enabling the repeated and secure use of a block cipher 

under a single key. [1][2] A block cipher by itself allows encryption only of a single data block of the cipher's block 

length. When targeting a variable-length message, the data must first be partitioned into separate cipher blocks. 

Typically, the last block must also be extended to match the cipher's block length using a suitable padding scheme. A 

mode of operation describes the process of encrypting each of these blocks, and generally uses randomization based 

on an additional input value, often called an initialization vector, to allow doing so safely. [1] 

Modes of operation have primarily been defined for encryption and authentication. [1][3] Historically, encryption 

modes have been studied extensively in regard to their error propagation properties under various scenarios of data 

modification. Later development regarded integrity protection as an entirely separate cryptographic goal from 

encryption. Some modern modes of operation combine encryption and authentication in an efficient way, and are 

known as authenticated encryption modes. [2] 

While modes of operation are commonly associated with symmetric encryption, [2] they may also be applied to 

public-key encryption primitives such as RSA in principle (though in practice public-key encryption of longer 

messages is generally realized using hybrid encryption). [1] 

History and standardization 

The earliest modes of operation, ECB, CBC, OFB, and CFB (see below for all), date back to 1981 and were 

specified in FIPS 81 [4] , DES Modes of Operation. In 2001, NIST revised its list of approved modes of operation by 

including AES as a block cipher and adding CTR mode in SP800-38A [5] , Recommendation for Block Cipher Modes 

of Operation. Finally, in January, 2010, NIST added XTS-AES in SP800-38E [6] , Recommendation for Block Cipher 

Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. Other confidentiality modes exist 

which have not been approved by NIST. For example, CTS is ciphertext stealing mode and available in many 

popular cryptographic libraries. 

ECB, CBC, OFB, CFB, CTR, and XTS modes only provide confidentiality; to ensure an encrypted message is not 

accidentally modified or maliciously tampered requires a separate message authentication code such as CBC-MAC. 

The cryptographic community recognized the need for dedicated integrity assurances and NIST responded with 

HMAC, CMAC, and GMAC. HMAC was approved in 2002 as FIPS 198 [7] , The Keyed-Hash Message 

Authentication Code (HMAC), CMAC was released in 2005 under SP800-38B [8] , Recommendation for Block 

Cipher Modes of Operation: The CMAC Mode for Authentication, and GMAC was formalized in 2007 under 

SP800-38D [9] , Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. 

After observing that compositing a confidentiality mode with an authenticity mode could be difficult and error prone, 

the cryptographic community began to supply modes which combined confidentiality and data integrity into a single 

cryptographic primitive. The modes are referred to as authenticated encryption, AE or authenc. Examples of authenc 

modes are CCM (SP800-38C [10] ), GCM (SP800-38D [9] ), CWC, EAX, IAPM, and OCB. 

Modes of operation are nowadays defined by a number of national and internationally recognized standards bodies. 

The most influential source is the US NIST. Other notable standards organizations include the ISO, the IEC, the 

IEEE, the national ANSI, and the IETF.


Initialization vector (IV) 

An initialization vector (IV) is a block of bits that is used by several modes to randomize the encryption and hence to 

produce distinct ciphertexts even if the same plaintext is encrypted multiple times, without the need for a slower 

re-keying process. 

An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. 

However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and 

CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared 

by the two messages. For OFB and CTR, reusing an IV completely destroys security. In CBC mode, the IV must, in 

addition, be unpredictable at encryption time; in particular, the (previously) common practice of re-using the last 

ciphertext block of a message as the IV for the next message is insecure (for example, this method was used by SSL 

2.0). If an attacker knows the IV (or the previous block of ciphertext) before he specifies the next plaintext, he can 

check his guess about plaintext of some block that was encrypted with the same key before (this is known as the TLS 

CBC IV attack). [11] 

As a special case, if the plaintexts are always small enough to fit into a single block (with no padding), then with 

some modes (ECB, CBC, PCBC), re-using an IV will leak only whether two plaintexts are equal. This can be useful 

in cases where one wishes to be able to test for equality without decrypting or separately storing a hash. 

Padding 

A block cipher works on units of a fixed size (known as a block size), but messages come in a variety of lengths. So 

some modes (namely ECB and CBC) require that the final block be padded before encryption. Several padding 

schemes exist. The simplest is to add null bytes to the plaintext to bring its length up to a multiple of the block size, 

but care must be taken that the original length of the plaintext can be recovered; this is so, for example, if the 

plaintext is a C style string which contains no null bytes except at the end. Slightly more complex is the original DES 

method, which is to add a single one bit, followed by enough zero bits to fill out the block; if the message ends on a 

block boundary, a whole padding block will be added. Most sophisticated are CBC-specific schemes such as 

ciphertext stealing or residual block termination, which do not cause any extra ciphertext, at the expense of some 

additional complexity. Schneier and Ferguson suggest two possibilities, both simple: append a byte with value 128 

(hex 80), followed by as many zero bytes as needed to fill the last block, or pad the last block with n bytes all with 

value n. 

CFB, OFB and CTR modes do not require any special measures to handle messages whose lengths are not multiples 

of the block size, since the modes work by XORing the plaintext with the output of the block cipher. The last partial 

block of plaintext is XORed with the first few bytes of the last keystream block, producing a final ciphertext block 

that is the same size as the final partial plaintext block. This characteristic of stream ciphers makes them suitable for 

applications that require the encrypted ciphertext data to be the same size as the original plaintext data, and for 

applications that transmit data in streaming form where it is inconvenient to add padding bytes.


Electronic codebook (ECB) 

The simplest of the encryption modes is the electronic codebook (ECB) mode. The message is divided into blocks 

and each block is encrypted separately. 

The disadvantage of this method is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus, 

it does not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not 

recommended for use in cryptographic protocols at all. A striking example of the degree to which ECB can leave 

plaintext data patterns in the ciphertext is shown below; a pixel-map version of the image on the left was encrypted 

with ECB mode to create the center image, versus a non-ECB mode for the right image. 

Original Encrypted using ECB mode Modes other than ECB result in pseudo-randomness 

The image on the right is how the image might appear encrypted with CBC, CTR or any of the other more secure 

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.


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.


Cipher feedback (CFB) 

The cipher feedback (CFB) mode, a close relative of CBC, makes a block cipher into a self-synchronizing stream 

cipher. Operation is very similar; in particular, CFB decryption is almost identical to CBC encryption performed in 

reverse: 

This simplest way of using CFB described above is not any more self-synchronizing than other cipher modes like 

CBC. If a whole blocksize of ciphertext is lost both CBC and CFB will synchronize, but losing only a single byte or 

bit will permanently throw off decryption. To be able to synchronize after the loss of only a single byte or bit, a 

single byte or bit must be encrypted at a time. CFB can be used this way when combined with a shift register as the 

input for the block cipher. 

To use CFB to make a self-synchronizing stream cipher that will synchronize for any multiple of x bits lost, start by 

initializing a shift register the size of the block size with the initialization vector. This is encrypted with the block 

cipher, and the highest x bits of the result are XOR'ed with x bits of the plaintext to produce x bits of ciphertext. 

These x bits of output are shifted into the shift register, and the process repeats with the next x bits of plaintext. 

Decryption is similar, start with the initialization vector, encrypt, and XOR the high bits of the result with x bits of


the ciphertext to produce x bits of plaintext. Then shift the x bits of the ciphertext into the shift register. This way of 

proceeding is known as CFB-8 or CFB-1 (according to the size of the shifting). [16] 

In notation, where S i is the ith state of the shift register, a


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]


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.


Error propagation 

Before the widespread use of message authentication codes and authenticated encryption, it was common to discuss 

the "error propagation" properties as a selection criterion for a mode of operation. It might be observed, for example, 

that a one-block error in the transmitted ciphertext would result in a one-block error in the reconstructed plaintext for 

ECB mode encryption, while in CBC mode such an error would affect two blocks. 

Some felt that such resilience was desirable in the face of random errors (e.g., line noise), while others argued that 

error correcting increased the scope for attackers to maliciously tamper with a message. 

However, when proper integrity protection is used, such an error will result (with high probability) in the entire 

message being rejected. If resistance to random error is desirable, error-correcting codes should be applied to the 

ciphertext before transmission. 

Authenticated encryption 

A number of modes of operation have been designed to combine confidentiality and authentication in a single 

cryptographic primitive. Examples of such modes are XCBC, [23] IACBC, IAPM, [24] OCB, EAX, CWC, CCM, and 

GCM. Authenticated encryption modes are classified as single pass modes or double pass modes. Unfortunately for 

the cryptographic user community, many of the single pass authenticated encryption algorithms (such as OCB mode) 

are patent encumbered. 

In addition, some modes also allow for the authentication of unencrypted associated data, and these are called AEAD 

(Authenticated-Encryption with Associated-Data) schemes. For example, EAX mode is a double pass AEAD scheme 

while OCB mode is single pass. 

Other modes and other cryptographic primitives 

Many more modes of operation for block ciphers have been suggested. Some have been accepted, fully described 

(even standardized), and are in use. Others have been found insecure, and should never be used. Still others don't 

categorize as confidentiality, authenticity, or authenticated encryption - for example Key Feedback Mode (KFM) and 

AES-hash. 

NIST maintains a list of proposed modes for block ciphers at Modes Development [25] . [26][16] 

Disk encryption often uses special purpose modes specifically designed for the application. Tweakable narrow-block 

encryption modes (LRW, XEX, and XTS) and wide-block encryption modes (CMC and EME) are designed to 

securely encrypt sectors of a disk. (See disk encryption theory) 

Block ciphers can also be used in other cryptographic protocols. They are generally used in modes of operation 

similar to the block modes described here. As with all protocols, to be cryptographically secure, care must be taken 

to build them correctly. 

There are several schemes which use a block cipher to build a cryptographic hash function. See one-way 

compression function for descriptions of several such methods. 

Cryptographically secure pseudorandom number generators (CSPRNGs) can also be built using block ciphers. 

Message authentication codes (MACs) are often built from block ciphers. CBC-MAC, OMAC and PMAC are 

examples. 

Authenticated encryption also uses block ciphers as components. It means to both encrypt and MAC at the same 

time. That is to both provide confidentiality and authentication. IAPM, CCM, CWC, EAX, GCM and OCB are such 

authenticated encryption modes.


References 

[1] Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone (1996). Handbook of Applied Cryptography (http:/ / www. cacr. math. 

uwaterloo. ca/ hac/ ). CRC Press. ISBN 0-8493-8523-7. . 

[2] "Block Cipher Modes" (http:/ / csrc. nist. gov/ groups/ ST/ toolkit/ BCM/ index. html). NIST Computer Security Resource Center. . 

[3] "FIPS 81: DES Modes of Operation" (http:/ / www. itl. nist. gov/ fipspubs/ fip81. htm). NIST Computer Security Resource Center. . 

[4] http:/ / www. itl. nist. gov/ fipspubs/ fip81. htm 

[5] http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-38a/ sp800-38a. pdf 

[6] http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-38E/ nist-sp-800-38E. pdf 

[7] http:/ / csrc. nist. gov/ publications/ fips/ fips198/ fips-198a. pdf 

[8] http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-38B/ SP_800-38B. pdf 

[9] http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-38D/ SP-800-38D. pdf 

[10] http:/ / csrc. nist. gov/ publications/ nistpubs/ 800-38C/ SP800-38C_updated-July20_2007. pdf 

[11] B. Moeller (May 20, 2004), Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures (http:/ / www. openssl. org/ ~bodo/ 

tls-cbc. txt), 

[12] 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)


Certificate authority 

In cryptography, a certificate authority, or certification authority, (CA) is an entity that issues digital certificates. 

The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows 

others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public 

key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the 

subject (owner) of the certificate and the party relying upon the certificate. CAs are characteristic of many public key 

infrastructure (PKI) schemes. 

Commercial CAs charge to issue certificates that will automatically be trusted by most web browsers (Mozilla 

maintains a list of at least 36 trusted root CAs, though multiple commercial CAs or their resellers may share the 

same trusted root). [1] The number of web browsers and other devices and applications that trust a particular 

certificate authority is referred to as ubiquity. 

Aside from commercial CAs, some providers issue digital certificates to the public at no cost. Large institutions or 

government entities may have their own CAs. 

Domain Validation 

The commercial CAs that issue the bulk of certificates that clients trust for email servers and public HTTPS servers 

typically use a technique called "domain validation" to authenticate the recipient of the certificate. Domain validation 

involves sending an email containing an authentication token or link, to an email address that is known to be 

administratively responsible for the domain. This could be the technical contact email address listed in the domain's 

WHOIS entry, or an administrative email like postmaster@ or root@ the domain. The theory behind domain 

validation is that only the legitimate owner of a domain would be able to read emails sent to these administrative 

addresses. 

Domain validation suffers from certain structural security limitations. In particular, it is always vulnerable to attacks 

that allow an adversary to observe the domain validation emails that CAs send. These can include attacks against the 

DNS, TCP, or BGP protocols (which lack the cryptographic protections of TLS/SSL), or the compromise of routers. 

Such attacks are possible either on the network near a CA, or near the victim domain itself. 

Some Certificate Authorities offer Extended Validation (EV) certificates as a more rigorous alternative to domain 

validated certificates. One limitation of EV as solution to the weaknesses of domain validation is that attackers could 

still obtain a domain validated certificate for the victim domain, and deploy it during an attack; if that occurred, the 

only difference observable to the victim user would be a blue HTTPS address bar rather than a green one. Few users 

would be likely to recognise this difference as indicative of an attack being in progress. 

Domain validation implementations have also sometimes been a source of security vulnerabilities. In one instance, 

security researchers showed that attackers could obtain certificates for webmail sites because a CA was willing to 

use an email address like SSLCertificates@domain.com for domain.com, but not all webmail systems had 

reserved the "SSLCertificates" username to prevent attackers from registering it [2]. 

Issuing a certificate 

A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is 

not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a 

confirmation or validation by the CA that the public key contained in the certificate belongs to the person, 

organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to verify an 

applicant's credentials, so that users and relying parties can trust the information in the CA's certificates. CAs use a 

variety of standards and tests to do so. In essence, the Certificate Authority is responsible for saying "yes, this person 

is who they say they are, and we, the CA, verify that".


If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain public key does 

indeed belong to whoever is identified in the certificate. 

Example 

Public-key cryptography can be used to encrypt data communicated between two parties. This can typically happen 

when a user logs on to any site that implements the HTTP Secure protocol. In this example let us suppose that the 

user logs on to his bank's homepage www.bank.example to do online banking. When the user opens 

www.bank.example homepage, he receives a public key along with all the data that his web-browser displays. When 

the user enters some information to the bank's page and submits the page (sends the information back to the bank) 

then the data the user has entered to the page will be encrypted by his web browser using the public key that was 

issued by www.bank.example. The key that can be used to decrypt the information is called the private key and it is 

only known to the bank. Therefore, even if someone can access the (encrypted) data that was communicated from the 

user to www.bank.example, the (unencrypted) data that the user has entered can only be decrypted by the bank, as 

only the bank knows the private key. 

This mechanism is only safe if the user can be sure that it is the bank that he sees in his web browser. If the user 

types in www.bank.example, but his communication is hi-jacked and a fake web-site (that pretends to be the bank 

web-site) sends the page information back to the user's browser, the fake web-page can send a fake public key to the 

user. The user will fill the form with his personal data and will submit the page which will be encrypted by the fake 

public key. The fake web-page will get access to the user's data since the fake web-page owns the fake private key. 

A certificate authority is an organization that stores public keys and their owners and every party in a communication 

trusts this organization. When the user's web browser receives the public key from www.bank.example it can contact 

the certificate authority to ask whether the public key does really belong to www.bank.example. Since 

www.bank.example uses a public key that the certification authority certifies, a fake www.bank.example can only 

use the same public key. Since the fake www.bank.example does not know the corresponding private key, it cannot 

decrypt the user's answer. 

Subversion of CA 

If the CA can be subverted, then the security of the entire system is lost for each user for whom the CA is attesting a 

link between a public key and an identity. 

For example, suppose an attacker, Eve, manages to get a CA to issue to her a certificate that claims to represent 

Alice. That is, the certificate would publicly state that it represents Alice, and might include other information about 

Alice. Some of the information about Alice, such as her employer name, might be true, increasing the certificate's 

credibility. Eve, however, would have the all-important private key associated with the certificate. Eve could then 

use the certificate to send digitally signed email to Bob, tricking Bob into believing that the email was from Alice. 

Bob might even respond with encrypted email, believing that it could only be read by Alice, when Eve is actually 

able to decrypt it using the private key. 

A notable case of CA subversion like this occurred in 2001, when the certificate authority VeriSign issued two 

certificates to a person claiming to represent Microsoft. The certificates have the name "Microsoft Corporation", so 

could be used to spoof someone into believing that updates to Microsoft software came from Microsoft when they 

actually did not. The fraud was detected in early 2001. Microsoft and VeriSign took steps to limit the impact of the 

problem. [3][4] 

In 2011 fraudulent certificates were obtained from Comodo and DigiNotar [5][6] , allegedly by Iranian hackers. There 

is evidence that the fraudulent DigiNotar certificates were used in a man-in-the-middle attack in Iran. [7]



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 CA 2 , 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]


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 


• 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 XCBC BR2 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 OMAC1 IK3 , 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 (k 1 and k 2 ) using the following algorithm (this is equivalent to multiplication by x and 

x 2 in a finite field GF(2 b )). Let ≪ signify a standard left-shift operator: 

1. Calculate a temporary value k 0 = E k (0). 

2. If msb(k 0 ) = 0, then k 1 = k 0 ≪ 1, else k 1 = (k 0 ≪ 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(k 1 ) = 0, then k 2 = k 1 ≪ 1, else k 2 = (k 1 ≪ 1) ⊕ C. 

As a small example, suppose b = 4, C = 0011 2 , and k 0 = E k (0) = 0101 2 . Then k 1 = 1010 2 and k 2 = 0100 ⊕ 0011 = 

0111 2 .

CMAC 28 

The CMAC tag generation process is as follows: 

1. Divide message into b-bit blocks m = m 1 ∥ … ∥ m n−1 ∥ m n ′ where m 1 , …, m n−1 are complete blocks. (The empty 

message is treated as 1 incomplete block.) 

2. If m n ′ is a complete block then m n = k 1 ⊕ m n ′ else m n = k 2 ⊕ (m n ′∥ 10…0 2 ). 

3. Let c 0 = 00…0 2 . 

4. For i = 1,…, n, calculate c i = E k (c i−1 ⊕ m i ). 

5. Output t = msb ℓ (c n ). 

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] . 


• 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


Cryptographic hash function 

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: 

• it is easy (but not necessarily quick) 

to compute the hash value for any 

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 

A cryptographic hash function (specifically, SHA-1) at work. Note that even small 

changes in the source input (here in the word "over") drastically change the resulting 

output, by the so-called avalanche effect. 

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


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 n 20 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


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 

function built with the 

Merkle–Damgård construction is as 

The Merkle–Damgård hash construction. 

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.


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 2 69 hashing operations, rather than the 2 80 expected for a 160-bit hash 

function. In August 2005, another successful attack on SHA-1 was reported, finding collisions in 2 63 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.


Algorithm Output size (bits) Internal 

state size 

Block 

size 

Length 

size 

Word 

GOST 256 256 256 256 32 

size 

Collision attacks 

(complexity) 

HAVAL 256/224/192/160/128 256 1,024 64 32 Yes 

MD2 128 384 128 - 32 

MD4 128 128 512 64 32 

MD5 128 128 512 64 32 

PANAMA 256 8,736 256 - 32 Yes 

RadioGatún Up to 608/1,216 (19 

words) 

58 words 3 words - 1–64 

RIPEMD 128 128 512 64 32 

Preimage attacks 

(complexity) 

Yes ( 2 105 [12] ) Yes ( 2 192 [12] ) 

Yes ( 2 63.3 [13] ) Yes ( 2 73 [14] ) 

Yes ( 3 [15] ) Yes ( 2 70.4 [16] ) 

Yes ( 2 20.96 [17] ) Yes ( 2 123.4 [18] ) 

With flaws ( 2 352 or 

2 704 [19] ) 

Yes ( 2 18 [13] ) 

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 

SHA-1 160 160 512 64 32 

Yes ( 2 33.6 [20] ) 

Yes ( 2 51 [21] ) 

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 

No 

Yes ( 2 62 :19 [22] ) Yes ( 2 184.3 [16] ) 

WHIRLPOOL 512 512 512 256 8 No 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] Shai Halevi and Hugo Krawczyk, Randomized Hashing and Digital Signatures (http:/ / www. ee. technion. ac. il/ ~hugo/ rhash/ ) 

[11] NIST.gov - Computer Security Division - Computer Security Resource Center (http:/ / csrc. nist. gov/ groups/ ST/ hash/ sha-3/ index. html) 

[12] http:/ / www. springerlink. com/ content/ 2514122231284103/ 

[13] http:/ / www. springerlink. com/ content/ n5vrtdha97a2udkx/ 

[14] http:/ / eprint. iacr. org/ 2008/ 089. pdf 

[15] http:/ / www. springerlink. com/ content/ v6526284mu858v37/ 



[18] http:/ / springerlink. com/ content/ d7pm142n58853467/ 

[19] http:/ / eprint. iacr. org/ 2008/ 515 

[20] http:/ / www. springerlink. com/ content/ 3810jp9730369045/ 


[22] 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:

DiffieHellman key exchange 36 

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:


Alice Bob 

Secret Public Calculates Sends Calculates Public Secret 

a p, g p,g b 

a p, g, A g a mod p = A A p, g b 

a p, g, A B g b mod p = B p, g, A, B b 

a, s p, g, A, B B a mod p = s A b 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 = g a mod p 

• A = 5 6 mod 23 

• A = 15,625 mod 23 

• A = 8 

3. Bob chooses a secret integer b=15, then sends Alice B = g b mod p 

• B = 5 15 mod 23 

• B = 30,517,578,125 mod 23 

• B = 19 

4. Alice computes s = B a mod p 

• s = 19 6 mod 23 

• s = 47,045,881 mod 23 

• s = 2 

5. Bob computes s = A b mod p 

• s = 8 15 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 = 5 6*15 mod 23 

• s = 5 15*6 mod 23 

• s = 5 90 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 (g a ) b and (g b ) a are equal mod p. Note that only a, b and 

g ab = g ba mod p are kept secret. All the other values – p, g, g a mod p, and g b 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 g ab 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, g b mod p and g a 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 g a to Bob.


3. Bob picks a random natural number b and sends g b to Alice. 

4. Alice computes (g b ) a . 

5. Bob computes (g a ) b . 

Both Alice and Bob are now in possession of the group element g ab , which can serve as the shared secret key. The 

values of (g b ) a and (g a ) b are the same because groups are power associative. (See also exponentiation.) 

In order to decrypt a message m, sent as mg ab , Bob (or Alice) must first compute (g ab ) -1 , as follows: 

Bob knows |G|, b, and g a . A result from group theory establishes that from the construction of G, x |G| = 1 for all x in 

G. 

Bob then calculates (g a ) |G|-b = g a(|G|-b) = g a|G|-ab = g a|G| g -ab = (g |G| ) a g -ab =1 a g -ab =g -ab =(g ab ) -1 . 

When Alice sends Bob the encrypted message, mg ab , Bob applies (g ab ) -1 and recovers mg ab (g ab ) -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 = g a mod p = 8 

• Let b = Bob's private key. b = 15 

• Let B = Bob's public key. B = g b mod p = 19 

Alice 

knows doesn't know 

p = 23 b = ? 

base g = 5 

a = 6 

A = 5 6 mod 23 = 8 

B = 5 b mod 23 = 19 

s = 19 6 mod 23 = 2 

s = 8 b mod 23 = 2 

s = 19 6 mod 23 = 8 b mod 23 

s = 2 

Bob 


p = 23 a = ? 

base g = 5 

b = 15 

B = 5 15 mod 23 = 19 

A = 5 a mod 23 = 8 

s = 8 15 mod 23 = 2 

s = 19 a mod 23 = 2 

s = 8 15 mod 23 = 19 a mod 23 

s = 2 

Eve 


p = 23 a = ? 

base g = 5 b = ? 

A = 5 a mod 23 = 8 

B = 5 b mod 23 = 19 

s = 19 a mod 23 

s = 8 b mod 23 

s = 19 a mod 23 = 8 b mod 23 

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] 

s = ?


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 and . 

2. The parties generate their private keys, named , , and . 

3. Alice computes and sends it to Bob. 

4. Bob computes and sends it to Carol. 

5. Carol computes and uses it as her secret. 

6. Bob computes and sends it to Carol. 

7. Carol computes and sends it to Alice. 

8. Alice computes and uses it as her secret. 

9. Carol computes 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 participants (ending with its owner) and each participant 

has contributed to 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 ; this value is sent to E, F, G, and 

H. In return, participants A, B, C, and D receive . 

2. Participants A and B each perform one exponentiation, yielding , 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 , while B does the 

same to get ; again, C and D do similarly. 

5. Participants E through H simultaneously perform the same operations using as their starting point.


Upon completing this algorithm, all participants will possess the secret , but each participant will have 

performed only four modular exponentiations, rather than the eight implied by a simple circular arrangement. 


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 g ab . 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 g a 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) 


• 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)


• 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.


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 σ ≡ m d (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


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. A total break results in the recovery of the signing key. 

2. A universal forgery attack results in the ability to forge signatures for any message. 

3. A selective forgery attack results in a signature on a message of the adversary's choice. 

4. 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.


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


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.


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


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.


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=r e and the product s 1 s 2 of any two valid signatures s 1 , s 2 of m 1 , m 2 is a valid signature of the product 

m 1 m 2 . 

[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/ ).


Digital Signature Algorithm 

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 = g x 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 g x mod p, such as 

exponentiation by squaring.


Signing 

Let H be the hashing function and m the message: 

• Generate a random per-message value k where 0 < k < q 

• Calculate r = (g k 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 

k q−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 = ((g u1 ·y u2 ) 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 g q ≡ h p − 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


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/ ) 


• 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

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 

strength of the underlying hash 

SHA-1 HMAC Generation. 

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 

end if 

key = hash(key) // keys longer than blocksize are shortened 

if (length(key) < blocksize) then 

end if 

key = key ∥ [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded ('∥' is concatenation) 

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. 


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 


• 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 

Persistence · Compression · HTTPS 

HTTP 

Request methods 

OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT 

Cookie · ETag · Location · Referer 

DNT · X-Forwarded-For 

301 Moved permanently 

302 Found 

303 See Other 

403 Forbidden 

404 Not Found 

Header fields 

Status codes 

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.


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.


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]


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.


[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. . 


• 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

IPsec 62 

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

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] 

Offsets Octet 16 

Octet 16 

Bit 10 

Authentication Header format 

0 1 2 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 

0 0 Next Header Payload Len Reserved 

4 32 Security Parameters Index (SPI) 

8 64 Sequence Number 

C 96 Integrity Check Value (ICV) 

… … 

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] 

Offsets Octet 16 

Octet 16 

Bit 10 

Encapsulating Security Payload format 

0 1 2 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 

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 65 

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.

IPsec 66 

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]

IPsec 67 

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/ )

IPsec 68 


• 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

IPsec 69 

• 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


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).


• 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 

1. A user enters a username and password on the client machine. 

Kerberos negotiations 

2. The client performs a one-way function (hash usually) on the entered password, and this becomes the secret key 

of the client/user.


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.


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] http:/ / web. mit. edu/ kerberos/ 

[2] RFC 4556, abstract 

[3] http:/ / web. mit. edu/ Kerberos/ krb5-1. 5/ krb5-1. 5. 4/ doc/ krb5-admin/ Clock-Skew. html 

[4] 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)



• 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/ ) 

Key distribution center 

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.

Key distribution center 75 

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 


• Kerberos 5 KDC operation [1] 

References 

[1] http:/ / www. zeroshell. net/ eng/ kerberos/ Kerberos-operation/


Message authentication code 

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. 


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.


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.



• 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 

• K AS is a symmetric key known only to A and S 

• K BS is a symmetric key known only to B and S 

• N A and N B are nonces generated by A and B respectively 

• K AB 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 K AB , 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 

The public-key protocol 

which the attacker can't forge since she does not have . 

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: 

• K PA and K SA , respectively public and private halves of an encryption key-pair belonging to A 

• K PB and K SB , similar belonging to B 

• K PS and K SS , similar belonging to S. (Note this has the property that K SS is used to encrypt and K PS to decrypt). 

The protocol runs as follows: 

A requests B's public keys from S


S responds with public key K PB alongside B's identity, signed by the server for authentication purposes. 

A invents N A and sends it to B. 

B requests A's public keys. 

Server responds. 

B invents N B , and sends it to A along with N A to prove ability to decrypt with K SB . 

A confirms N B to B, to prove ability to decrypt with K SA 

At the end of the protocol, A and B know each other's identities, and know both N A and N B . 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 N A to I, who decrypts the message with K SI 

I relays the message to B, pretending that A is communicating 

B sends N B 

I relays it to A 

A decrypts N B and confirms it to I, who learns it 

I re-encrypts N B , 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 N A and N B are known only to 

A and B.


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 


• 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


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


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.


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.


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).


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.


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


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] Schneier, Bruce (1995-10-09). Applied Cryptography. New York: Wiley. p. 587. ISBN 0471117099. 

[2] Nichols, Randall (1999). ICSA Guide to Cryptography. McGrawHill. p. 267. ISBN 0079137598. 

[3] "United States v. Scarfo (Key-Logger Case)" (http:/ / www. epic. org/ crypto/ scarfo. html). Epic.org. . Retrieved 2010-02-08. 

[4] 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)



• 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. 


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/ )


Public key certificate 

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. 

Similarly, Microsoft Windows 2000 Server and Windows Server 

Diagram of an example usage of digital certificate 

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;


(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.


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.


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] Ran Canetti: Universally Composable Signature, Certification, and Authentication. CSFW 2004, http:/ / eprint. iacr. org/ 2003/ 239 

[2] http:/ / www. openssl. org/ docs/ apps/ ca. html 

[3] OpenSSL: Documentation ca(1) (http:/ / www. openssl. org/ docs/ apps/ ca. html) 

[4] VeriSign Class definitions (https:/ / www. verisign. com/ support/ roots. html) 

[5] "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. 


• 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 

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 

carried out by software at a CA, or under 

human supervision. The PKI role that 

Diagram of a public key infrastructure 

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.


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:


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


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



• 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 

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 

other; not all asymmetric key algorithms do. Those 

with this property are particularly useful and have been 

widely deployed, and are the source of the commonly 

used name. The public key is used to transform a 

In an asymmetric key encryption scheme, anyone can encrypt 

messages using the public key, but only the holder of the paired 

private key can decrypt. Security depends on the secrecy of that 

private key. 

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 --


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. 

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 

same as the key used to decrypt it. Each user has a pair 

of cryptographic keys — a public encryption key and 

a private decryption key. The publicly available 

encrypting-key is widely distributed, while the private 

decrypting-key is known only to the recipient. 

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. 

In the Diffie–Hellman key exchange scheme, each party generates a 

public/private key pair and distributes the public key... After 

obtaining an authentic copy of each other's public keys, Alice and 

Bob can compute a shared secret offline. The shared secret can be 

used, for instance, as the key for a symmetric cipher. 

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


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. 


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.


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 E 1 () and E 2 () be two encryption 

functions and let "M" be the message so if Alice encrypts it using E 1 () and sends E 1 (M) to Bob. Bob then again 

encrypts the message as E 2 (E 1 (M)) and sends it to Alice. Now Alice Decrypts E 2 (E 1 (M)) using E 1 (). She'll 

now get E 2 (M), meaning when she sends this again to Bob, he will be able to decrypt the message using E 2 () 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.


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


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.


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.


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.


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.



• 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)


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.


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 

least one terminal having a decoding device. A 

message-to-be-transferred is enciphered to ciphertext at the 

Adi Shamir, one of the authors of RSA: Rivest, 

Shamir and Adleman 

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. 


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


• 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 by using an agreed-upon reversible protocol known as a 

padding scheme. He then computes the ciphertext 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 more efficiently as follows: 

• 

• 

• (if 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.


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 . 

2. Compute giving 

n = 61 · 53 = 3233. 

3. Compute the totient of the product as giving 

. 

4. Choose any number that is coprime to 3120. Choosing a prime number for leaves us only to 

check that is not a divisor of 3120. 

Let . 

5. Compute , 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)


Attacks against plain RSA 

There are a number of attacks against plain RSA as described below. 

• When encrypting with low encryption exponents (e.g., ) and small values of the , (i.e. ) 

the result of is strictly less than the modulus . 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 may 

ask the holder of the private key to decrypt an unsuspicious-looking ciphertext for some 

value chosen by the attacker. Because of the multiplicative property is the encryption of . 

Hence, if the attacker is successful with the attack, he will learn from which he can derive the 

message m by multiplying with the modular inverse of modulo . 

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).


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 . With the ability to recover prime 

factors, an attacker can compute the secret exponent from a public key , then decrypt using the standard 

procedure. To accomplish this, an attacker factors into and , and computes which allows 

the determination of from . 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.



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 2n 1/4 (which for even small 1024-bit values of n is 3×10 77 ) 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 < n 1/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 and so the effect of can be 

removed by multiplying by its inverse. A new value of 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.


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 (m e ) 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 m ed 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 m ed m mod p, we consider two cases: m 0 mod p and m 0 mod 

p. In the first case m ed is a multiple of p, so m ed 0 m mod p. In the second case 

where we used Fermat's little theorem to replace m p-1 mod p with 1. 

The verification that m ed m mod q proceeds in a similar way, treating separately the cases m 0 mod q and m 

0 mod q, using Fermat's little theorem for modulus q in the second case. 

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 m ed 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,


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 m ed 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. 


• 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)


• 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.

S/MIME 119 

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

S/MIME 120 

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. 


• 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] RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One was published in November 1996 

[2] http:/ / www. penango. com/ 

[3] http:/ / datatracker. ietf. org/ doc/ rfc5751/ 

[4] http:/ / yplakosh. blogspot. com/ 2008/ 10/ how-to-secure-email-using-smime. html


Secure Electronic Transaction 

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


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.


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.


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.


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)


• 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 

• 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) 

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. 

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


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. 

• The user authentication layer (RFC 4252). This 

Diagram of the SSH-2 binary packet. 

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


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] Network Working Group of the IETF, January 2006, RFC 4252, The Secure Shell (SSH) Authentication Protocol 

[2] SSH Hardens the Secure Shell (http:/ / www. serverwatch. com/ news/ print. php/ 3551081), Serverwatch.com 

[3] SSH setup manual (http:/ / wiki. qnap. com/ wiki/ How_To_Set_Up_Authorized_Keys) 

[4] 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 


• 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.



• 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 (telecommunication) 

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] [3] [4] 

are technically aligned. This model is widely recognized 

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


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] : 


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 

Access control 

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. 

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


Data integrity 

This service provides for the protection of the information which might be derived from observation of 

traffic flows. 

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 

Non-repudiation 

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. 

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


Illustration of relationship of security services and mechanisms 

Service Mechanism 

Encipherment Digital 

signature 

Access 

control 

Data 

integrity 


exchange 

Traffic 

padding 

Routing 

control 

Peer entity authentication Y Y · · Y · · · 

Data origin authentication Y Y · · · · · · 

Access control service · · Y · · · · · 

Connection confidentiality 

Connectionless 

confidentiality 

Selective field 

confidentiality 

Y . · · · · Y · 

Y · · · · · Y · 

Y · · · · · · · 

Traffic flow confidentiality Y · · · · Y Y · 

Connection Integrity with 

recovery 

Connection 

integritywithout recovery 

Selective field connection 

integrity 

Y · · Y · · · · 

Y · · Y · · · · 

Y · · Y · · · · 

Connectionless integrity Y Y · Y · · · · 

Selective field 

connectionless integrity 

Y Y · Y · · · · 

Non-repudiation. Origin · Y · Y · · · Y 

Non-repudiation. Delivery Y · Y · · · Y 

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* 

Peer entity authentication · · Y Y · · Y 

Data origen authentication · · Y Y · · Y 

Access control service · · Y Y · · Y 

Connection confidentiality Y Y Y Y · Y Y 

Connectionless confidentiality · Y Y Y · Y Y 

Selective field confidentiality · · · · · Y Y 

Traffic flow confidentiality Y · Y · · · Y 

Connection Integrity with recovery · · · Y · · Y 

Connection integrity without recovery · · Y Y · · Y 

Selective field connection integrity · · · · · · Y 

Notarization


Other related meanings 

Managed Security Service 

Connectionless integrity · · Y Y · · Y 

Selective field connectionless integrity · · · · · · Y 

Non-repudiation Origin · · · · · · Y 

Non-repudiation. Delivery · · · · · · Y 

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 


• 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 


A 2008 attack by Stéphane Manuel breaks the hash function, as it can produce hash collisions with a complexity of 2 51 operations. [1] 

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. 

Comparison of SHA functions 

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; 

n denotes a left bit rotation by n places; 

n varies for each operation; 

W t is the expanded message word of round t; 

K t is the round constant of round t; 

denotes addition modulo 2 32 . 

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) 

SHA-0 160 160 512 

SHA-1 

SHA-2 SHA-256/224 256/224 256 512 

SHA-512/384 512/384 512 1024 

Max 

message 

size (bits) 

2 64 − 1 

2 64 − 1 

2 128 − 1 

Word 

size 

(bits) 

Rounds Operations Collisions 

32 80 add, and, or, xor, rotate, 

mod 

32 64 add, and, or, xor, shift, 

64 80 

rotate, mod 

found? 

Yes 

Theoretical attack 

(2 51 ) [5] 

No

SHA-1 136 

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 2 L 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 2 L/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 2 80 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).

SHA-1 137 

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 2 61 , fewer than the 2 80 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 2 51 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 

2 40 , 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 2 39 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 2 80 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 2 69 operations. (A brute-force search would require 

2 80 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 2 33 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 2 63 . [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 2 35 compression 

function evaluations. As this attack requires the equivalent of about 2 35 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]

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 2 51 to 2 57 operations. [27] 

Cameron McDonald, Philip Hawkes and Josef Pieprzyk presented a hash collision attack with claimed complexity 

2 52 at the Rump session of Eurocrypt 2009. [28] However, the accompanying paper, "Differential Path for SHA-1 

with complexity O(2 52 )" 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 2 57.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 2 32 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 

Main loop: [32] 

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 2 30 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 ≤ i ≤ 19): f = d xor (b and (c xor d)) (alternative 1) 

(0 ≤ i ≤ 19): f = (b and c) xor ((not b) and d) (alternative 2) 

(0 ≤ i ≤ 19): f = (b and c) + ((not b) and d) (alternative 3) 

(0 ≤ i ≤ 19): f = vec_sel(d, c, b) (alternative 4) 

(40 ≤ i ≤ 59): f = (b and c) or (d and (b or c)) (alternative 1) 

(40 ≤ i ≤ 59): f = (b and c) or (d and (b xor c)) (alternative 2) 

(40 ≤ i ≤ 59): f = (b and c) + (d and (b xor c)) (alternative 3) 

(40 ≤ i ≤ 59): f = (b and c) xor (b and d) xor (c and d) (alternative 4) 

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 141 

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)

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. 


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 

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 pseudorandom keystream is typically 

generated serially from a random seed value 

using digital shift registers. The seed value 

serves as the cryptographic key for decrypting the ciphertext stream. 

The operation of the keystream generator in A5/1, a LFSR-based stream 

cipher used to encrypt mobile phone conversations. 

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.


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.


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. 

An alternating step generator comprises three linear feedback shift 

registers, which we will call LFSR0, LFSR1 and LFSR2 for 

One approach is to use n LFSRs in parallel, their 

outputs combined using an n-input binary 

Boolean function (F). 

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.


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. 


Main article: Stream cipher attack 

For a stream cipher to be secure, its keystream 

must have a large period and it must be 

RC4 is one of the most widely used stream cipher designs. 

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 2 32 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 2 32 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).


A5/1 

A5/2 

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 

Achterbahn-128/80 

Creation 

Date 

Speed 

(cycles per byte) 

Effective 

Key-Length 

(bits) Attack 

Initialization 

vector 

Internal 

State 

Best Known Computational 

Complexity 

1989 Voice (W phone ) 54 114 64 Active KPA OR 

KPA Time-Memory Tradeoff 

~2 seconds OR 

2 39.91 

1989 Voice (W phone ) 54 114 64? Active 4.6 

milliseconds 

2006 1 (hardware) 80/128 80/128 297/351 Brute force for frame lengths 

L ≤ 2 44 . Correlation attack for 

L ≥ 2 48 [1] . 

FISH 1993 Quite Fast (W soft ) Variable ? ? Known-plaintext attack 

Grain Pre-2004 Fast 80 64 160 Key-Derivation 

2 80 resp. 2 128 

for L ≤ 2 44 . 

HC-256 Pre-2004 4 (W P4 ) 256 256 65536 ? ? 

ISAAC 

1996 2.375 (W 64-bit ) - 

4.6875 (W 32-bit ) 

8-8288 

usually 

40-256 

N/A 8288 (2006) First-round 

Weak-Internal-State-Derivation 

MUGI 1998–2002 ? 128 128 1216 N/A (2002) 

PANAMA 1998 2 256 128? 1216? Hash Collisions (2001) 

Phelix 

Pre-2004 up to 8 (W x86 ) 256 + a 

128-bit 

Nonce 

128? ? Differential (2006) 

2 11 

2 43 

4.67×10 1240 

Pike 1994 0.9 x FISH (W soft ) Variable ? ? N/A (2004) N/A (2004) 

Py 

Pre-2004 2.6 8-2048? 

usually 

40-256? 

64 8320 Cryptanalytic Theory (2006) 

Rabbit 2003-Feb 3.7(W P3 )-9.7(W ARM7 ) 128 64 512 N/A (2006) N/A (2006) 

RC4 

Salsa20 

Scream 

1987 

Pre-2004 4.24 (W G4 ) - 

11.84 (W P4 ) 

[2] 

7 W 

8-2048 

P5 

usually 

40-256 

2002 4 - 5 (W soft ) 128 + a 

128-bit 

Nonce 

256 a 64-bit 

Nonce + a 

64-bit stream 

position 

8 2064 Shamir Initial-Bytes 

Key-Derivation OR KPA 

32? 64-bit 

round 

function 

512 Probabilistic neutral bits 

method 

(2001) 

~2 82 

2 82 

2 37 

2 75 

2 13 OR 2 33 

2 251 for 8 

rounds (2007) 

? ? 

SEAL 1997 Very Fast (W 32-bit ) ? 32? ? ? ?


SNOW Pre-2003 Very Good (W 32-bit ) 128 OR 256 32 ? ? ? 

SOBER-128 2003 ? up to 128 ? ? Message Forge 

SOSEMANUK Pre-2004 Very Good (W 32-bit ) 128 128 ? ? ? 

Trivium Pre-2004 4 (W x86 ) - 8 (W LG ) 80 80 288 Brute force attack (2006) 

Turing 2000–2003 5.5 (W x86 ) ? 160 ? ? ? 

VEST 

2005 42 (W ASIC ) - 

64 (W FPGA ) 

Variable 

usually 

80-256 

Variable 

usually 

80-256 

256 - 

800 

2 −6 

2 135 

N/A (2006) N/A (2006) 

WAKE 1993 Fast ? ? 8192 CPA & CCA Vulnerable 

Stream 

Cipher 

Trivia 

Creation 

Date 

Speed 

(cycles per byte) 

Effective 

Key-Length 

(bits) Attack 

Initialization 

vector 

Internal 

State 

Best Known Computational 

Complexity 

• 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. 


• 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 algorithm 

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. 


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.



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 

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.


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.


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.



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.


• 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.


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.


• 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. 

• The client performs the same decryption and verification. 


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. 

• The client performs the same decryption and verification.



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. 

Content type 

Version 

+ Byte +0 Byte +1 Byte +2 Byte +3 

Byte 

0 

Bytes 

1..4 

Bytes 

5..(m-1) 

Bytes 

m..(p-1) 

Bytes 

p..(q-1) 

Content type 

Version Length 

(Major) (Minor) (bits 15..8) (bits 7..0) 

Protocol message(s) 

MAC (optional) 

Padding (block ciphers only) 

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 

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.


Length 

Major 

Version 

Versions 

Minor 

Version 

Version Type 

3 0 SSL 3.0 

3 1 TLS 1.0 

3 2 TLS 1.1 

3 3 TLS 1.2 

The length of Protocol message(s), not to exceed 2 14 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). 

Message type 


Byte 

0 

Bytes 

1..4 

Bytes 

5..8 

Bytes 

9..(n-1) 

Bytes 

n..(n+3) 

Bytes 

(n+4).. 

This field identifies the Handshake message type. 

22 



Message type Handshake message data length 

(bits 23..16) (bits 15..8) (bits 7..0) 

Handshake message data 

Message type Handshake message data length 

(bits 23..16) (bits 15..8) (bits 7..0) 

Handshake message data


Handshake message data length 

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). 

Level 


Byte 

0 

Bytes 

1..4 

Bytes 

5..6 

Bytes 

7..(p-1) 

Bytes 

p..(q-1) 

21 


(Major) (Minor) 0 2 

Level Description 



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


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). 

Description 

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. 

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 

44 Certificate revoked warning/fatal 

client certificate 

45 Certificate expired warning/fatal Check server certificate expire also check no certificate in the chain presented has 

46 Certificate unknown warning/fatal 

47 Illegal parameter fatal 

48 Unknown CA (Certificate 

authority) 

expired 

fatal TLS only 

49 Access denied fatal TLS only - E.g. no client certificate has been presented (TLS: Blank certificate 

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 

message or SSLv3: No Certificate alert), but server is configured to require one.


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) 

ChangeCipherSpec protocol 

CCS protocol type 

Currently only 1. 

Application protocol 

Length 

MAC 

Padding 

fatal TLS only 


Byte 

0 

Bytes 

1..4 

Byte 

5 

20 


(Major) (Minor) 0 1 

CCS protocol type 


Byte 

0 

Bytes 

1..4 

Bytes 

5..(m-1) 

Bytes 

m..(p-1) 

Bytes 

p..(q-1) 

23 



Application data 



Length of Application data (excluding the protocol header and including the MAC and padding trailers) 

20 bytes for the SHA-1-based HMAC, 16 bytes for the MD5-based HMAC. 

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. 


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]


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”.


• 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.


[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). . 



• 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



• 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.

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, 

Validity 

OU=Certification Services Division, 

CN=Thawte Server CA/emailAddress=server-certs@thawte.com 

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/emailAddress=baccala@freesoft.org

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. 


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 172 

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]

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] All About Certificate Extensions (http:/ / www. mozilla. org/ projects/ security/ pki/ nss/ tech-notes/ tn3. html) 

[3] Top 10 PKI risks (http:/ / hackerproof. org/ technotes/ pki/ pki_risks. pdf) 

[4] Peter Gutmann, PKI: it's not dead, just resting (http:/ / ieeexplore. ieee. org/ xpl/ freeabs_all. jsp?arnumber=1023787) 

[5] 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 2 52 (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 174 


• 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


Article Sources and Contributors 

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, Ali@gwc.org.uk, 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, Jonathan.lampe@standardnetworks.com, 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, Ali@gwc.org.uk, 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, Victor871129@hotmail.com, 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, Aalsheb@hotmail.com, 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,


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, Jonathan.lampe@standardnetworks.com, 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,


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, D.j.potts@bcs.org.uk, 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,


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, Baccala@freesoft.org, 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

Image Sources, Licenses and Contributors 179 

Image Sources, Licenses and Contributors 

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

License 180 

License 

Creative Commons Attribution-Share Alike 3.0 Unported 

//creativecommons.org/licenses/by-sa/3.0/

Security Articles from Wikipedia

Create successful ePaper yourself

Delete template?

Save as template?