Global Information Assurance Certification Paper - GIAC Certifications
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Global Information Assurance Certification Paper
Copyright SANS Institute
Author Retains Full Rights
This paper is taken from the GIAC directory of certified professionals. Reposting is not permited without express written permission.
Interested in learning more?
Check out the list of upcoming events offering
"Security Essentials Bootcamp Style (Security 401)"
at http://www.giac.org/registration/gsecThe Advanced Encryption Standard: A Review of the Finalists
Kathleen Flood
October 9, 2000
On the second of October 2000 the National Institute of Standards and Technology (NIST) of the U.S. Department of
Commerce announced the selection for the new encryption standard, the Advanced Encryption Standard, as the
replacement for the Data Encryption Standard (DES). For more than two decades, DES has been the cryptographic
algorithm used to protect the "sensitive" U.S. government communications. Although the Triple DES algorithm
provides a stronger encryption than DES, it does so with a reduction in performance and an increased cost of
s.
implementation. NIST identified the need to select a new "faster, cheaper, better" standard that would provide greater
ht
security well into the twenty-first century. This paper will briefly review the history of the AES, the five finalists’
rig
algorithms, and the NIST’s evaluation and selection of the new proposed standard.
Background
ull
NIST announced its intention to seek a replacement for DES in January 1997, and in September of the same year it
f
ins
made the formal call for algorithms. As noted in the call for algorithms, the submissions had to be symmetric key
block cipher algorithms supporting
Key fingerprint keyFA27
= AF19 sizes2F94
of 128, 192,FDB5
998D and 256
DE3Dbits F8B5
and block
06E4sizes
A169of4E46
128 bits in order to be
eta
considered for further evaluation. Once having met those requirements, the algorithms would be evaluated based on
security, licensing requirements, computational efficiency, memory requirements, flexibility, hardware and software
suitability, and simplicity. It was hoped that the collaborative effort of academia, industry, cryptography community,
rr
and the U.S. government would provide the amount of international exposure, scrutiny, and cryptanalysis necessary
ho
to ensure the strength of the selection and to uncover possible weaknesses. The first round of evaluation and
analysis of the 15 initial proposals began in August 1998. The five finalists were announced by NIST in August 1999.
The Finalists
A ut
5,
The NIST noted that it was difficult to measure and compare the security of the algorithms but an attempt was made
to do so using simplified variants of the actual algorithms with unit of measurement being a security margin.
00
According to the Technical Details of the Round 2 Analysis as presented in NIST’s Report "In general, the results will
-2
be biased against algorithms that attract greater scrutiny in a limited analysis period. This could plausibly occur, for
example, if a particular algorithm is simpler, or at least appears to be simpler, to analyze against certain attacks.
00
Another factor could be the ancestry of the algorithm and its constituent techniques, and the existence of previous
attacks upon which to build. The proposed measure would tend to favor novel techniques for resisting attacks,
20
techniques that have not yet stood the test of time." [NIST] Even though NIST found that all five finalists had
"adequate security for the AES", three algorithms, MARS, Serpent, and Twofish, were noted as having a high security
te
margin.
tu
MARS
sti
This algorithm was submitted by a team from IBM, the developers of Lucifer, which with input from the National
In
Security Agency became the original DES. As noted in IBM’s submission paper, "It is designed to take advantage of
the powerful operations supported in today's computers, resulting in a much improved security/performance tradeoff
NS
over existing ciphers. As a result, MARS offers better security than triple DES while running significantly faster than
single DES. The key for MARS may be from 4 to 39 words in length." [IBM] The algorithm used a pre-whitening key
SA
addition, rounds (iterations) of keyed transformations, rounds of unkeyed mixing which used S-boxes (substitution
tables), addition, and an XOR operation, and finally a post-whitening key subtraction.
©
In the NIST’s assessment of MARS, it found that in the software implementation on the various platforms (8-bit, 32-
bit, 64-bit processors and digital signal processors), the algorithm achieved average speed performance, in all three
key sizes, for encryption and decryption functions and for key setup. In restricted-space environments, that is,
environments with limited ROM and RAM, MARS had greater resource requirements, particularly for ROM, which
could presentKeya problem for an
fingerprint application
= AF19 FA27such
2F94as998D
a smart
FDB5card. In terms
DE3D F8B5of06E4
the performance
A169 4E46in a hardware
implementation, MARS was assessed to have an above average area requirement and a below average throughput,
yielding a below average efficiency. Efficiency was computed as [Throughput / Area]. Since MARS’ encryption and
decryption functions were similar, there was no significant difference between those functions in their speed and
space used. MARS’ subkey computation and storage created additional resource demands, an issue in memory-
restricted environments. To its credit, MARS has the flexibility to support a wide range of key sizes, from 128 to 448
bits.
© SANS Institute 2000 - 2005 Author retains full rights.RC6
The RC6 algorithm was submitted by the RSA Laboratories. In the abstract of its submission paper, RSA stated that
"RC6 is an evolutionary improvement of RC5, designed to meet the requirements of the Advanced Encryption
Standard (AES). [It] makes essential use of data-dependent rotations, […] four working registers instead of two, and
the inclusion of integer multiplication as an additional primitive operation. The use of multiplication greatly increases
the diffusion achieved per round, allowing for greater security, fewer rounds, and increased throughput." [RSA]
The NIST found that RC6’s performance to be above average in encryption and decryption speed for 128-bit keys
(notably well in 32-bit platforms), average for key setup speed, and consistent for all three key sizes. RC6 had a low
s.
ROM requirement but a high RAM requirement since it did not have an on-the-fly subkey computation for the
decryption process. Its throughput in a hardware implementation was found to be average, and not dependent upon
ht
the key size. As with MARS, the encryption and decryption processes for RC6 were similar enough to require no
rig
significant additional area and speed for implementation. As noted above, on-the-fly subkey computation for
decryption was not supported, but was supported for encryption. The parameter characteristics of the algorithm
ull
support key sizes larger than 256 bits.
f
Serpent
ins
This algorithmKey wasfingerprint
designed =byAF19
Ross FA27
Anderson,
2F94Eli Biham,
998D FDB5andDE3D
Lars Knudsen.
F8B5 06E4 In explaining
A169 4E46 their design philosophy,
eta
the international Serpent team noted, "Its design is highly conservative, yet still allows a very efficient implementation.
It uses S-boxes similar to those of DES in a new structure that simultaneously allows a more rapid avalanche, a more
rr
efficient bitslice implementation, and an easy analysis that enables us to demonstrate its security against all known
types of attack. …We did not feel it appropriate to use novel and untested ideas in a cipher which, if accepted after a
ho
short review period, will be used to protect enormous volumes of financial transactions, health records and
government information over a period of decades." [ABK] The algorithm used an initial permutation, followed by 32
ut
rounds each consisting of a keyed mixing, an S-box pass, and a linear transformation, followed by a final
A
permutation.
5,
In the NIST’s software implementation tests, the Serpent algorithm had the slowest speed for encryption and
00
decryption for 128-bit keys, with a consistent performance for all three key sizes. However, Serpent had an average
key setup speed. Its implementation had low ROM and RAM requirements, making it favorable for restricted-space
-2
environments. Despite its slower performance in software implementation, Serpent was found to have the highest
throughput in hardware in non-feedback mode, and second best in feedback mode. In addition, its efficiency was
00
determined to be very good. Although the algorithm’s speed did not vary much between the encryption and
decryption process, the two processes were quite different, sharing very few hardware resources. Serpent supported
20
on-the-fly subkey computation for encryption and decryption and supported key sizes up to 256 bits.
te
Twofish
tu
A team from Counterpane Systems, Hi/fn, and University of California Berkeley submitted the Twofish algorithm.
sti
Echoing the Serpent team’s view of conservative design, the Twofish team explained, "We used well-studied design
In
elements throughout the algorithm. We started with a Feistel networks, probably the most studied block cipher
structure, instead of something newer. …Complicated round functions are harder to analyze and rely on more ad-hoc
NS
arguments for security. …In Twofish, we tried to create a simple round function and then iterate it more than enough
times for security." [SKW] The algorithm used a Feistel structure composed of key-dependent S-boxes, a fixed
SA
maximum distance matrix, a pseudo-Hadamard transform, and bitwise rotations.
In software implementation testing, NIST noted that Twofish had generally average speed for encryption and
©
decryption for 128-bit keys, although the results were mixed across platforms. Its key setup speed was slower, with
performance degrading with increased key sizes. Due to its low ROM and RAM requirements, the algorithm was
found to be suitable for restricted-space environments. In hardware implementation testing, Twofish had average
throughput and efficiency. Since the encryption and decryption functions were very similar, its efficiency was not
greatly effected. The algorithm demonstrated key agility by supporting on-the-fly subkey computation for both
encryption and decryption.
Key It also
fingerprint supported
= AF19 variable
FA27 2F94 998DkeyFDB5
sizes up to 256
DE3D bits.06E4 A169 4E46
F8B5
And the winner is…
The Rijndael algorithm was designed by Joan Daemen and Vincent Rijmen. The Dutch team noted in their discussion
of the design rationale, three criteria: "Resistance against all known attacks; Speed and code compactness on a wide
range of platforms; Design simplicity." [DR] They also gave credit to another block cipher, Square, as an influence for
Rijndael’s design. In the algorithm each regular round involved four steps or layers. The first layer was a byte-
© SANS Institute 2000 - 2005 Author retains full rights.oriented S-box pass. The next layer involved shifting rows of the array, followed by a layer in which the columns
were mixed using a matrix multiplication. In the final layer the subkey addition was applied to the array. The extra
final round omitted the Mix Column step, but was otherwise the same as a regular round.
The following pseudo C notation describing a round was provided in the submission paper:
Round(State,RoundKey)
{
s.
ByteSub(State);
ht
ShiftRow(State);
rig
MixColumn(State);
ull
AddRoundKey(State,RoundKey);
f
ins
}
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
eta
The pseudo notation for the Rijndael cipher:
rr
Rijndael(State,CipherKey)
ho
{
ut
KeyExpansion(CipherKey,ExpandedKey) ; A
AddRoundKey(State,ExpandedKey);
5,
00
For( i=1 ; i[DR] Daemen, J.,Rijmen, V. "AES Proposal: Rijndael", version 2. 9 March 1999. URL:
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/ (3 October 2000).
[IBM] Burwick, C., Coppersmith, D., et al. "MARS – a candidate cipher for AES" 20 August 1999. URL:
http://www.research.ibm.com/security/mars.html (3 October 2000).
[NIST] National Institute of Standards and Technology, U.S. Department of Commerce. "Report on the Development
of the Advanced Encryption Standard (AES)." Advanced Encryption Standard (AES) Development Effort. 2 October
2000. URL: http://csrc.nist.gov/encryption/aes/ (3 October 2000).
s.
[RSA] Rivest, R., Robshaw, M., et al. "The RC6[tm] Block Cipher". June 1998. URL:
ht
http://www.rsasecurity.com/rsalabs/aes/index.html (3 October 2000).
rig
[SKW] Schneier, B., Kelsey, J. , et al. "Twofish: A 128-Bit Block Cipher". 15 June 1998. URL:
http://www.counterpane.com/twofish-paper.html (3 October 2000).
ull
National Institute of Standards and Technology, U.S. Department of Commerce. "Announcing Request for Candidate
f
Algorithm Nominations for the Advanced Encryption Standard (AES)." Federal Register, Volume 62, Number 177. 12
ins
September 1997. URL: http://csrc.nist.gov/encryption/aes/pre-round1/aes_9709.htm (7 October 2000)
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
eta
National Institute of Standards and Technology, U.S. Department of Commerce. "Overview of the AES Development
Effort." )." Advanced Encryption Standard (AES) Development Effort. August 1999. URL:
rr
http://csrc.nist.gov/encryption/aes/ (3 October 2000)
ho
National Security Agency. "Hardware Performance Simulations of Round 2 Advanced Encryption Standard
Algorithms." Round 2 Analysis. 15 May 2000. URL: http://csrc.nist.gov/encryption/aes/round2/r2anlsys.htm
(3 October 2000). A ut
Seifried, K. "Advanced Encryption Standard Released", 3 October 2000. URL:
5,
http://securityportal.com/articles/aes20001003.html (3 October 2000).
00
Savard, J. "Towards the 128-bit Era: AES Candidates." A Cryptographic Compendium. URL:
-2
http://home.ecn.ab.ca/~jsavard/crypto.htm (4 October 2000).
00
20
te
tu
sti
In
NS
SA
©
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
© SANS Institute 2000 - 2005 Author retains full rights.Last Updated: January 7th, 2021
Upcoming Training
SANS Security East 2021 , Jan 11, 2021 - Jan 16, 2021 CyberCon
SANS Security Fundamentals 2021 , Netherlands Jan 18, 2021 - Jan 29, 2021 CyberCon
Cyber Threat Intelligence Summit & Training 2021 Virtual - US Eastern, Jan 21, 2021 - Feb 01, 2021 CyberCon
SANS Cyber Security West: Feb 2021 , Feb 01, 2021 - Feb 06, 2021 CyberCon
Open-Source Intelligence Summit & Training 2021 Virtual - US Eastern, Feb 08, 2021 - Feb 23, 2021 CyberCon
SANS Essentials Australia 2021 - Live Online , Australia Feb 15, 2021 - Feb 20, 2021 CyberCon
SANS Essentials Australia 2021 Melbourne, Australia Feb 15, 2021 - Feb 20, 2021 Live Event
SANS London February 2021 , United Kingdom Feb 22, 2021 - Feb 27, 2021 CyberCon
SANS Secure Japan 2021 , Japan Feb 22, 2021 - Mar 13, 2021 CyberCon
SANS Scottsdale: Virtual Edition 2021 , Feb 22, 2021 - Feb 27, 2021 CyberCon
SANS Cyber Security East: March 2021 , Mar 01, 2021 - Mar 06, 2021 CyberCon
SANS Secure Asia Pacific 2021 Singapore, Singapore Mar 08, 2021 - Mar 20, 2021 Live Event
SANS Secure Asia Pacific 2021 , Singapore Mar 08, 2021 - Mar 20, 2021 CyberCon
SANS Cyber Security West: March 2021 , Mar 15, 2021 - Mar 20, 2021 CyberCon
SANS Riyadh March 2021 , Kingdom Of Saudi Mar 20, 2021 - Apr 01, 2021 CyberCon
Arabia
SANS Secure Australia 2021 Canberra, Australia Mar 22, 2021 - Mar 27, 2021 Live Event
SANS Secure Australia 2021 Live Online , Australia Mar 22, 2021 - Mar 27, 2021 CyberCon
SANS 2021 , Mar 22, 2021 - Mar 27, 2021 CyberCon
SANS Munich March 2021 , Germany Mar 22, 2021 - Mar 27, 2021 CyberCon
SANS Cyber Security Mountain: April 2021 , Apr 05, 2021 - Apr 10, 2021 CyberCon
SANS Cyber Security East: April 2021 , Apr 12, 2021 - Apr 17, 2021 CyberCon
SANS London April 2021 , United Kingdom Apr 12, 2021 - Apr 17, 2021 CyberCon
SANS Autumn Australia 2021 Sydney, Australia Apr 12, 2021 - Apr 17, 2021 Live Event
SANS Autumn Australia 2021 - Live Online , Australia Apr 12, 2021 - Apr 17, 2021 CyberCon
SANS SEC401 (In Spanish) April 2021 , Spain Apr 12, 2021 - Apr 23, 2021 CyberCon
SANS Secure India 2021 , Singapore Apr 19, 2021 - Apr 24, 2021 CyberCon
SANS Baltimore Spring: Virtual Edition 2021 , Apr 26, 2021 - May 01, 2021 CyberCon
SANS Cyber Security Central: May 2021 , May 03, 2021 - May 08, 2021 CyberCon
SANS Security West 2021 , May 10, 2021 - May 15, 2021 CyberCon
SANS Cyber Security East: May 2021 , May 17, 2021 - May 22, 2021 CyberCon
SANS In French May 2021 , France May 31, 2021 - Jun 05, 2021 CyberConYou can also read
