Symmetric Ciphers
Also see the notes for block cipher modes and
KeyGenerators.
Key scheduling
Ciphers that have different key schedules, but are otherwise identical
are given different names (for example,
SAFERK and
SAFERSK).
Sometimes it is useful to bypass the normal key scheduling process, and specify
the subkeys (which should be random and independent) directly in the input key.
The name of such a cipher is derived by adding "Direct" to the standard name (except
that if part of the name already specifies the key schedule, that part is dropped).
For example, "DESDirect" and "SAFERDirect" refer to DES and SAFER respectively
with independent subkeys. This convention can also be used for experimental ciphers
that have no defined key schedule.
[A previous version of SCAN specified "ISK" instead of "Direct". This is a
backwardincompatible change, although an alias has been added for "BlowfishISK".]
If the subkeys are not in fact random and independent (to a closeenough
approximation), the cipher may become vulnerable to relatedkey attacks, and
therefore particular care is needed from the application designer in choosing how
to generate subkeys.
Subkeys are encoded in the order in which they are used for encryption (or if this
is ambiguous, the order in which they are presented or numbered in the original
document specifying the cipher). Where applicable, they have the same byte order
as is used in the rest of the cipher. However, in some cases these conventions may
still not be sufficient to decide how to encode the subkeys; if you wish to use a
"Direct" algorithm where the subkey encoding is not clear, ask for a comment to
be added to the algorithm definition.
 Designer:
 Joan Daemen
 Published:
 1994
 Alias:
 "ThreeWay" (use for identifiers)
 References:
 [Def, An] Joan Daemen,
"Cipher and Hash Function Design, Strategies based on linear and
differential cryptanalysis,"
Ph.D. Thesis, Katholieke Universiteit Leuven, March 1995.
http://www.esat.kuleuven.ac.be/~cosicart/ps/JD9500/
(in particular see
chapter 7,
"block cipher design").
 [Def, An] J. Daemen, R. Govaerts, J. Vandewalle,
"A New Approach to Block Cipher Design,"
Fast Software Encryption, Cambridge Security Workshop Proceedings,
Volume 809 of Lecture Notes in Computer Science (Ross Anderson, ed.), pp. 1832.
SpringerVerlag, 1994.
 [Inf] Bruce Schneier,
"Section 14.5 3Way,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [An] John Kelsey, Bruce Schneier, David Wagner,
"KeySchedule Cryptanalysis of 3WAY, IDEA, GDES, RC4, SAFER, and TripleDES".
http://www.counterpane.com/key_schedule.html
 [An] John Kelsey, Bruce Schneier, David Wagner,
"RelatedKey Cryptanalysis of 3WAY, BihamDES, CAST, DESX, NewDES, RC2, and TEA",
ICICS '97 Proceedings, SpringerVerlag, November 1997.
http://www.counterpane.com/relatedkey_cryptanalysis.html
 [Test] Wei Dai,
Crypto++ 3.0, file 3wayval.dat
http://www.eskimo.com/~weidai/cryptlib.html
 Key length:
 96 bits.
 Block size:
 12 bytes.
 Comment:
 The byte ordering convention is as follows: within each 12byte block, the
32bit words are represented in the same order as they are written in chapter 7
of Joan Daemen's thesis. Within each 32bit word, the bytes are in bigendian
order. This is consistent with the four test vectors in Crypto++ (note that
the same four test vectors are included on page 659 of
Applied Cryptography, 2nd edition, with the words written in
the opposite order).
For reference, the fourth test vector in this set is:
key = <D2F05B5ED6144138CAB920CD>
plaintext = <4059C76E83AE9DC4AD21ECF7>
ciphertext = <478EA8716B13F17C15B155ED>
 Security comment:
 3Way is vulnerable to relatedkey attacks, and therefore it should only
be used with keys that are generated by a strong RNG, or by a source of
bits that are sufficiently uncorrelated (such as the output of a hash
function).
 Designers:
 Joan Daemen,
Vincent Rijmen
 Alias:
 "OpenPGP.Cipher.7"
 Object Identifiers:
 2.16.840.1.101.3.4.1.1 for AES128/ECB/NoPadding
 2.16.840.1.101.3.4.1.2 for AES128/CBC/PKCSPadding
 2.16.840.1.101.3.4.1.3 for AES128/CFB
 2.16.840.1.101.3.4.1.4 for AES128/OFB
 Description:
 AES128 is defined as Rijndael with a 128bit block size and 10 rounds.
 References:
 [see references for Rijndael]
 [Inf] NIST,
AES Home Page,
http://www.nist.gov/aes/
 [Inf] AES Round 1 Information,
http://csrc.nist.gov/encryption/aes/round1/round1.htm
 [Inf] AES Round 2 Information,
http://csrc.nist.gov/encryption/aes/round2/round2.htm
 [Inf] The CAESAR  Candidate AES for Analysis and Reviews project,
http://www.dice.ucl.ac.be/crypto/CAESAR/caesar.html
 [Inf] Lars Knudsen, Vincent Rijmen,
The Block Cipher Lounge  AES,
http://www.ii.uib.no/~larsr/aes.html
 [Inf] John Savard,
Towards the 128bit Era  AES Candidates,
http://fn2.freenet.edmonton.ab.ca/~jsavard/crypto/co0408.htm
 [An] Eli Biham,
"A Note on Comparing the AES Candidates,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/biham2.pdf
 [An] Olivier Baudron, Henri Gilbert, Louis Granboulan,
Helena Handschuh, Antoine Joux, Phong Nguyen, Fabrice Noilhan,
David Pointcheval, Thomas Pornin, Guillaume Poupard, Jacques Stern,
Serge Vaudenay,
"Report on the AES Candidates,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/baudron1.pdf
 [An] G. Carter, E. Dawson, L. Nielsen,
"Key Schedule Classification of the AES Candidates,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/carter.pdf
 [An] B. Preneel, A. Bosselaers, V. Rijmen, B. Van Rompay, L. Granboulan,
J. Stern, S. Murphy, M. Dichtl, P. Serf, E. Biham, O. Dunkelman, V. Furman,
F. Koeune, G. Piret, JJ. Quisquater, L. Knudsen, H. Raddum,
"Comments by the NESSIE Project on the AES Finalists,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000524bpreneel.pdf
 [An] Thomas S. Messerges,
"Securing the AES Finalists Against Power Analysis Attacks,"
Presented at Fast Software Encryption 2000, New York.
 Key length:
 128 bits.
 Block size:
 16 bytes.
 Designers:
 Joan Daemen,
Vincent Rijmen
 Alias:
 "OpenPGP.Cipher.8"
 Object Identifiers:
 2.16.840.1.101.3.4.1.21 for AES192/ECB/NoPadding
 2.16.840.1.101.3.4.1.22 for AES192/CBC/PKCSPadding
 2.16.840.1.101.3.4.1.23 for AES192/CFB
 2.16.840.1.101.3.4.1.24 for AES192/OFB
 Description:
 AES192 is defined as Rijndael with a 128bit block size and 12 rounds.
 References:
 [see references for AES128 and
Rijndael]
 Key length:
 192 bits.
 Block size:
 16 bytes.
 Designers:
 Joan Daemen,
Vincent Rijmen
 Alias:
 "OpenPGP.Cipher.9"
 Object Identifiers:
 2.16.840.1.101.3.4.1.41 for AES256/ECB/NoPadding
 2.16.840.1.101.3.4.1.42 for AES256/CBC/PKCSPadding
 2.16.840.1.101.3.4.1.43 for AES256/CFB
 2.16.840.1.101.3.4.1.44 for AES256/OFB
 Description:
 AES256 is defined as Rijndael with a 128bit block size and 14 rounds.
 References:
 [see references for AES128 and
Rijndael]
 Key length:
 256 bits.
 Block size:
 16 bytes.
 Designers:
 Paulo Barreto,
Vincent Rijmen
 Published:
 November 2000
 References:
 [Def, An] Paulo Barreto, Vincent Rijmen,
The Anubis Block Cipher,
Presented at the First Open NESSIE Workshop, November 2000.
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/anubis.zip
 [Inf, Test] Paulo Barreto, Vincent Rijmen,
The Anubis Page,
http://www.esat.kuleuven.ac.be/~rijmen/anubis/
 [Test] Paulo Barreto, Vincent Rijmen,
Anubis Test Values,
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/anubis.zip
 Key length:
 Minimum 128, maximum 320, multiple of 32 bits; default 128 bits.
 Block size:
 16 bytes.
 Designer:
 Bruce Schneier
 Published:
 1994
 Alias:
 "OpenPGP.Cipher.4"
 References:
 [Def] Bruce Schneier,
"Description of a New VariableLength Key, 64Bit Cipher (Blowfish),"
Fast Software Encryption, Cambridge Security Workshop Proceedings,
pp. 191204. SpringerVerlag, 1994.
http://www.counterpane.com/bfsverlag.html
 [Inf, Impl] Bruce Schneier,
The Blowfish Encryption Algorithm page,
http://www.counterpane.com/blowfish.html
 [Inf] Bruce Schneier,
"Blowfish  One Year Later,"
Dr. Dobb's Journal, September 1995.
http://www.counterpane.com/bfdobsoyl.html
 [Inf] Bruce Schneier,
"Section 14.3 Blowfish,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
(Note: the C source in the appendix contains a
bug; this bug
is not present in Eric Young's C reference implementation.)
 [An] Serge Vaudenay,
"On the weak keys of Blowfish,"
Fast Software Encryption, Third International Workshop,
Volume 1008 of Lecture Notes in Computer Science (B. Preneel, ed.),
pp. 286297. SpringerVerlag, 1995.
 [Test] Eric Young,
Blowfish test vectors,
http://www.counterpane.com/vectors.txt
(also in C syntax)
 Key length:
 Minimum 32, maximum 448, multiple of 8 bits; default 128 bits.
 Block size:
 8 bytes.
 Security comment:
 The weak keys described in Vaudenay's paper do not appear to
be significant for full (16round) Blowfish.
 Variant:
 "BlowfishDirect" or "BlowfishISK"  the subkeys are specified
(using the notation of Applied Cryptography) as
P_{1..18} first, followed by
S_{1, 0..255}, S_{2, 0..255},
S_{3, 0..255}, and S_{4, 0..255}.
Each entry is represented as 4 bytes in bigendian order.
Weak keys may be avoided by ensuring that no Sbox has duplicate
entries (i.e. that there does not exist i, j, k where j != k such
that S_{i, j} = S_{i, k}).
 Designers:
 Johan Håstad, Mats Näslund
 Published:
 October 2000
 Description:
 BMGL is an alias for "Rijndael256/KFB(40)"; that is, Rijndael with
a 256bit block size, used in KFB mode, with
40 bits of keystream taken for each application of Rijndael.
See the description of KFB mode for further detail.
 References:
 Key length:
 Minimum 128, maximum 320, multiple of 32 bits; default 128 bits.
 Security comment:
 The security bounds proven for BMGL in Corollary 13 of Håstad
and Näslund's paper, hold provided that less than 2^{30}
bits (128 MBytes) of output are used. The "provable security" referred to
in the paper is in the sense of a proven reduction from predicting the
keystream generator, to breaking Rijndael256
as a oneway function.
 Designers:
 Carlisle Adams,
Stafford Tavares
 Published:
 1997
 Aliases:
 "CAST5", "OpenPGP.Cipher.3"
 References:
 [Def, Test] Carlisle Adams,
"The CAST128 Encryption Algorithm,"
RFC 2144, May 1997.
 [Inf, An] CAST Encryption Algorithm Related Publications,
http://adonis.ee.queensu.ca:8000/cast/
 [Inf] Carlisle Adams,
"Constructing Symmetric Ciphers Using the CAST Design Procedure,"
Selected Areas in Cryptography (E. Kranakis and P. van Oorschot, ed.), pp. 71104.
Kluwer Academic Publishers, 1997, and
Designs, Codes, and Cryptography, Vol. 12, No. 3, pp. 283316, 1997.
http://www.entrust.com/resourcecenter/pdf/cast.pdf
Also "CAST Design Procedure Addendum,"
http://www.entrust.com/downloads/castadd.pdf
 [Patent] Carlisle Adams,
"Symmetric cryptographic system for data encryption,"
U.S. Patent 5,511,123, filed August 4 1994, issued April 23 1996.
Also see:
Canadian Patent Application 2,134,410.
Japanese Patent Application 6295746.
U.S. Patent Application 08/761,763.
Canadian Patent Application 2,164,768.
PCT Patent Application CA96/00782.
U.S. Patent Application 08/895,875.
 Key length:
 Minimum 40, maximum 128, multiple of 8 bits; default 128 bits.
 Block size:
 8 bytes.
 Comment:
 Strictly speaking the alias "CAST5" only applies to CAST128 with a key size of 80
or 128 bits. Implementations MAY enforce this.
 Patent status:
 The design procedure that was used to obtain the CAST Sboxes is patented
by Entrust Technologies, Inc..
However, quoting from RFC 2144,
The CAST128 cipher described in this document is available worldwide
on a royaltyfree basis for commercial and noncommercial uses.
 Designer:
 Carlisle Adams,
Howard Heys,
Stafford Tavares,
Michael Wiener
 Published:
 June 1998
 Alias:
 "CAST6"
 References:
 [Def, An] Carlisle Adams,
The CAST256 Encryption Algorithm,
http://www.entrust.com/resources/pdf/cast256.pdf
 [Def, Test] Carlisle Adams, Jeff Gilchrist,
"The CAST256 Encryption Algorithm,"
RFC 2612, June 1999.
 [Inf] Carlisle Adams,
"Constructing Symmetric Ciphers Using the CAST Design Procedure,"
Selected Areas in Cryptography (E. Kranakis and P. van Oorschot, ed.), pp. 71104.
Kluwer Academic Publishers, 1997, and
Designs, Codes, and Cryptography, Vol. 12, No. 3, pp. 283316, 1997.
http://www.entrust.com/resources/pdf/cast.pdf
Also "CAST Design Procedure Addendum,"
http://www.entrust.com/resources/pdf/castadd.pdf
(This does not describe CAST256, but is relevant to its design.)
 [An] C. Adams, H. Heys, S. Tavares, M. Wiener,
"An Analysis of the CAST256 Cipher,"
Proceedings of IEEE Canadian Conference on Electrical and Computer
Engineering, 1999.
http://www.engr.mun.ca/~howard/PAPERS/cast256.ps
 [Patent] Carlisle Adams,
"Symmetric cryptographic system for data encryption,"
U.S. Patent 5,511,123, filed August 4 1994, issued April 23 1996.
Also see:
Canadian Patent Application 2,134,410.
Japanese Patent Application 6295746.
U.S. Patent Application 08/761,763.
Canadian Patent Application 2,164,768.
PCT Patent Application CA96/00782.
U.S. Patent Application 08/895,875.
 [Test] NIST,
CAST256 Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/cast256vals.zip
 Key length:
 Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 16 bytes.
 Patent status:
 The design procedure that was used to obtain the CAST Sboxes is patented
by Entrust Technologies, Inc..
However, quoting from RFC 2612,
The CAST256 cipher described in this document is available worldwide
on a royaltyfree and licencefree basis for commercial and noncommercial
uses.
 Designer:
 Chae Hoon Lim
 Published:
 1998
 Alias:
 "CRYPTONv05" (use for identifiers)
 Description:
 This is the version of CRYPTON originally submitted to NIST as an AES candidate.
 References:
 [Def, An] Chae Hoon Lim, Hyo Sun Hwang,
CRYPTON: A New 128bit Block Cipher  Specification and Analysis (Version 0.5),
http://crypt.future.co.kr/~chlim/pub/cryptonv05.ps
(PDF
version).
 [Inf, Test] The CRYPTON: A new 128bit block cipher page.
http://crypt.future.co.kr/~chlim/crypton.html
 [An] D'Halluin, Bijnens, Rijmen, Preneel,
"Attack on six rounds of CRYPTON,"
Presented at Fast Software Encryption '99, Rome.
 [Test] NIST,
CRYPTON v0.5 Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/cryptonvals.zip
 Comment:
 "CRYPTON: A New 128bit Block Cipher  Specification and Analysis" contains an error
in the description of the byte permutation phi: on the right hand side of figure 4,
b_{33} should be b_{03}.
 Key length:
 Minimum 64, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 16 bytes.
 Security comments:
 [[need reference to key schedule attacks]]
 CRYPTON0.5 has been superceded by CRYPTON1.0.
 Designer:
 Chae Hoon Lim
 Published:
 December 1998
 Alias:
 "CRYPTONv10" (use for identifiers)
 Description:
 This is version 1.0 of CRYPTON (the current version, at time of writing).
 References:
 Key length:
 Minimum 0, maximum 256, multiple of 8 bits; default 128 bits.
(Note that this is different from CRYPTON0.5.)
 Block size:
 16 bytes.
 Designers:
 Jacques Stern,
Serge Vaudenay
 Published:
 1998
 References:
 [Def, An, Test, Impl] Serge Vaudenay, Jacques Stern,
"CSCipher,"
Presented at Fast Software Encryption '98, Paris, France.
Lecture Notes in Computer Science No. 1372, pp. 189205, SpringerVerlag, 1998.
http://lasecwww.epfl.ch/query.msql?ref=SV98
 [An] Serge Vaudenay,
"On the Security of CSCipher,"
Presented at Fast Software Encryption '99, Rome.
To appear in Lecture Notes in Computer Science, SpringerVerlag.
http://lasecwww.epfl.ch/query.msql?ref=Vau99b
 [An] Bart van Rompey, Vincent Rijmen, Jorge Nakahara Jr.,
"A First Report on CSCipher, Hierocrypt, Grand Cru, SAFER++ and SHACAL,"
NESSIE Project public report, March 12, 2001.
https://www.cosic.esat.kuleuven.ac.be/nessie/reports/kulwp30061.pdf
 Key length:
 Minimum 0, maximum 128, multiple of 8 bits; default 128 bits.
 Block size:
 8 bytes.
 Patent status:
 CSCipher may be subject to patents by the
Compagnie des Signaux.
 Designer:
 Lars Knudsen
 Published:
 May 1998
 References:
 [Def, An] Lars Knudsen,
DEAL: A 128bit Block Cipher,
February 1998 (revised May 15, 1998).
http://www.ii.uib.no/~larsr/newblock.html
(Note: this paper contains an error; see the comments below.)
 [An] Stefan Lucks,
On the Security of the 128Bit Block Cipher DEAL.
http://th.informatik.unimannheim.de/m/lucks/papers.html
 [An] John Kelsey, Bruce Schneier,
"KeySchedule Cryptanalysis of DEAL,"
Sixth Annual Workshop on Selected Areas in Cryptography,
SpringerVerlag, August 1999, to appear.
http://www.counterpane.com/deal.html
 [Test] NIST,
DEAL Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/dealvals.zip
 Key length:
 128, 192 or 256 bits; default 128 bits.
 Block size:
 16 bytes.
 Comment:
 The paper "DEAL: A 128bit Block Cipher" contains an error in the description
of key scheduling: the three occurrences of "<4>" should be replaced by "<3>",
and the two occurrences of "<8>" should be replaced by "<4>". In other words,
the constants to be XOR'd with the input keys are 0x8000000000000000,
0x4000000000000000, 0x2000000000000000 and 0x1000000000000000.
 Security comments:
 The paper "On the Security of the 128Bit Block Cipher DEAL,"
describes some certificational weaknesses of DEAL with a key size
of 192 bits; these attacks are impractical.
 John Kelsey of Counterpane Systems has found some relatedkey attacks
and equivalent keys for DEAL (described in the DEAL AES forum on
NIST's web site,
and in the paper "KeySchedule Cryptanalysis of DEAL").
These appear to be impractical when DEAL is used as a cipher (as opposed to
a hash function using a construction such as DaviesMeyer).
 Designers:
 Don Coppersmith, Horst Feistel, Walt Tuchmann,
U.S. National Security Agency
 Published:
 1976
 References:
 [Def] U.S. National Institute of Standards and Technology,
NIST FIPS PUB 462 (supercedes FIPS PUB 461),
"Data Encryption Standard",
U.S. Department of Commerce, December 1993.
http://www.itl.nist.gov/div897/pubs/fip462.htm
 [Inf, Test] U.S. National Institute of Standards and Technology,
NIST FIPS PUB 74,
"Guidelines for Implementing and Using the NBS Data Encryption Standard".
 [Inf] Bruce Schneier,
"Chapter 12 Data Encryption Standard,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf, Test] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
"Section 7.4 DES,"
Handbook of Applied Cryptography,
CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf,
.ps
 [An] Eli Biham, Adi Shamir,
"Differential Cryptanalysis of the Full 16Round DES,"
CS 708, Proceedings of CRYPTO '92,
Volume 740 of Lecture Notes in Computer Science, December 1991.
http://www.cs.technion.ac.il/users/wwwb/cgibin/trget.cgi/1991/CS/CS0708.ps
 [An] Eli Biham, Adi Shamir,
"Differential cryptanalysis of DESlike cryptosystems,"
Technical report CS9016, Weizmann Institute of Science.
Advances in Cryptology  CRYPTO '90 Proceedings and
Journal of Cryptology, Vol. 4, No. 1, pp. 372, 1991.
http://www.cs.technion.ac.il/~biham/Reports/Weizmann/cs9016.ps.gz
 [An] Eli Biham, Adi Shamir,
Differential Cryptanalysis of the Data Encryption Standard,
SpringerVerlag, 1993.
 [An] M. Matsui,
"Linear cryptanalysis method for DES cipher,"
Advances in Cryptology  EUROCRYPT '93 Proceedings,
Volume 765 of Lecture Notes in Computer Science (T. Helleseth, ed.), pp. 386397.
SpringerVerlag, 1994.
 [An] M. Matsui,
"The First Experimental Cryptanalysis of the Data Encryption Standard,"
Advances in Cryptology  CRYPTO '94 Proceedings,
Volume 839 of Lecture Notes in Computer Science, SpringerVerlag, 1994.
 [An] M. Matsui,
"On Correlation Between the Order of Sboxes and the Strength of DES,"
Advances in Cryptology  EUROCRYPT '94 Proceedings,
Volume 950 of Lecture Notes in Computer Science, SpringerVerlag, 1995.
 [An] Eli Biham, A. Biryukov,
"An Improvement of Davies' Attack on DES,"
CS 817, EUROCRYPT '94 Proceedings (May 1994),
Volume 950 of Lecture Notes in Computer Science (A. De Santis, ed.),
Springer Verlag, 1995, and
Journal of Cryptology, Vol. 10, No. 3, pp. 195206, 1997.
http://www.cs.technion.ac.il/users/wwwb/cgibin/trget.cgi/1994/CS/CS0817.ps
 [An] Lars Knudsen,
"New potentially weak keys for DES and LOKI,"
Advances in Cryptology  EUROCRYPT '94 Proceedings,
Volume 950 of Lecture Notes in Computer Science (A. De Santis, ed.), pp. 419424.
Springer Verlag, 1995.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/potential.ps.Z
 [An] Lars Knudsen, John Erik Mathiassen,
"A ChosenPlaintext Linear Attack on DES,"
Proceedings of Fast Software Encryption 2000,
Volume 1978 of Lecture Notes in Computer Science. SpringerVerlag, 2001.
http://link.springer.de/link/service/series/0558/bibs/1978/19780262.htm
(requires subscription)
 [Test] U.S. National Institute of Science and Technology,
NIST Special Publication 80017, pp. 124 et seq.
http://csrc.nist.gov/nistpubs/80017.pdf
 Key length:
 64 bits as encoded; 56 bits excluding parity bits.
 Block size:
 8 bytes.
 Comment:
 Implementations MUST ignore (i.e. not check) the parity bits of keys.
KeyGenerators for DES MUST, however, output keys with correct parity.
 Security comment:
 The fixed 56bit effective key length is too short to prevent bruteforce attacks.
 Designers:
 Whitfield Diffie, Martin Hellman, Walt Tuchmann
 Published:
 197879
 Aliases:
 "DESEDE2" (always 2key)
 "DESEDE3", "OpenPGP.Cipher.2" (always 3key)
 "TripleDES", "3DES" (default key length implemented inconsistently
by different providers)
 References:
 [Def] U.S. National Institute of Standards and Technology,
DRAFT FIPS PUB 463, "Data Encryption Standard",
U.S. Department of Commerce, 1999.
http://csrc.nist.gov/cryptval/des/fr990115.htm
 [Inf] Walt Tuchman,
"Hellman Presents No Shortcut Solutions To DES,"
IEEE Spectrum, v. 16, n. 7, July 1979, pp. 4041.
 [Inf] U.S. National Institute of Standards and Technology,
NIST FIPS PUB 462, "Data Encryption Standard",
U.S. Department of Commerce, December 1993.
http://www.itl.nist.gov/div897/pubs/fip462.htm
 [Inf] Bruce Schneier,
"Chapter 12 Data Encryption Standard," and
"Section 15.2 Triple Encryption,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf, An] Ralph C. Merkle,
Secrecy, authentication, and public key systems,
UMI Research Press, Ann Arbor, Michigan, 1979.
 [Inf, An] Ralph C. Merkle, Martin Hellman,
"On the Security of Multiple Encryption,"
Communications of the ACM,
vol. 24 no. 7, 1981, pp. 465467.
 [An] Paul van Oorshot, Michael Wiener,
"A KnownPlaintext Attack on TwoKey Triple Encryption,"
Advances in Cryptology  EUROCRYPT '90 Proceedings,
Volume 473 of Lecture Notes in Computer Science (I.B. Damgård, ed.), pp. 318325.
SpringerVerlag, 1991.
 [An] John Kelsey, Bruce Schneier, David Wagner,
"KeySchedule Cryptanalysis of 3WAY, IDEA, GDES, RC4, SAFER, and TripleDES".
http://www.counterpane.com/key_schedule.html
 [An] Stefan Lucks,
"Attacking Triple Encryption,"
Fast Software Encryption '98,
Volume 1372 of Lecture Notes in Computer Science (Serge Vaudenay, ed.),
SpringerVerlag, 1998.
http://th.informatik.unimannheim.de/m/lucks/papers.html
 [An] Helena Handschuh, Bart Preneel,
"On the security of double and 2key triple modes of operation."
Fast Software Encryption 6,
Volume 1636 of Lecture Notes in Computer Science (L. Knudsen, ed.),
SpringerVerlag, 1999.
http://perso.enst.fr/~handschu/fse6.ps
 [Test] U.S. National Institute of Standards and Technology,
Modes of Operation Validation System for the Triple
Data Encryption Algorithm (TMOVS): Requirements and Procedures,
NIST Special Publication 80020, April 2000.
http://csrc.nist.gov/publications/nistpubs/80020/80020.pdf
 [Test] U.S. National Institute of Standards and Technology,
Triple DES Test Vectors,
http://csrc.nist.gov/cryptval/des/tripledesvectors.zip
 Key length:
 128 or 192 bits, as encoded (112 or 168 bits excluding parity).
The default key length depends on the name of the KeyGenerator:
128 bits for DESEDE2, and 192 bits for DESEDE3 or OpenPGP.Cipher.2.
The default key length for DESede and the other aliases is implemented
inconsistently between different providers, and therefore if an
application needs to create a specific length of DESede key in a
way that is guaranteed to work across providers, it should explicitly
create a SecretKeySpec.
 Block size:
 8 bytes.
 Comments:
 If the key length is 128 bits including parity (i.e. twokey triple DES),
the first 8 bytes of the encoding represent the key used for the
two outer DES operations, and the second 8 bytes represent the key
used for the inner DES operation.
 If the key length is 192 bits including parity (i.e. threekey triple DES),
then three independent DES keys are represented, in the order in
which they are used for encryption.
 Implementations MUST ignore (i.e. not check) the parity bits of keys.
KeyGenerators for DESede MUST, however, output keys with correct parity.
 Security comment:
 Quoting from the paper "Attacking Triple Encryption" cited above:
[A]bout 2^{108} steps of computation are sufficient to break
threekey triple DES. If one concentrates on the number of single DES
operations and assumes the other operations to be much faster,
2^{90} of these are enough.
Better attacks than this are available against twokey triple DES (which
should only be used for backward compatibility, if at all).
 Designer:
 Ron Rivest
 Description:
 If K, K1 and K2 are the subkeys encoded as described below, then
encryption and decryption are defined by:
E_{DESX[K, K1, K2]}(P) = E_{DES[K]}(P XOR K1) XOR K2
D_{DESX[K, K1, K2]}(C) = D_{DES[K]}(C XOR K3) XOR K2
If the user key length is 24 bytes, the first 8 bytes represent the key
K used for the DES operation, and the two subsequent blocks of 8 bytes
represent the "whitening" keys K1 and K2, in that order.
If the user key length is 16 bytes, the first 8 bytes represent the key
K used for the DES operation, the second 8 bytes represent the whitening
key K1, and K2 is derived from K and K1 as specified in the first reference
below.
 References:
 [Def] Mark Riordan,
Subject: Re: Ladder DES.
Posting to Usenet newsgroup sci.crypt, 1 Mar 1994.
(MessageID: <2ku9uc$sr8@msuinfo.cl.msu.edu>)
Archived at
ftp://ftp.replay.com/pub/replay/mirror/ftp.cryptography.org/DESX/
desx.algorithm.description
 [An] Joe Kilian, Phillip Rogaway,
"How to protect DES against exhaustive key search,"
Earlier version in Advances in Cryptology  CRYPTO '96,
Volume 1109 of Lecture Notes in Computer Science (N. Koblitz, ed.), pp. 252267.
SpringerVerlag, 1996.
Full version:
http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/desx.ps
 [Inf] U.S. National Institute of Standards and Technology,
NIST FIPS PUB 462 (supercedes FIPS PUB 461),
"Data Encryption Standard",
U.S. Department of Commerce, December 1993.
http://www.itl.nist.gov/div897/pubs/fip462.htm
 [Inf] Bruce Schneier,
"Chapter 12 Data Encryption Standard,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [An] John Kelsey, Bruce Schneier, David Wagner,
"RelatedKey Cryptanalysis of 3WAY, BihamDES, CAST, DESX, NewDES, RC2, and TEA",
ICICS '97 Proceedings, SpringerVerlag, November 1997.
http://www.counterpane.com/relatedkey_cryptanalysis.html
 Key length:
 128 or 192 bits; default 192 bits, as encoded. See security comments for
the effective key length.
 Block size:
 8 bytes.
 Comments:
 Security comments:
 The paper "How to protect DES against exhaustive key search" proves that
attacks on DESX that assume a "blackbox" model for DES require a work
factor of 2^{118}. This does not take into account any possible
weaknesses of DES, apart from the key complementation property. In
particular, DESX is no more secure than DES against linear and
differential cryptanalysis.
 DESX is vulnerable to relatedkey attacks, and therefore it should only
be used with keys that are generated by a strong RNG, or by a source of
bits that are sufficiently uncorrelated (such as the output of a hash
function).
 Designers:
 Henri Gilbert,
Marc Girault,
Philippe Hoogvorst,
Fabrice Noilhan,
Thomas Pornin,
Guillaume Poupard,
Jacques Stern,
Serge Vaudenay
 Published:
 May 1998
 References:
 [Def, An] Henri Gilbert, Marc Girault, Philippe Hoogvorst, Fabrice Noilhan,
Thomas Pornin, Guillaume Poupard, Jacques Stern, Serge Vaudenay,
Decorrelated Fast Cipher: an AES Candidate,
http://lasecwww.epfl.ch/query.msql?ref=GG%2B98b
(also see errata at the DFC home page)
 [Inf] The Decorrelated Fast Cipher Home Page,
http://lasecwww.epfl.ch/dfc.shtml.
 [Inf] Serge Vaudenay,
"The Decorrelation Technique,"
http://lasecwww.epfl.ch/decorrelation.shtml
 [An] Lars Knudsen, Vincent Rijmen,
"On the decorrelated fast cipher (DFC) and its theory,"
Presented at Fast Software Encryption '99, Rome.
 [Patent] Serge Vaudenay,
"Procédé de décorrélation des données,"
French patent application num. 96 13411. Requested on 4 November 1996.
(Extension to other countries in process.)
 [Test] NIST,
DFC Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/dfcvals.zip
 Key length:
 Minimum 0, maximum 256 bits, multiple of 8 bits; default 128 bits.
 Block size:
 16 bytes.
 Patent status:
 DFC itself is unpatented, but the decorrelation technique it uses may
be covered by the patent application referenced above.
DFCv2128(rounds,s)  Block Cipher

 Designers:
 Louis Granboulan,
Phong Nguyen,
Fabrice Noilhan,
Serge Vaudenay
 Published:
 August 2000
 References:
 [Def, An, Test] Louis Granboulan, Phong Nguyen, Fabrice Noilhan, Serge Vaudenay,
"DFCv2,"
In Selected Areas in Cryptography  Proceedings of SAC '2000 (D. Stinson and S. Tavares, eds.),
Waterloo, Ontario, Canada, August 1415 2000. To appear in Lecture Notes in Computer Science, SpringerVerlag.
http://www.di.ens.fr/~granboul/recherche/publications/
 [Inf] The Decorrelated Fast Cipher Home Page,
http://lasecwww.epfl.ch/dfc.shtml.
 [Inf] Serge Vaudenay,
"The Decorrelation Technique,"
http://lasecwww.epfl.ch/decorrelation.shtml
 [Inf] Olivier Baudron, Henri Gilbert, Louis Granboulan,
Helena Handschuh, Robert Harley, Antoine Joux, Phong Nguyen, Fabrice Noilhan,
David Pointcheval, Thomas Pornin, Guillaume Poupard, Jacques Stern,
Serge Vaudenay,
"DFC Update,"
Presented at the 2nd AES Conference.
http://lasecwww.epfl.ch/query.msql?ref=BG%2B99b
 [An] Lars Knudsen, Vincent Rijmen,
"On the decorrelated fast cipher (DFC) and its theory,"
Presented at Fast Software Encryption '99, Rome.
 [Patent] Serge Vaudenay,
"Procédé de décorrélation des données,"
French patent application num. 96 13411. Requested on 4 November 1996.
(Extension to other countries in process.)
 Parameters:

Integer rounds
[creation/read, no default]  the number
of rounds to be performed (minimum 8, default 12, multiple of 2)

Integer s
[creation/read]  adjustment to
key scheduling (minimum 4, default 4?)
 Key length:
 128, 192 or 256 bits; default 128 bits.
 Block size:
 16 bytes.
 Comments:
 Note that DFCv2 is not the same as the algorithm defined in the
"DFC Update" paper (which did not have a sufficiently wellspecified
key schedule). That paper is included in the references only for
comparison.
 Patent status:
 DFCv2 itself is unpatented, but the decorrelation technique it uses may
be covered by the patent application referenced above.
Diamond2(rounds)  Block Cipher

 Designer:
 Michael Paul Johnson
 Published:
 1995
 References:
 [Def] Michael Paul Johnson,
"The Diamond2 Block Cipher,"
diamond2.{ps,doc}
in
ftp://ftp.zedz.com/pub/cryptoI/mirror/ftp.cryptography.org/libraries/dlock2.zip
 [Inf] Michael Paul Johnson,
"Beyond DES: Data Compression and the MPJ Encryption Algorithm,"
Master's Thesis at the University of Colorado at Colorado Springs, 1989.
thesis.txt
in
ftp://ftp.zedz.com/pub/cryptoI/mirror/ftp.cryptography.org/libraries/dlock2.zip
(Note: this describes an earlier version of Diamond, not Diamond2.)
 [Impl, Test] Michael Paul Johnson,
Diamond2 reference implementation (in C++),
ftp://ftp.zedz.com/pub/cryptoI/mirror/ftp.cryptography.org/libraries/dlock2.zip
 Parameters:

Integer rounds
[creation/read, no default]  the number
of rounds to be performed (minimum 10)
 Key length:
 Minimum 8, maximum 65536, multiple of 8 bits; default 128 bits.
 Block size:
 16 bytes.
 Comments:
 The paper "The Diamond2 Block Cipher" does not appear to specify a recommended
number of rounds, only a minimum number of rounds. For that reason, the rounds
parameter has been made mandatory.
 The "Diamond2 Lite" variant does not have a standard name.
 Designers:
 Kazumaro Aoki, Masayuki Kanda, Tsutomu Matsumoto, Shiho Moriai,
Kazuo Ohta, Miyako Ookubo, Youichi Takashima, Hiroki Ueda
 Published:
 June 1998
 References:
 [Def, An] Specification of E2  a 128bit Block Cipher,
http://info.isl.ntt.co.jp/e2/E2spec.pdf
 [Inf] The E2 Home Page,
http://info.isl.ntt.co.jp/e2/
 [Inf] Supporting Document on E2,
(corrected version,
April 16 1999)
http://info.isl.ntt.co.jp/e2/E2support.pdf
 [Inf] Kazumaro Aoki, Hiroki Ueda,
"Optimized Software Implementations of E2,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/aoki.pdf
 [Inf] Kazumaro Aoki, Hiroki Ueda,
"Optimized Software Implementations of E2,"
Revised April 15, 1999.
http://info.isl.ntt.co.jp/e2/RelDocs/implE2.pdf
 [Def, An] M. Kanda, Y. Takashima, T. Matsumoto, K. Aoki, K. Ohta,
"A Strategy for Constructing Fast Round Functions with Practical
Security against Differential and Linear Cryptanalysis,"
Presented at the 5th annual workshop on Selected Areas in
Cryptography (SAC '98) in August, 1998.
 [An] Makoto Sugita, Kazukuni Kobara, Hideki Imai,
"Pseudorandomness and Maximum Average of Differential Probability of
Block Ciphers with SPNStructures like E2,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/sugita.pdf
 [An] Yuji Hori, Toshinobu Kaneko,
"A study of E2 by higher order differential attack,"
Technical report of IEICE. ISEC9839, Science University of Tokyo
(in Japanese  brief English summary
here).
 [An] Mitsuru Matsui, Toshio Tokita,
"On cryptanalysis of a byteoriented cipher,"
The 1999 Symposium on Cryptography and Information Security, SCIS99W21.5
(in Japanese  brief English summary
here).
 [An] Mitsuru Matsui, Toshio Tokita,
"Cryptanalysis of a Reduced Version of the Block Cipher E2,"
Fast Software Encryption '99 (March 1999), pp. 7079
(abstract here).
 [An] NTT Laboratories,
"Security of E2 aginst Truncated Differential Cryptanalysis (in progress),"
April 15 1999.
http://info.isl.ntt.co.jp/e2/RelDocs/E2trunc.pdf
 [An] Makoto Sugita, Kazukuni Kobara, Kazuhiro Uehara, Shuji Kubota, Hideki Imai,
"Relationships among Differential, Truncated Differential,
Impossible Differential Cryptanalyses against WordOriented
Block Ciphers like Rijndael, E2,"
Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/32msugita.pdf
 [An] Matsui, Tokita,
"Cryptanalysis of block cipher E2,"
Presented at Fast Software Encryption '99, Rome.
 [Patent] NTT (assignee),
"Data Randomize Device and Symmetric Cipher Devices (translated),"
Japanese Patent Application JP 173672/1997.
 [Patent] NTT (assignee),
[[need patent titles]]
Japanese Patent Application JP 013572/1998.
Japanese Patent Application JP 013573/1998.
Japanese Patent Application JP 153066/1998.
Japanese Patent Application JP 147479/1998.
(Corresponding applications will be filed in other countries.)
 [Test] NIST,
E2 Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/e2vals.zip
 Key length:
 128, 192 or 256 bits; default 128 bits.
 Block size:
 16 bytes.
 Patent status:
 NTT has several patents pending on E2 (see references).
? FROG[(blockSize[,rounds])]  Block Cipher

 Designers:
 Dianelos Georgoudis, Damian Leroux, Billy Simón Chaves
 Published:
 1998
 References:
 [Def, An, Impl] Dianelos Georgoudis, Damian Leroux, Billy Simón Chaves,
The "FROG" Encryption Algorithm,
June 15, 1998.
http://www.tecapro.com/aesfrog.htm
 [An] F. Koeune, G.F. Piret, J.J. Quisquater,
Our first few comments about FROG,
August 1998.
http://www.dice.ucl.ac.be/crypto/CAESAR/frog.html
 [An] David Wagner, Niels Ferguson, Bruce Schneier,
Cryptanalysis of FROG,
Corrected version, March 16, 1999. Presented at the 2nd AES Conference.
http://www.cs.berkeley.edu/~daw/papers/frogfinal.ps
(slides:
http://www.cs.berkeley.edu/~daw/papers/frogslides.ps)
[Also see: http://www.counterpane.com/frog.html  is this the earlier version?]
 [Test] NIST,
FROG Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/frogvals.zip
 Parameters:

Integer blockSize
[creation/read, default 16]  the
length of a block in bytes (8 to 128)

Integer rounds
[creation/read, default 8]  the number
of rounds to be performed (minimum 8)
 Key length:
 Minimum 40, maximum 1000, multiple of 8 bits; default 128 bits.
 Block size:
 As given by the
blockSize
parameter (in bytes).
 Missing information:
 Test vectors for block sizes other than 16 bytes.
 Comment:
 The original C reference code uses an unconventional byte order when printing
test vectors (the order of bytes is reversed across the whole block). The
correct byte order is that defined by the Java reference
implementation, and by the NIST test vectors referenced above.
 Security comment:
 The paper "Cryptanalysis of FROG" describes the following attacks
on weak keys:
 A differential attack requiring 2^{58} chosen plaintexts
and very little time for the analysis; it works for about 2^{33.0}
of the keyspace.
 A linear attack that uses 2^{56} known texts and works for
2^{31.8} of the keyspace.
 A ciphertextonly linear attack using 2^{64} ciphertexts (also
for 2^{31.8} of the keyspace).
 A differential attack on the decryption function that requires 2^{36}
chosen ciphertexts and works for 2^{29.3} of the keyspace.
 Alias:
 "GOST2814789"
 Published:
 1989
 References:
 [Def] GOST, Gosudarstvennyi Standard 2814789,
"Cryptographic Protection for Data Processing Systems,"
Government Committee of the USSR for Standards, 1989 (in Russian).
 [Def, Inf] Bruce Schneier,
"Section 14.1 GOST,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] J. Pieprzyk, L. Tombak,
"Soviet Encryption Algorithm,"
Preprint 9410, Department of Computer Science, The University of Wollongong, 1994.
ftp://ftp.cs.uow.edu.au/pub/papers/1994/tr9410.ps.Z
 [An] MarkkuJuhani Saarinen,
A chosen key attack against the secret Sboxes of GOST,
http://www.cc.jyu.fi/~mjos/gost_cka.ps
 [An] C. Charnes, L. O'Connor, J. Pieprzyk, R. SavafiNaini, Y. Zheng,
"Comments on Soviet encryption algorithm,"
Advances in Cryptology  EUROCRYPT '94 Proceedings,
Volume 950 of Lecture Notes in Computer Science (A. De Santis, ed.),
pp. 433438. Springer Verlag, 1995.
 [An] C. Charnes, L. O'Connor, J. Pieprzyk, R. SafaviNaini, Y. Zheng,
"Further comments on GOST encryption algorithm,"
Preprint 949, Department of Computer Science, The University of Wollongong,
1994.
ftp://ftp.cs.uow.edu.au/pub/papers/1994/tr949.ps.Z
 [An] John Kelsey, Bruce Schneier, David Wagner,
"Keyschedule cryptanalysis of IDEA, GDES, GOST, SAFER, and tripleDES,"
Advances in Cryptology  CRYPTO '96 Proceedings.
SpringerVerlag, August 1996.
http://www.cs.berkeley.edu/~daw/papers/keyschedcrypto96.ps
 [Inf] MarkkuJuhani Saarinen,
C implementation and test vectors for GOST hash function,
http://www.tcs.hut.fi/~mjos/gosthash.tar.gz
[The implementation is of GOSTHash,
but this archive also contains a draft translation into
English of the GOST 2814789 standard.]
 Parameters:

byte[][] sboxes
[write only, default as given in Applied
Cryptography]  the Sboxes to be used by this cipher instance.
sboxes[i1][j]
represents the output of Sbox i,
for an input value j.
The implementation may or may not copy the contents of arrays used
to set this parameter. If any such arrays are subsequently changed, the
output of the cipher is undefined (it is therefore the responsibility
of the caller to make sure that references to these arrays are not
accessible to untrusted code). Setting this parameter will reset the
current key and feedback vector, if applicable.
 Key length:
 256 bits.
 Block size:
 8 bytes.
 Missing information:
 Test vectors.
 Security comment:
 The paper "A chosen key attack against the secret Sboxes of GOST"
cited above describes how to recover the Sboxes in about 2^{32}
encryptions. The main significance of this is on tamperproof hardware
implementations where the Sboxes were assumed to be secret; for a software
implementation, they should be assumed to be public in any case.
HPC1(blockSize[,backup])  Block Cipher

 Designer:
 Rich Schroeppel
 Published:
 1998
 Description:
 This is the original HPC cipher submitted as a first round AES candidate.
 References:
 [Def] Rich Schroeppel, Hilarie Orman,
Specification for the Hasty Pudding Cipher,
http://www.cs.arizona.edu/~rcs/hpc/hpcspec
 [Inf, Test] Rich Schroeppel,
The Hasty Pudding Cipher page,
http://www.cs.arizona.edu/~rcs/hpc/
 [An] David Wagner,
Equivalent keys for HPC,
Rump session talk at the 2nd AES Conference.
Slides at:
http://www.cs.berkeley.edu/~daw/papers/hpcaes99slides.ps
 [An] Carl D'Halluin, Gert Bijnens, Bart Preneel, Vincent Rijmen,
Equivalent keys of HPC,
Katholieke Universiteit Leuven, ESATCOSIC.
http://www.esat.kuleuven.ac.be/~rijmen/pub99.html
 [Inf] Rich Schroeppel,
"The Hasty Pudding Cipher: One Year Later,"
June 12, 1999.
http://www.cs.arizona.edu/~rcs/hpc/hpconeyearlater
 [Test] NIST,
HPC Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/hpcvals.zip
 Parameters:

Integer blockSize
[creation/read, default 16]  the
length of a block in bytes (minimum 1)

Integer backup
[creation/read, default 0]  a parameter
that can be increased to make the cipher more conservative, at
the cost of speed (minimum 0)

long[] spice
[write, default allzeroes]  an array
of 8 64bit words containing a diversifier.
The implementation may or may not copy the contents of arrays used
to set this parameter. If any such array is subsequently changed, the
output of the cipher is undefined, unless the parameter is set again
immediately (it is therefore the responsibility of the caller to make
sure that a reference to this array is not accessible to untrusted code).
Setting this parameter will not reset the
current key and feedback vector.
 Key length:
 Minimum 0, maximum 65536 bits; default 128 bits.
 Block size:
 As given by the
blockSize
parameter (in bytes). Note that
while HPC supports block sizes that are not a multiple of 8 bits, the
JCE API does not.
 Comment:
 The convention for encoding keys that are not a multiple of 8 bits
in length, is for the last (
effectiveBitLength
% 8) bits of
the key to be packed in the highorder bits of the last byte of the
encoding. Any unused loworder bits of the last byte are ignored. For
example, the key given by the 11bit sequence
<01010101 010>_{2}, would be encoded as the byte array
{ 0x55, 0x40  junk }
, where
junk & 0xE0 == 0
.
The value of the key's effectiveBitLength
parameter is used
to determine how many bits of the encoding are significant.
 Security comments:
 The paper "Equivalent keys of HPC" by D'Halluin et al, describes an
attack which, for 128bit keys, has an expected work factor of
2^{89}, and works for 1/256 of the keyspace. The analysis is
extended to HPC with a 192bit key and a 256bit key, with similar
results. For some other key lengths (including 56 bits), all keys are
shown to be weak. The "tweak" described in "Tweaking the Hasty Pudding
Cipher," (see HPC2) is intended to correct
this problem, but has not yet had a significant amount of analysis.
 Also note that with the default allzeroes spice value, much of the work
being done by the cipher has no cryptographic effect.
? HPC2(blockSize[,backup])  Block Cipher

 Designer:
 Rich Schroeppel
 Published:
 June 1999
 Description:
 This is the "tweaked" version of HPC, with a modified key schedule.
 References:
 Parameters:

Integer blockSize
[creation/read, default 16]  the
length of a block in bytes (minimum 1)

Integer backup
[creation/read, default 0]  a parameter
that can be increased to make the cipher more conservative, at
the cost of speed (minimum 0)

long[] spice
[write, default allzeroes]  an array
of 8 64bit words containing a diversifier.
The implementation may or may not copy the contents of arrays used
to set this parameter. If any such array is subsequently changed, the
output of the cipher is undefined, unless the parameter is set again
immediately (it is therefore the responsibility of the caller to make
sure that a reference to this array is not accessible to untrusted code).
Setting this parameter will not reset the
current key and feedback vector.
 Key length:
 Minimum 0, maximum 65536 bits; default 128 bits.
 Block size:
 As given by the
blockSize
parameter (in bytes). Note that
while HPC supports block sizes that are not a multiple of 8 bits, the
JCE API does not.
 Missing information:
 Test vectors.
 Comment:
 [see comment for HPC1]
 Security comment:
 Note that with the default allzeroes spice value, much of the work
being done by the cipher has no cryptographic effect.
 Designer:
 Matthew Kwan
 Published:
 1997
 References:
 [Def, Test] Matthew Kwan,
"The Design of the ICE Encryption Algorithm,"
Proceedings of Fast Software Encryption  Fourth International Workshop,
Haifa, Israel, pp. 6982.
SpringerVerlag, 1997.
http://www.darkside.com.au/ice/paper.html
 [Inf, Impl] The ICE Home Page,
http://www.darkside.com.au/ice/
 [An] Matthew Kwan,
Cryptanalysis of ICE,
http://www.darkside.com.au/ice/cryptanalysis.html
 [An] B. Van Rompay, Lars Knudsen, Vincent Rijmen,
"Differential cryptanalysis of the ICE encryption algorithm,"
Fast Software Encryption,
Volume 1372 of Lecture Notes in Computer Science (Serge Vaudenay, ed.), pp. 270283.
SpringerVerlag, 1998.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/vrompay/fse98.ps.gz
 Key length:
 Minimum 64, multiple of 64 bits; default 128 bits.
 Block size:
 8 bytes.
 Comment:
 The length of the key defines the "level" parameter (note that the "Thin ICE" variant
is not included).
 Security comment:
 The paper "Differential cryptanalysis of the ICE encryption algorithm"
describes several differential attacks, including an attack against a variant reduced
to 15 rounds, with 2^{56} work and at most 2^{56} chosen plaintexts.
(The full algorithm has n/4 rounds when the key length is n bits.)
The paper concludes:
[...] The main conclusion of this paper is that keyed permutation does not prevent
differential cryptanalysis. Although the analysis is more complicated and becomes
key dependent, in our opinion the intention of the design has not been reached.
The best 3round iterative characteristic that can be used in our attack has a
probability of 2^{13}, which is higher than the probability of
2^{16} of the best 3round characteristic for LOKI91
(a similar block cipher that makes use of four identical 12 to 8bit Sboxes).
These attacks are probably not practical when the number of rounds is 32 or higher
(i.e. the key is 128 bits or longer). However, in that case ICE is slower than DES.
 Designers:
 Xuejia Lai, James Massey
 Published:
 1992
 Alias:
 "OpenPGP.Cipher.1"
 Object Identifiers:
 1.3.6.1.4.1.188.7.1.1.1 for IDEA/ECB
 1.3.6.1.4.1.188.7.1.1.2 for IDEA/CBC
 1.3.6.1.4.1.188.7.1.1.3 for IDEA/CFB
 1.3.6.1.4.1.188.7.1.1.4 for IDEA/OFB
(source for OIDs)
 References:
 [Def, An] X. Lai,
"On the design and security of block ciphers",
ETH Series in Information Processing (J.L. Massey, ed.), Vol. 1,
HartungGorre Verlag, Konstanz Technische Hochschule (Zurich), 1992.
 [Inf, An] X. Lai, J.L. Massey, S. Murphy,
"Markov Ciphers and Differential Cryptanalysis,"
Advances in Cryptology  EUROCRYPT '91,
Volume 547 of Lecture Notes in Computer Science (D.W. Davies, ed.), pp. 1738.
SpringerVerlag, 1991.
 [Inf] The IDEA Algorithm page.
http://www.mediacrypt.com/
Older version archived at
http://web.archive.org/web/20000816173927/http://www.ascom.ch/infosec/idea/oid.html
 [Inf] Bruce Schneier,
"Section 13.9 IDEA,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
(Note: there is an error in the description; the diagram is
correct.)
 [Inf] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
"Section 7.6 IDEA,"
Handbook of Applied Cryptography,
CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf,
.ps
 [An] Joan Daemen, René Govaerts, Joos Vandewalle,
"Weak Keys of IDEA,"
Advances in Cryptology  CRYPTO '93 Proceedings,
Volume 773 of Lecture Notes in Computer Science (D. Stinson, ed.), pp. 224231.
SpringerVerlag, 1994.
http://www.esat.kuleuven.ac.be/~cosicart/ps/JD9304.ps.gz
 [An] Joan Daemen, René Govaerts, Joos Vandewalle,
"Cryptanalysis of 2.5 Rounds of IDEA,"
ESATCOSIC Technical Report 93/1, 1993.
http://www.esat.kuleuven.ac.be/~cosicart/ps/JD9306.ps.gz
 [An] J. Borst, L. Knudsen, V. Rijmen,
"Two attacks on reduced IDEA,"
Advances in Cryptology  EUROCRYPT '97 Proceedings,
Volume 1233 of Lecture Notes in Computer Science (W. Fumy, ed.), pp. 113.
SpringerVerlag, 1997.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/idea.ps.gz
 [An] L. Knudsen, V. Rijmen,
"Truncated Differentials of IDEA,"
ESATCOSIC Technical Report 971.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/idea_trunc.ps.Z
 [An] John Kelsey, Bruce Schneier, David Wagner,
"KeySchedule Cryptanalysis of 3WAY, IDEA, GDES, RC4, SAFER, and TripleDES".
http://www.counterpane.com/key_schedule.html
 [An] Phillip Hawkes,
"DifferentialLinear Weak Key Classes of IDEA,"
Advances in Cryptology  EUROCRYPT '98 Proceedings, pp. 112126,
SpringerVerlag, 1998.
 [An] E. Biham, A. Biruykov, A. Shamir,
"Miss in the middle attacks on IDEA, Khufu and Khafre,"
Presented at Fast Software Encryption '99, Rome.
 [An] John Kelsey, Bruce Schneier, David Wagner, Chris Hall,
"Side Channel Cryptanalysis of Product Ciphers",
ESORICS '98 Proceedings pp. 97110,
SpringerVerlag, September 1998.
http://www.counterpane.com/side_channel.html
 [Inf, An] Ascom Systec, Ltd.
"Side Channel Attack Hardening of the IDEA^{TM} Cipher,"
Ascom Systec White Paper (corrected version, May 1999).
http://web.archive.org/web/20000823133119/www.ascom.ch/infosec/downloads/sidechannel.pdf
 [An] Jorge Nakahara Jr., Paulo Barreto, Bart Preneel, Joos Vandewalle,
Hae Y. Kim,
"SQUARE Attacks on ReducedRound PES and IDEA Block Ciphers,"
NESSIE Project phase 2 public report, 19 November 2001.
https://www.cosic.esat.kuleuven.ac.be/nessie/reports/phase2/nessieidea.pdf
 [An] Alex Biryukov, Jorge Nakahara Jr., Bart Preneel, Joos Vandewalle,
"New Weak Key Classes of IDEA,"
NESSIE Project phase 2 public report, 29 June 2002.
https://www.cosic.esat.kuleuven.ac.be/nessie/reports/phase2/keyidea5.pdf
 [Patent] James Massey, Xuejia Lai,
"Device for Converting a Digital Block and the Use Thereof",
International Patent WO09118459A2, filed May 16 1991, issued November 28 1991.
 [Patent] James Massey, Xuejia Lai,
"Device for Converting a Digital Block and the Use Thereof,"
European Patent EP00482154A1, filed May 16 1991, issued April 29 1992.
 [Patent] James Massey, Xuejia Lai,
"Device for Converting a Digital Block and the Use Thereof,"
European Patent EP00482154B1, filed May 16 1991, issued June 30 1993.
 [Patent] James Massey, Xuejia Lai,
"Device for the Conversion of a Digital Block and Use of Same",
U.S. Patent 5,214,703, filed January 7 1992, issued May 25 1993.
 [Patent] James Massey, Xuejia Lai,
[[filed Japanese Patent Application No. 508119/1991]]
 [Impl, Test] Ascom Systec, Ltd.
IDEA C Source Code and Test Data (corrected version, May 1999).
http://web.archive.org/web/20000816173624/www.ascom.ch/infosec/downloads.html
 Key length:
 128 bits.
 Block size:
 8 bytes.
 Comments:
 Security comment:
 IDEA is vulnerable to key schedule attacks, and therefore it should only
be used with keys that are generated by a strong RNG, or by a source of
bits that are sufficiently uncorrelated (such as the output of a hash
function).
 Patent status:
 IDEA is patented in the U.S and 9 European countries by Ascom Systec Ltd.,
with a patent pending in Japan.
 Designer:
 Robert J. Jenkins Jr.
 Published:
 1996
 References:
 [Def, An] Robert J. Jenkins Jr.,
ISAAC and RC4,
http://www.burtleburtle.net/bob/rand/isaac.html
 [Inf, An, Test, Impl] Robert J. Jenkins Jr.,
ISAAC: a fast cryptographic random number generator,
http://www.burtleburtle.net/bob/rand/isaacafa.html
 [Inf] Robert J. Jenkins Jr.,
"ISAAC,"
Fast Software Encryption, Third International Workshop,
Volume 1039 of Lecture Notes in Computer Science (D. Gollman, ed.),
pp. 4149. SpringerVerlag, 1996.
 Key length:
 ?
 Missing information:
 ISAAC does not appear to have a standard key schedule; this would need
to be specified for it to be usable as a SCAN algorithm. Test vectors would
also be needed.
 Designer:
 Robert J. Jenkins Jr.
 Published:
 1996
 References:
 [see references for ISAACBE]
 Key length:
 ?
 Missing information:
 [see ISAACBE]
× ISAAC64BE  Stream Cipher

 Designer:
 Robert J. Jenkins Jr.
 Published:
 1996
 References:
 Key length:
 ?
 Missing information:
 ISAAC64 does not appear to have a standard key schedule; this would need
to be specified for it to be usable as a SCAN algorithm. Test vectors would
also be needed.
× ISAAC64LE  Stream Cipher

 Designer:
 Robert J. Jenkins Jr.
 Published:
 1996
 References:
 [see references for ISAAC64BE]
 Key length:
 ?
 Missing information:
 [see ISAACBE]
 Designers:
 Hervé Chabanne, Emmanuel Michon
 Published:
 1998
 Description:
 This algorithm refers to JEROBOAM version 2.0.
 Alias:
 "JEROBOAM2.0"
 References:
 [Def, An] Hervé Chabanne, Emmanuel Michon,
"JEROBOAM",
Fast Software Encryption '98,
Volume 1372 of Lecture Notes in Computer Science (Serge Vaudenay, ed.), pp. 4959.
SpringerVerlag, 1998.
 [Def, An] Emmanuel Michon,
Rapport de stage d'option scientifique: étude cryptologique du
chiffreur JEROBOAM,
Ecole Polytechnique, June 1997.
 Key length:
 128 or 248 bits
 Missing information:
 I have not yet read either of the referenced papers, so I don't know whether
byteorder is specified, status of test vectors, etc.
× LEVIATHANBE  Stream Cipher

 Designers:
 David McGrew, Scott Fluhrer
 Published:
 October 2000
 Description:
 This is LEVIATHAN using bigendian byte order, when XORing the
keystream with the plaintext for encryption.
 References:
 Key length:
 128 or 256 bits
 Security comment:
 The output of LEVIATHAN can be distinguished from a random stream given
about ??? MBytes of output.
× LEVIATHANLE  Stream Cipher

 Designers:
 David McGrew, Scott Fluhrer
 Published:
 October 2000
 Description:
 This is LEVIATHAN using littleendian byte order, when XORing the
keystream with the plaintext for encryption.
 References:
 [see references for LEVIATHANBE]
 Key length:
 128 or 256 bits
 Security comment:
 [see Security comment for LEVIATHANBE]
 Designers:
 Laurence Brown,
Matthew Kwan,
Josef Pieprzyk,
Jennifer Seberry
 Published:
 199192
 References:
 [Def, An] Laurence Brown, Matthew Kwan, Josef Pieprzyk, Jennifer Seberry,
"Improving Resistance to Differential Cryptanalysis and the
Redesign of LOKI,"
Advances in Cryptology  ASIACRYPT '91 Proceedings,
SpringerVerlag, 1993, pp. 3650.
 [Inf] Bruce Schneier,
"Section 13.6 LOKI,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [An] Eli Biham,
"New Types of Cryptanalytic Attacks Using Related Keys,"
CS 753, Computer Science Department, Technion  Israel
Institute of Technology, September 1992.
http://www.cs.technion.ac.il/users/wwwb/cgibin/trget.cgi/1992/CS/CS0753.ps
 [An] Lars Knudsen,
"Cryptanalysis of LOKI91,"
Volume 718 of Lecture Notes in Computer Science, pp. 196208.
SpringerVerlag, 1992.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/loki91.ps.Z
 [An] Lars Knudsen,
"Block ciphers  analysis, design and applications,"
PhD. Thesis, DAIMI PB 485, Aarhus University, 1994.
 [An] Toshio Tokita, Tohru Sorimachi, Mitsuru Matsui,
"Linear cryptanalysis of LOKI and S2DES,"
Volume 917 of Lecture Notes in Computer Science, pp. 293306.
SpringerVerlag, 1994.
 [An] Lars Knudsen, M.J.B. Robshaw,
"Nonlinear Approximations in Linear Cryptanalysis,"
Volume 1070 of Lecture Notes in Computer Science, pp. 224236.
SpringerVerlag, 1996.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/nonlinear.ps.Z
 [An] Kouichi Sakurai, Souichi Furuya,
"Improving Linear Cryptanalysis of LOKI91 by Probabalistic Counting Method,"
Volume ??? of Lecture Notes in Computer Science.
SpringerVerlag, 1997.
 [An] Lars Knudsen,
"New potentially weak keys for DES and LOKI,"
Advances in Cryptology  EUROCRYPT '94 Proceedings,
Volume 950 of Lecture Notes in Computer Science (A. De Santis, ed.), pp. 419424.
Springer Verlag, 1995.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/potential.ps.Z
 Key length:
 64 bits.
 Block size:
 8 bytes.
 Security comments:
 LOKI91 is vulnerable to relatedkey attacks, with a work factor of about
2^{60} operations, and therefore it should only be used with keys
that are generated by a strong RNG, or by a source of bits that are
sufficiently uncorrelated (such as the output of a hash function).
 The attacks cited above based on Linear Cryptanalysis, are effective against
reducedround variants of LOKI91 with up to 12 rounds (the full cipher has 16 rounds).
 The fixed 64bit key length is too short to prevent bruteforce attacks.
 Designers:
 Laurence Brown,
Josef Pieprzyk,
Jennifer Seberry
 Published:
 1997
 References:
 [Def, An] Laurence Brown, Josef Pieprzyk,
Introducing the new LOKI97 Block Cipher,
http://www.adfa.oz.au/~lpb/research/loki97/loki97spec.ps
 [Inf, Impl] Laurence Brown,
The LOKI97 Block Cipher page,
http://www.adfa.oz.au/~lpb/research/loki97/
 [An] Vincent Rijmen, Lars Knudsen,
Weaknesses in LOKI97,
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/loki97.pdf
 [Test] NIST,
LOKI97 Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/loki97vals.zip
 Key length:
 128, 192 or 256 bits; default 128 bits.
 Block size:
 16 bytes.
 Security comment:
 The paper "Weaknesses in LOKI97" describes an attack using
Differential Cryptanalysis, estimated as requiring at most 2^{56}
chosen plaintexts, and an attack using Linear Cryptanalysis, estimated
as requiring at most 2^{56} known plaintexts.
 Designers:
 Michael Jacobson Jr.,
Klaus Huber
 Published:
 August 1998
 References:
 [Def, An] M.J. Jacobson Jr., K. Huber,
The MAGENTA Block Cipher Algorithm,
http://www.gel.ulaval.ca/~klein/maitrise/aes/magenta.pdf
 [An] Eli Biham, Alex Biryukov, Niels Ferguson, Lars Knudsen,
Bruce Schneier, Adi Shamir,
"Cryptanalysis of Magenta,"
Distributed at the first AES conference, August 20, 1998.
http://www.counterpane.com/magenta.html
 [Patent] [[need patent title]]
German Patent DE 44 25 158 A1, [[need date]].
 [Test] NIST,
MAGENTA Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/magentavals.zip
 Key length:
 128, 256, or 256 bits; default 128 bits.
 Block size:
 16 bytes.
 Security comment:
 The paper "Cryptanalysis of Magenta" describes a chosen plaintext
attack using 2^{64} chosen plaintexts, and 2^{64} work. It also
notes that "given a ciphertext, one can decrypt it by swapping its two halves,
reencrypting the result, and swapping again". This would be a fatal weakness
for some applications, even though it does not allow obtaining the key.
 Patent status:
 MAGENTA may be patented (see references).
 Designers:
 Carolynn Burwick, Don Coppersmith, Edward D'Avignon,
Rosario Gennaro,
Shai Halevi,
Charanjit Jutla, Stephen M. Matyas Jr., Luke O'Connor,
Mohammad Peyravian, David Safford, Nevenko Zunicof
 Published:
 August? 1999
 Description:
 This is the "tweaked" version of MARS submitted as a second round AES candidate.
 Alias:
 "MARS2"
 References:
 [Def, An] Carolynn Burwick, Don Coppersmith, Edward D'Avignon,
Rosario Gennaro, Shai Halevi, Charanjit Jutla, Stephen M. Matyas Jr.,
Luke O'Connor, Mohammad Peyravian, David Safford, Nevenko Zunicof,
"MARS  A candidate cipher for AES," (corrected version).
Available from
http://www.research.ibm.com/security/mars.html
[Note that the key schedule described here (in mars.pdf/.ps) is for the
initial version of MARS submitted as a first round AES candidate.]
 [Def] Shai Halevi,
"MARS key setup,"
http://www.research.ibm.com/security/keysetup.txt
 [An] Scott Contini, Yiqun Lisa Yin,
"On Differential Properties of DataDependent Rotations and
Their Use in MARS and RC6,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/contini.pdf
 [An] John Kelsey, Bruce Schneier,
"MARS Attacks! Preliminary Cryptanalysis of ReducedRound MARS Variants,"
Presented at the 3rd AES Candidate Conference.
http://www.counterpane.com/marsattacks.html
 [An] Eli Biham, Vladimir Furman,
"Impossible Differential on 8Round MARS' Core,"
March 15, 2000. Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/07ebiham.pdf
 [An] L. Burnett, G. Carter, E. Dawson, W. Millan,
"Efficient methods for generating MARSlike Sboxes,"
Presented at Fast Software Encryption 2000.
 [An] L. Knudsen, H. Raddum,
"Linear Approximations to MARS SBox,"
Submitted to NIST as an AES comment, April 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000407lknudsen.pdf
 [An] M. Robshaw, Y. Lin,
"Potential Flaws in the Conjectured Resistance of MARS to Linear Cryptanalysis,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000502mrobshaw.pdf
 [An] B. Preneel, A. Bosselaers, V. Rijmen, B. Van Rompay, L. Granboulan,
J. Stern, S. Murphy, M. Dichtl, P. Serf, E. Biham, O. Dunkelman, V. Furman,
F. Koeune, G. Piret, JJ. Quisquater, L. Knudsen, H. Raddum,
"Comments by the NESSIE Project on the AES Finalists,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000524bpreneel.pdf
 [An] IBM MARS Team,
"Comments on MARS's linear analysis,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000515ibm2.pdf
 [An] Tetsu Iwata, Kaoru Kurosawa,
"On the Pseudorandomness of AES Finalists  RC6, Serpent, MARS and Twofish,"
Presented at Fast Software Encryption 2000, New York.
 [An] John Kelsey, Tadayoshi Kohno, Bruce Schneier,
"Amplified Boomerang Attacks Against ReducedRound MARS and Serpent,"
Presented at Fast Software Encryption 2000, New York.
http://www.counterpane.com/boomerang.html
 [Patent] [[need patent title and date]]
U.S. Patent Application: IBM application CR998021.
 [Test] IBM Corporation,
New MARS Test Vectors,
http://www.research.ibm.com/security/testvectors/
 Key length:
 Minimum 128, maximum 448, multiple of 32 bits; default 128 bits.
 Block size:
 16 bytes.
 Patent status:
 IBM has a patent pending on MARS. It has said that "... we are making
MARS available on a royaltyfree basis, worldwide, regardless of AES outcome."
(See this
press release.) However, it is not clear whether "royaltyfree" excludes
the possibility of upfront license fees.
 Designer:
 Peter Gutmann
 Published:
 October 1992
 References:
 Key length:
 Minimum 64, maximum 640, multiple of 8 bits; default 128 bits.
 Missing information:
 Test vectors.
 Comments:
 With regard to buffering and use of IVs, MDC behaves identically to
the CFB mode of a block cipher. The length of the initialisation vector
is 16 bytes. Implementations MUST support immediate processing of
individual bytes.
 MDC has nothing to do with the cipher constructions MDC2 and MDC4
designed at IBM (which do not have SCAN standard names).
 Security comment:
 A new random IV should be used for each message encrypted under a given key.
MISTY1[(rounds)]  Block Cipher

 Designer:
 M. Matsui
 Published:
 January 1997
 References:
 [Def] M. Matsui,
"New Block Encryption Algorithm MISTY,"
4th Fast Software Encryption Workshop, January 1997.
http://www.mitsubishi.com/ghp_japan/misty/misty_e_b.pdf,
.ps
 [Inf] Mitsubishi Electric,
MISTY home page,
http://www.mitsubishi.com/ghp_japan/misty/200misty.htm
 [Inf] M. Matsui,
"Block Encryption Algorithm MISTY," (in Japanese)
Technical Report of IEICE, ISEC9611 (199607).
http://www.mitsubishi.com/ghp_japan/misty/misty_j_b.pdf,
.ps
 [Inf] M. Matsui,
"New Structure of Block Ciphers with Provable Security against Differential
and Linear Cryptanalysis,"
3rd Fast Software Encryption Workshop, February 1996.
 Parameters:

Integer rounds
[creation/read, default 8]  the number
of rounds to be performed (minimum 8, multiple of 4)
 Key length:
 128 bits.
 Block size:
 8 bytes.
? MISTY2[(rounds)]  Block Cipher

 Designer:
 M. Matsui
 Published:
 January 1997
 References:
 [Def] M. Matsui,
"New Block Encryption Algorithm MISTY,"
4th Fast Software Encryption Workshop, January 1997.
http://www.mitsubishi.com/ghp_japan/misty/misty_e_b.pdf,
.ps
 [Inf] Mitsubishi Electric,
MISTY home page,
http://www.mitsubishi.com/ghp_japan/misty/200misty.htm
 [Inf] M. Matsui,
"Block Encryption Algorithm MISTY," (in Japanese)
Technical Report of IEICE, ISEC9611 (199607).
http://www.mitsubishi.com/ghp_japan/misty/misty_j_b.pdf,
.ps
 [Inf] M. Matsui,
"New Structure of Block Ciphers with Provable Security against Differential
and Linear Cryptanalysis,"
3rd Fast Software Encryption Workshop, February 1996.
 Parameters:

Integer rounds
[creation/read, default 12]  the number
of rounds to be performed (minimum 12, multiple of 4)
 Key length:
 128 bits.
 Block size:
 8 bytes.
 Missing information:
 Test vectors.
Noekeon[(rounds)]  Block Cipher

 Designers:
 Joan Daemen,
Michaël Peeters,
Gilles van Assche,
Vincent Rijmen
 Published:
 November 2000
 References:
 [Def, An] Joan Daemen, Michaël Peeters, Gilles van Assche, Vincent Rijmen,
The Noekeon Block Cipher,
Presented at the First Open NESSIE Workshop, November 2000.
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/noekeon.zip
 [Inf] Proton World,
Research: Noekeon, a 128bit block cipher,
http://www.protonworld.com/research/noekeon/
 [Test] Joan Daemen, Michaël Peeters, Gilles van Assche, Vincent Rijmen,
Noekeon Test Values,
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/noekeon.zip
 Parameters:

Integer rounds
[creation/read, default 16]  the number
of rounds to be performed (minimum 16)
 Key length:
 128 bits.
 Block size:
 16 bytes.
NoekeonDirect[(rounds)]  Block Cipher

 Designers:
 Joan Daemen,
Michaël Peeters,
Gilles van Assche,
Vincent Rijmen
 Published:
 November 2000
 Description:
 This is the "directkey" variant of Noekeon, i.e. where the working key
is provided directly. This key should be generated at random, or as the
output of a hash or PRF.
 References:
 [Def, An] Joan Daemen, Michaël Peeters, Gilles van Assche, Vincent Rijmen,
The Noekeon Block Cipher,
http://www.cryptonessie.org/submissions/noekeon/noekeon.zip
 [Inf, Test] Joan Daemen, Vincent Rijmen,
The Noekeon Page,
http://www.esat.kuleuven.ac.be/~rijmen/noekeon/
 [Test] NIST,
Noekeon Test Values,
http://www.cryptonessie.org/submissions/noekeon/noekeon.zip
 Parameters:

Integer rounds
[creation/read, default 16]  the number
of rounds to be performed (minimum 16)
 Key length:
 128 bits.
 Block size:
 16 bytes.
 Designers:
 Joan Daemen,
Craig Clapp
 Published:
 1998
 References:
 [Def, An] Joan Daemen, Craig Clapp,
"Fast Hashing and Stream Encryption with Panama,"
Fast Software Encryption '98,
Volume 1372 of Lecture Notes in Computer Science (Serge Vaudenay, ed.), pp. 6074.
SpringerVerlag, 1998.
http://standard.pictel.com/ftp/research/security/panama.pdf
 [Inf] Joan Daemen,
Panama reference implementation (in C),
http://www.esat.kuleuven.ac.be/~rijmen/daemen/panama.zip
 Key length:
 256 bits.
 Missing information:
 Test vectors (
panama.zip
only contains test vectors for hashing).
 Comment:
 Panama makes use of a "diversification parameter" that is appended to the key.
This is handled by treating the diversification parameter as an IV (which can
be set in the same way as would be used for a block cipher).
Note that this implies that an implementation must save the user key (or the
state of the cipher after loading this key), in order to ensure that more than
one call to setIV
can be made without having to reinitialise the
cipher object.
 Designers:
 ChangHyi Lee, JeongSoo Kim
 References:
 Key length:
 Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 16 bytes.
 Missing information:
 Test vectors.
 Comment:
 Only the 128bit block version is defined as a SCAN algorithm.
 Designer:
 Ron Rivest
 Published:
 1998
 References:
 [Def] Ron Rivest,
"A Description of the RC2(r) Encryption Algorithm,"
RFC 2268, March 1998.
 [An] L.R. Knudsen, V. Rijmen, R.L. Rivest, M.J.B. Robshaw,
"On the design and security of RC2,"
Fast Software Encryption,
Volume 1372 of Lecture Notes in Computer Science (Serge Vaudenay, ed.), pp. 206221.
SpringerVerlag, 1998.
http://www.esat.kuleuven.ac.be/~cosicart/ps/VR9800.ps.gz
 [An] John Kelsey, Bruce Schneier, David Wagner,
"RelatedKey Cryptanalysis of 3WAY, BihamDES, CAST, DESX, NewDES, RC2, and TEA",
ICICS '97 Proceedings, SpringerVerlag, November 1997.
http://www.counterpane.com/relatedkey_cryptanalysis.html
 Key length:
 Minimum 0; maximum 1024, multiple of 8 bits; default 128 bits.
 Block size:
 8 bytes.
 Comment:
 The value of the key's
effectiveBitLength
parameter may be different
from 8 * (length of key encoding in bytes), to allow compatibility with other RC2
implementations. However, RC2 KeyGenerators should always generate keys such that
the length of the encoding is equal to (effectiveBitLength + 7) / 8
bytes.
(To create keys that do not satisfy this constraint, an application has to construct
a SecretKey object directly.)
Note that the table given in section 6 of RFC 2268 plays no part in determining
the number of effective bits (and also, the default key length is 128 bits,
not 32 as implied by that section).
 Security comment:
 RC2 is vulnerable to relatedkey attacks, and therefore it should only
be used with keys that are generated by a strong RNG, or by a source of
bits that are sufficiently uncorrelated (such as the output of a hash
function).
 Designer:
 Ron Rivest
 Published:
 September 1994 (see Comment section below)
 Alias:
 "ARCFOUR"
 References:
 [Def] Bruce Schneier,
"Section 17.1 RC4,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Def] Anonymous,
Subject: RC4 Algorithm revealed,
Posting to Usenet newsgroups sci.crypt, alt.security, comp.security.misc,
and alt.privacy, September 14 1994 (reposting of a message to the
cipherpunks mailing list).
MessageID: <sternCvKL4B.Hyy@netcom.com>
Archived at
ftp://idea.sec.dsi.unimi.it/pub/security/crypt/code/rc4.revealed.gz
 [An] Hal Finney,
Subject: An RC4 cycle that can't happen,
Posting to sci.crypt, 18 September 1994.
MessageID: <35hq1u$c72@news1.shell>
 [An] David Wagner,
Subject: Re: Weak Keys in RC4,
Posting to sci.crypt, 26 September 1995.
MessageID: <447o1l$cbj@cnn.Princeton.EDU>
Archived at
http://www.cs.berkeley.edu/~daw/myposts/myrc4weakkeys
 [An] Andrew Roos <andrewr@vironix.co.za>,
A Class of Weak Keys in the RC4 Stream Cipher,
November 1997.
http://www.tik.ee.ethz.ch/~mwa/RC4/WeakKeys.txt
(Also two postings to sci.crypt in 1995; MessageIDs
<43u1eh$1j3@hermes.is.co.za> and <44ebge$llf@hermes.is.co.za>.)
 [An] John Kelsey, Bruce Schneier, David Wagner,
"KeySchedule Cryptanalysis of 3WAY, IDEA, GDES, RC4, SAFER, and TripleDES".
http://www.counterpane.com/key_schedule.html
 [An] Jovan Goli,
"Linear Statistical Weakness of Alleged RC4 Keystream Generator,"
Advances in Cryptology  EUROCRYPT '97 Proceedings,
Volume 1233 of Lecture Notes in Computer Science (W. Fumy, ed.)
SpringerVerlag, 1997.
http://www.wisdom.weizmann.ac.il/~itsik/RC4/Golic.PDF
 [An] Lars Knudsen, Willi Meier, Bart Preneel, Vincent Rijmen, Sven Verdoolaege,
"Analysis Methods for (Alleged) RC4,"
Advances in Cryptology  ASIACRYPT '98 Proceedings,
Volume 1514 of Lecture Notes in Computer Science (K. Ohta, D. Pei, eds.),
pp. 327341. SpringerVerlag, 1998.
http://www.wisdom.weizmann.ac.il/~itsik/RC4/Knudsen.ps or
http://www.esat.kuleuven.ac.be/~cosicart/ps/VR9801.ps.gz
 [An] Serge Mister,
"Cryptanalysis of RC4like Ciphers,"
Master's Thesis, Queen's University, Kingston, Ontario, Canada. May 1998.
 [An] Serge Mister, Stafford Tavares,
"Cryptanalysis of RC4like Ciphers,"
Workshop Record of the Workshop on Selected Areas in Cryptography
(SAC '98), August 1718 1998, pp. 136148.
Abstract only at
http://www.ncf.carleton.ca/~cf744/pub.html
 [An] Alexander L. Grosul, Dan S. Wallach,
"A RelatedKey Cryptanalysis of RC4,"
Rice University TR00358, June 2000.
http://www.wisdom.weizmann.ac.il/~itsik/RC4/GrosulWallach.ps
 [An] Scott Fluhrer, David McGrew,
"Statistical Analysis of the Alleged RC4 Keystream Generator,"
Presented at Fast Software Encryption 2000, New York.
http://www.mindspring.com/~dmcgrew/rc403.pdf
 [An] Itsik Mantin, Adi Shamir,
"A Practical Attack on Broadcast RC4,"
Presented at Fast Software Encryption 2001.
http://www.wisdom.weizmann.ac.il/~itsik/RC4/bc_rc4.ps
 [An] Scott Fluhrer, Itsik Mantin, Adi Shamir,
"Weaknesses in the Key Scheduling Algorithm of RC4,"
In Proceedings of SAC 2001, Eighth Annual Workshop on
Selected Areas in Cryptography (Toronto, Ontario, Canada,
August 2001), pp. 124.
http://www.crypto.com/papers/others/rc4_ksaproc.ps
 [An] Itsik Mantin,
"Analysis of the stream cipher RC4,"
Master's Thesis, Weizmann Insitute, Israel, 2001.
 [An] G. Durfee,
"Distinguishers for the RC4 stream cipher,"
Manuscript, 2001.
 [An] Ilya Mironov,
"(Not So) Random Shuffles of RC4 (full version),"
IACR eprint 2002/067.
http://eprint.iacr.org/2002/067/
 Key length:
 Minimum 8, maximum 2048, multiple of 8 bits; default 128 bits.
 Comment:
 For the purposes of SCAN, "RC4" will refer to the cipher described in
the "RC4 Algorithm revealed" article and in
Applied Cryptography, even in the unlikely event that
differences are found between that cipher, and RSA Security, Inc.'s
proprietary cipher of the same name.
 Security comments:
 There are small biases at the start of the RC4 keystream; see the
paper by Ilya Mironov, and the security comments for
RC4drop for further discussion.
 The RC4 keystream is distinguishable from random given about 2 Gbytes of
the stream.
 RC4 is vulnerable to relatedkey attacks, and therefore it should only
be used with keys that are generated by a strong RNG, or by a source of
bits that are sufficiently uncorrelated (such as the output of a hash
function).
RC4drop[(nbytes)]  Stream Cipher

 Description:
 This algorithm is the same as RC4, except that the first nbytes
bytes of keystream are discarded after key scheduling.
 Alias:
 "MARK4" is an alias for RC4drop(256).
 References:
 Parameters:

Integer nbytes
[creation/read, default 768]  the number
of bytes to be dropped after key scheduling (minimum 0, maximum 65536)
 Key length:
 Minimum 8, maximum 2048, multiple of 8 bits; default 128 bits.
 Comments:
 For the purposes of SCAN, "RC4drop" will be based on the "RC4" cipher
described in in the "RC4 Algorithm revealed" article and in
Applied Cryptography, even in the unlikely event that
differences are found between that cipher, and RSA Security, Inc.'s
proprietary cipher of the same name.
 The alias "MARK4" for RC4drop(256) was apparently suggested by
Bryan Olson, in a posting to sci.crypt. In SCAN 1.0.15, "MARK4" was
a standard name rather than an alias; this is technically an
incompatible change.
 Security comments:
RC5[(rounds)]  Block Cipher

 Designer:
 Ron Rivest
 Published:
 January 1995
 Alias:
 "RC532"
 References:
 [Inf] Ron Rivest,
"The RC5 Encryption Algorithm,"
Dr. Dobb's Journal, vol. 20 no. 1, pp. 146148.
January 1995.
 [Def] Ron Rivest,
"The RC5 Encryption Algorithm,"
Revised 20 March 1997.
http://theory.lcs.mit.edu/~rivest/publications.html
(Postscript,
PDF,
correction note)
 [Def, Test] Ron Rivest,
"The RC5, RC5CBC, RC5CBCPad, and RC5CTS Algorithms,"
RFC 2040, October 1996.
 [Inf] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
"Section 7.7.2 RC5,"
Handbook of Applied Cryptography,
CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf,
.ps
 [Patent] RSA Security, Inc. (assignee),
"Block Encryption Algorithm with DataDependent Rotations,"
U.S. Patent 5,724,428, filed November 1 1995, issued March 3 1998.
 [Patent] RSA Security, Inc. (assignee),
"Block Encryption Algorithm with DataDependent Rotations,"
U.S. Patent 5,835,600, filed April 21 1997, issued November 10 1998.
 [An] B.S. Kaliski, Y.L. Yin,
"On Differential and Linear Cryptanalysis of the RC5 Encryption Algorithm",
Advances in Cryptology  CRYPTO '95, pp. 171184.
SpringerVerlag, 1995.
 [An] Lars Knudsen, W. Meier,
"Improved differential attack on RC5,"
Advances in Cryptology  CRYPTO '96 Proceedings,
Volume 1109 of Lecture Notes in Computer Science (N. Koblitz, ed.), pp. 216228.
SpringerVerlag, 1996.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/rc5.ps.Z
 [An] Howard Heys,
"Linearly Weak Keys of RC5,"
IEE Electronics Letters, vol. 33, no. 10, pp. 836838, 1997.
http://www.engr.mun.ca/~howard/PAPERS/rc5_letter.ps
 [An] A. Biryukov, E. Kushilevitz,
"Improved Cryptanalysis of RC5,"
Advances in Cryptology  EuroCrypt '98.
http://www.cs.technion.ac.il/~eyalk/alex.ps.Z
 [An] A. A. Selcuk,
"New results in linear cryptanalysis of RC5,"
Fast Software Encryption  Fifth International Workshop,
Paris, France, LNCS. SpringerVerlag, 1998.
 [An] Helena Handschuh, Howard Heys
"A Timing Attack on RC5,"
Workshop on Selected Areas in Cryptography  SAC '98,
Queen's University, Kingston, Ontario, Aug. 1998.
To be published by SpringerVerlag.
http://www.enst.fr/~handschu/rc5.ps
 [An] B.S. Kaliski Jr., Y.L. Yin,
"On the Security of the RC5 Encryption Algorithm,"
RSA Laboratories Technical Report TR602, 1998.
ftp://ftp.rsasecurity.com/pub/rsalabs/rc5/rc5report.pdf
 [An] Takeshi Shimoyama, Kiyofumi Takeuchi, Juri Hayakawa,
"Correlation Attack to the Block Cipher RC5 and the Simplified
Variants of RC6,"
Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/36tshimoyama.pdf
 [An] Borst, Preneel, Vandewalle,
"Linear cryptanalysis of RC5 and RC6,"
Presented at Fast Software Encryption '99, Rome.
 [An] John Kelsey, Bruce Schneier, David Wagner,
"Mod n cryptanalysis, with applications against RC5P and M6,"
Presented at Fast Software Encryption '99, Rome.
 Parameters:

Integer rounds
[creation/read, default 12]  the number
of rounds to be performed (minimum 12, multiple of 2)
 Key length:
 Minimum 0; maximum 2040, multiple of 8 bits; default 128 bits.
 Block size:
 8 bytes.
 Comments:
 The block size could have been specified as a parameter; however it is
unlikely that RC5 could be efficiently implemented with multiple block
sizes sharing the same code, and therefore two different algorithms are
specified (RC5 and RC564). Also note that the default (and minimum)
number of rounds is different (12 vs 16).
 The maximum key length is restricted to 2040 bits (see the
RSA
Labs FAQ entry for RC5); this is an incompatible change since SCAN 1.0.11.
 Security comment:
 The paper "On the Security of the RC5 Encryption Algorithm" cited above
gives an overview of cryptanalysis results against RC5 up to 1998.
 Patent status:
 RC5 and RC564 are patented by RSA Security, Inc.
? RC564[(rounds)]  Block Cipher

 Designer:
 Ron Rivest
 Published:
 January 1995
 References:
 [see references for RC5]
 Parameters:

Integer rounds
[creation/read, default 16]  the number
of rounds to be performed (minimum 16, multiple of 2)
 Key length:
 Minimum 0; maximum 2040, multiple of 8 bits; default 128 bits.
 Block size:
 16 bytes.
 Missing information:
 Test vectors.
 Comments:
 The block size could have been specified as a parameter; however it is
unlikely that RC5 could be efficiently implemented with multiple block
sizes sharing the same code, and therefore two different algorithms are
specified (RC5 and RC564). Also note that the default (and minimum)
number of rounds is different (12 vs 16).
 The maximum key length is restricted to 2040 bits (see the
RSA
Labs FAQ entry for RC5); this is an incompatible change since SCAN 1.0.11.
 Patent status:
 RC5 and RC564 are patented by RSA Security, Inc.
RC6[(rounds)]  Block Cipher

 Designers:
 Ron Rivest,
Matthew Robshaw,
Raymond Sidney,
Yiqun Lisa Yin
 Published:
 1998?
 Alias:
 "RC632"
 References:
 [Def, An] Ron Rivest, Matthew Robshaw, Raymond Sidney, Yiqun Lisa Yin,
The RC6 Block Cipher,
http://theory.lcs.mit.edu/~rivest/rc6.pdf
 [An] Ron Rivest,
Further notes on RC6,
http://theory.lcs.mit.edu/~rivest/rc6notes.txt
 [An] Scott Contini, Ron Rivest, Matthew Robshaw, Yiqun Lisa Yin,
The Security of RC6,
http://www.rsasecurity.com/rsalabs/aes
 [An] Scott Contini, Yiqun Lisa Yin,
"On Differential Properties of DataDependent Rotations and
Their Use in MARS and RC6,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/contini.pdf
 [An] MarkkuJuhani Saarinen,
"A note regarding the hash function use of MARS and RC6,"
http://www.cc.jyu.fi/~mjos/sshnote.pdf
 [An] Willi Meier, Lars Knudsen,
"Correlations in RC6,"
July 29, 1999.
http://www.ii.uib.no/~larsr/papers/rc6.ps or
http://csrc.nist.gov/encryption/aes/round2/comments/19990812lknudsen.pdf
 [An] Takeshi Shimoyama, Kiyofumi Takeuchi, Juri Hayakawa,
"Correlation Attack to the Block Cipher RC5 and the Simplified
Variants of RC6,"
Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/36tshimoyama.pdf
 [An] Contini, Rivest, Robshaw, Yin,
"Improved analysis of some simplified variants of RC6,"
Presented at Fast Software Encryption '99, Rome.
 [An] Borst, Preneel, Vandewalle,
"Linear cryptanalysis of RC5 and RC6,"
Presented at Fast Software Encryption '99, Rome.
 [An] Henri Gilbert, Helena Handschuh, Antoine Joux, Serge Vaudenay,
"A Statistical Attack on RC6,"
Presented at Fast Software Encryption 2000, New York.
 [An] Tetsu Iwata, Kaoru Kurosawa,
"On the Pseudorandomness of AES Finalists  RC6, Serpent, MARS and Twofish,"
Presented at Fast Software Encryption 2000, New York.
 [Patent] RSA Security, Inc. (assignee),
"Block Encryption Algorithm with DataDependent Rotations,"
U.S. Patent 5,724,428, filed November 1 1995, issued March 3 1998.
 [Patent] RSA Security, Inc. (assignee),
"Block Encryption Algorithm with DataDependent Rotations,"
U.S. Patent 5,835,600, filed April 21 1997, issued November 10 1998.
 [Patent] RSA Security, Inc. (assignee),
"Enhanced Block Encryption Algorithm with DataDependent Rotations,"
U.S. Patent Application 09/094,649. Filed June 15, 1998.
 [Test] NIST,
RC6 Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/rc6vals.zip
 Parameters:

Integer rounds
[creation/read, default 20]  the number
of rounds to be performed (minimum 8, multiple of 4)
 Key length:
 Minimum 0; maximum 2040, multiple of 8 bits; default 128 bits.
 Block size:
 16 bytes.
 Comments:
 The block size could have been specified as a parameter; however it is
unlikely that RC6 could be efficiently implemented with multiple block
sizes sharing the same code, and therefore two different algorithms are
specified (RC6 and RC664).
 Patent status:
 RSA Security, Inc., has several patents pending on RC6 (covering all
versions).
? RC664[(rounds)]  Block Cipher

 Designers:
 Ron Rivest,
Matthew Robshaw,
Raymond Sidney,
Yiqun Lisa Yin
 Published:
 1998?
 References:
 [see references for RC6]
 Parameters:

Integer rounds
[creation/read, default 20]  the number
of rounds to be performed (minimum 8, multiple of 4)
 Key length:
 Minimum 0; maximum 2040, multiple of 8 bits; default 128 bits.
 Block size:
 32 bytes.
 Missing information:
 Test vectors.
 Comments:
 The block size could have been specified as a parameter; however it is
unlikely that RC6 could be efficiently implemented with multiple block
sizes sharing the same code, and therefore two different algorithms are
specified (RC6 and RC664).
 Patent status:
 RSA Security, Inc., has several patents pending on RC6 (covering all
versions).
 Designers:
 Joan Daemen,
Vincent Rijmen
 Published:
 November 1998
 Description:
 This is Rijndael with a 128bit block size. The number of rounds is
6 + max(Nk, Nb), where Nb = 4, and Nk is the number of 32bit words in the key.
 References:
 [Def, An] Joan Daemen, Vincent Rijmen,
AES Proposal: Rijndael (corrected version),
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaeldocV2.zip
 [An] Joan Daemen, Vincent Rijmen,
Annex to AES Proposal: Rijndael,
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/PropCorr.PDF
 [An] Stefan Lucks,
"Attacking Seven Rounds of Rijndael under 192bit and 256bit Keys,"
Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/04slucks.pdf
 [An] Henri Gilbert, Marine Minier,
"A collision attack on 7 rounds of Rijndael,"
Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/11hgilbert.pdf
 [An] Makoto Sugita, Kazukuni Kobara, Kazuhiro Uehara, Shuji Kubota,
Hideki Imai,
"Relationships among Differential, Truncated Differential,
Impossible Differential Cryptanalyses against WordOriented
Block Ciphers like Rijndael, E2,"
Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/32msugita.pdf
 [An] Eli Biham, Nathan Keller,
"Cryptanalysis of Reduced Variants of Rijndael,"
Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/35ebiham.pdf
 [An] Niels Ferguson, John Kelsey, Stefan Lucks, Bruce Schneier,
Mike Stay, David Wagner, Doug Whiting,
"Improved Cryptanalysis of Rijndael,"
Proceedings of FSE 2000.
http://www.counterpane.com/rijndael.html
 [An] Sean Murphy, Matt Robshaw,
"New observations on Rijndael,"
August 7, 2000.
http://www.isg.rhbnc.ac.uk/~mrobshaw/rijndael.html
http://www.cs.rhbnc.ac.uk/~sean/
 [An] Joan Daemen, Vincent Rijmen,
"Answer to 'new observations on Rijndael',"
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/answer.pdf
 [An] Sean Murphy, Matt Robshaw,
"Further Comments on the Structure of Rijndael,"
http://www.cs.rhbnc.ac.uk/~sean/
 [An] Joan Daemen, Vincent Rijmen,
"The AES second round Comments of the Rijndael Team,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000512jdaemen.pdf
 [An] F. Koeune, J.J. Quisquater,
"A timing attack against Rijndael,"
UCL/DICE Crypto Group Technical Report CG1999/1.
http://www.dice.ucl.ac.be/crypto/techreports.html#1999
 [An] L. Keliher, I. Meijer, S. Tavares,
"Improving the upper bound on the maximum average linear hull
probability for Rijndael,"
To be presented at Selected Areas in Cryptography 2001,
Toronto, Ontario, Canada.
 [An] Niels Ferguson, Richard Schroeppel, Doug Whiting,
"A simple algebraic representation of Rijndael,"
To be presented at Selected Areas in Cryptography 2001,
Toronto, Ontario, Canada.
Draft at
http://www.xs4all.nl/~vorpal/pubs/rdalgeq.html
 Nicolas Courtois, Josef Pieprzyk,
"Cryptanalysis of Block Ciphers with Overdefined Systems of Equations,"
IACR eprint 2002/044, 23 July 2002.
http://eprint.iacr.org/2002/044/
 Eric Filiol,
"A New Statistical Testing for Symmetric Ciphers and Hash Functions,"
IACR eprint 2002/099, 23 July 2002.
http://eprint.iacr.org/2002/099/
 [An] Joanne Fuller, William Millan,
"On Linear Redundancy in the AES SBox,"
IACR eprint 2002/111, 5 August 2002.
http://eprint.iacr.org/2002/111/
 [An] Sean Murphy, Matt Robshaw,
"Essential Algebraic Structure within the AES,"
June 5, 2002.
http://www.isg.rhbnc.ac.uk/~mrobshaw/rijndael.html
 [An] R. Wernsdorf,
"The round functions of Rijndael generate the alternating group,"
In Proceedings of Fast Software Encryption (Vincent Rijmen, ed.)
LNCS, SpringerVerlag, to appear.
 [Inf] www.minrank.org,
The XSL attack on AES/Rijndael (collection of links to relevant papers),
http://www.minrank.org/aes/
 [Inf, Test] Joan Daemen, Vincent Rijmen,
The Rijndael Page,
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
 [Test] NIST,
Rijndael Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/rijndaelvals.zip
 [Test] Brian Gladman,
aesdvec.zip
(Rijndael test vectors for all block and key sizes),
http://fp.gladman.plus.com/cryptography_technology/rijndael/
 Key length:
 Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 16 bytes.
 Comments:
 The range of specified key lengths has been extended since SCAN 1.0.12
(which only specified 128, 192 and 256 bits). This is an incompatible
change for the key lengths that were not previously supported.
 Rijndael is pronounced approximately as "Rhinedahl".
Rijndael160  Block Cipher

 Designers:
 Joan Daemen,
Vincent Rijmen
 Published:
 November 1998
 Description:
 This is Rijndael with a 160bit block size. The number of rounds is
6 + max(Nk, Nb), where Nb = 5, and Nk is the number of 32bit words in the key.
 References:
 [see references for Rijndael]
 Key length:
 Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 20 bytes.
 Comments:
 [see comments for Rijndael]
Rijndael192  Block Cipher

 Designers:
 Joan Daemen,
Vincent Rijmen
 Published:
 November 1998
 Description:
 This is Rijndael with a 192bit block size. The number of rounds is
6 + max(Nk, Nb), where Nb = 6, and Nk is the number of 32bit words in the key.
 References:
 [see references for Rijndael]
 Key length:
 Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 24 bytes.
 Comments:
 [see comments for Rijndael]
Rijndael224  Block Cipher

 Designers:
 Joan Daemen,
Vincent Rijmen
 Published:
 November 1998
 Description:
 This is Rijndael with a 224bit block size. The number of rounds is
6 + max(Nk, Nb), where Nb = 7, and Nk is the number of 32bit words in the key.
 References:
 [see references for Rijndael]
 Key length:
 Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 28 bytes.
 Comments:
 [see comments for Rijndael]
Rijndael256  Block Cipher

 Designers:
 Joan Daemen,
Vincent Rijmen
 Published:
 November 1998
 Description:
 This is Rijndael with a 256bit block size. The number of rounds is
always 14.
 References:
 [see references for Rijndael]
 Key length:
 Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
 Block size:
 32 bytes.
 Comments:
 [see comments for Rijndael]
SAFERK[(rounds)]  Block Cipher

 Designer:
 James Massey
 Published:
 December 1993.
 Description:
 This algorithm refers to the original version of SAFER, designed
in 1993.
 References:
 [Def] Massey, J. L.,
"SAFER K64: A ByteOriented Block Ciphering Algorithm",
Fast Software Encryption (Ross Anderson, ed.),
Proceedings of the Cambridge Security Workshop, Cambridge,
U.K., December 911, 1993, pp. 117.
Volume 809 of Lecture Notes in Computer Science,
Springer, 1994.
 [Inf] Massey, J. L.,
"SAFER K64: One Year Later",
Preliminary manuscript of a paper presented at the K. U. Leuven
Workshop on Cryptographic Algorithms, December 1416, 1994.
To be published in the Proceedings of this workshop by Springer.
 [Inf] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
"Section 7.7.1 SAFER,"
Handbook of Applied Cryptography,
CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap7.pdf,
.ps
 [Inf, Test, Impl] Richard De Moliner,
SAFER toolkit V1.2.
Includes C implementation, additional notes, test data, test program.
ftp://ftp.isi.ee.ethz.ch/pub/simpl/safer.V1.2.tar.Z
 [An] Lars Knudsen,
"A KeySchedule Weakness in SAFER K64",
Advances in Cryptology  CRYPTO '95 Proceedings,
Volume 963 of Lecture Notes in Computer Science, SpringerVerlag, 1995.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/saferkey.ps.Z
(appendix with corrections:
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/tillaeg.ps.Z)
 [An] John Kelsey, Bruce Schneier, David Wagner,
"KeySchedule Cryptanalysis of 3WAY, IDEA, GDES, RC4, SAFER, and TripleDES".
http://www.counterpane.com/key_schedule.html
 [also see cryptanalysis references for SAFERSK]
 Parameters:

Integer rounds
[creation/read, default null (indicating keylengthdependent)] 
the number of rounds to be performed (minimum 6). When the value of this property is null,
6 rounds are used for a 64bit key, and 10 rounds for a 128bit key.
 Key length:
 64 or 128 bits; default 128 bits.
 Block size:
 8 bytes.
 Comment:
 Conventionally, the key length for SAFER is included in the algorithm
name, e.g. "SAFER K64", "SAFER K128", etc. Because a SCAN algorithm
may have variablelength keys, all of these are referred to as
"SAFERK".
 Security comment:
 As a result of the key schedule attack by Lars Knudsen cited above, SAFERK has
been superceded by SAFERSK.
SAFERSK[(rounds)]  Block Cipher

 Designer:
 James Massey
 Published:
 September 1995.
 Description:
 This algorithm refers to the version of SAFER with a
strengthened key schedule, designed in 1995 (see SAFER_SK.TXT,
cited below).
 Alias:
 "OpenPGP.Cipher.6" for SAFERSK(13).
 References:
 [Def (excluding key schedule)] Massey, J. L.,
"SAFER K64: A ByteOriented Block Ciphering Algorithm",
Fast Software Encryption (Ross Anderson, ed.),
Proceedings of the Cambridge Security Workshop, Cambridge,
U.K., December 911, 1993, pp. 117.
Volume 809 of Lecture Notes in Computer Science,
Springer, 1994.
 [Def] Massey, J. L.,
"Announcement of a Strengthened Key Schedule for the Cipher SAFER",
September 9, 1995, (see file 'SAFER_SK.TXT' included in the SAFER
toolkit, below).
 [Inf, Test, Impl] Richard De Moliner,
SAFER toolkit V1.2.
Includes C implementation, additional notes, test data, test program.
ftp://ftp.isi.ee.ethz.ch/pub/simpl/safer.V1.2.tar.Z
 [An] C. Harpes,
"A Generalization of Linear Cryptanalysis Applied to SAFER,"
Internal report, Signal and Information Processing Lab., Swiss Federal Institute
of Technology, Zurich, March 9, 1995.
http://www.isi.ee.ethz.ch/~harpes/GLCsafer.ps
 [An] Serge Vaudenay,
"On the need for multipermutations: cryptanalysis of MD4 and SAFER,"
Fast Software Encryption, Leuven Workshop,
Volume 1008 of Lecture Notes in Computer Science, pp. 286297.
SpringerVerlag, 1995.
 [An] Lars Knudsen, T.A. Berson,
"Truncated differentials of SAFER,"
Fast Software Encryption,
Volume 1039 of Lecture Notes in Computer Science (D. Gollmann, ed.), pp. 1526.
SpringerVerlag, 1996.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/trunc_dif_saf.ps.Z
 [An] John Kelsey, Bruce Schneier, David Wagner,
"KeySchedule Cryptanalysis of 3WAY, IDEA, GDES, RC4, SAFER, and TripleDES".
http://www.counterpane.com/key_schedule.html
 [An] Jorge Nakahara Jr., Bart Preneel, Joos Vandewalle,
"Linear Cryptanalysis of ReducedRound Versions of the SAFER Block Cipher
Family,"
Presented at Fast Software Encryption 2000, New York.
 Parameters:

Integer rounds
[creation/read, default null (indicating keylengthdependent)] 
the number of rounds to be performed (minimum 8). When the value of this property is null,
8 rounds are used for a 64bit key, and 10 rounds for a 128bit key.
 Key length:
 64 or 128 bits; default 128 bits.
 Block size:
 8 bytes.
 Comments:
 Conventionally, the key length for SAFER with strengthened key schedule is
included in the algorithm name, e.g. "SAFER SK64", "SAFER SK128", etc.
Because a SCAN algorithm may have variablelength keys, all of these are
referred to as "SAFERSK".
 SAFER_SK.TXT suggests a maximum of 10 rounds for a 64bit key, and 12 rounds for a
128bit key; however here we do not specify any limit on the number of
rounds. Also note that because the number of rounds can be given in the algorithm
name before the key length is known, it is possible to use a 128bit key with 8
or 9 rounds (i.e. less than the default), but this is definitely not recommended.
 A 40bit key schedule has also been specified for SAFERSK; this is not required to
be implemented, and application designers should not assume that a SAFERSK
implementation will support 40bit keys.
 Designers:
 James Massey, Gurgen Khachatrian, Melsik Kuregian
 Description:
 This is the original SAFER+ cipher submitted as a first round AES candidate
(not the "tweaked" version).
 Aliases:
 "SAFERp1" (use for identifiers)
 "SAFER+1"
 References:
 [Def, An] Prof. James Massey, Prof. Gurgen Khachatrian, Dr. Melsik Kuregian,
Nomination of SAFER+ as Candidate Algorithm for the Advanced
Encryption Standard (AES),
http://www.cylink.com/library2/downloadbody.htm
(but link appears to be broken)
 [An] Prof. James Massey,
"On the Optimality of SAFER+ Diffusion,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/massey.pdf
 [An] John Kelsey, Bruce Schneier, David Wagner,
"Key Schedule Weaknesses in SAFER+,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/kelsey.pdf
 [Test] NIST,
SAFER+ Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/saferplsvals.zip
 [also see cryptanalysis references for SAFER++]
 Key length:
 128, 192 or 256 bits; default 128 bits.
 Block size:
 16 bytes.
 Comments:
 The original C reference code uses an unconventional byte order when printing
test vectors (the order of bytes is reversed across the whole block). The
correct byte order is that defined by the Java reference
implementation, and by the NIST test vectors referenced above.
 The "tweaked" version of SAFER+, which was included in SCAN 1.0.13
under the name "SAFER+2", is no longer included because it has no
welldefined test vectors, and has been obsoleted by SAFER++.
This is an incompatible change.
 Security comment:
 The paper "Key Schedule Weaknesses in SAFER+," describes some certificational
weaknesses (meetinthemiddle attacks) for SAFER+ with key sizes of 192 and
256 bits. These are claimed to be corrected by the modified key schedule used
in SAFER++.
 Designers:
 James Massey, Gurgen Khachatrian, Melsik Kuregian
 Published:
 November 2000
 Alias:
 "SAFERpp" (use for identifiers)
 Description:
 This is the variant of SAFER++ with a 128bit block size.
 References:
 [Def, An, Test] James Massey, Gurgen Khachatrian, Melsik Kuregian,
"Nomination of SAFER++ as Candidate Algorithm for the New European Schemes for Signatures,
Integrity, and Encryption (NESSIE),"
Presented at the First Open NESSIE Workshop, November 2000.
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/safer++.zip
 [An] Prof. James Massey,
"On the Optimality of SAFER+ Diffusion,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/massey.pdf
(This applies to SAFER+, but the diffusion properties of SAFER++ are similar.)
 [An] Jorge Nakahara Jr., Bart Preneel, Joos Vandewalle,
"Linear Cryptanalysis of ReducedRound Versions of the SAFER Block Cipher
Family,"
Presented at Fast Software Encryption 2000, New York.
http://www.esat.kuleuven.ac.be/~nakahara/safer.ps.gz
 [An] Bart van Rompey, Vincent Rijmen, Jorge Nakahara Jr.,
"A First Report on CSCipher, Hierocrypt, Grand Cru, SAFER++ and SHACAL,"
NESSIE Project public report, March 12, 2001.
https://www.cosic.esat.kuleuven.ac.be/nessie/reports/kulwp30061.pdf
 [An] Jorge Nakahara Jr., Bart Preneel, Joos Vandewalle,
"Linear Cryptanalysis of ReducedRound SAFER++,"
Second NESSIE Workshop, September 1213, 2001.
http://www.esat.kuleuven.ac.be/~nakahara/spp.ps.gz
 Key length:
 128 or 256 bits; default 128 bits.
 Block size:
 16 bytes.
 Designers:
 James Massey, Gurgen Khachatrian, Melsik Kuregian
 Published:
 November 2000
 Alias:
 "SAFERpp64" (use for identifiers)
 Description:
 This is the "legacy" variant of SAFER++, with a 64bit block size and 128bit key.
 References:
 [see references for SAFER++]
 Key length:
 128 bits.
 Block size:
 8 bytes.
SapphireII  Stream Cipher

 Designer:
 Michael Paul Johnson
 Published:
 January? 1995
 References:
 Key length:
 Minimum 8, maximum 2040, multiple of 8 bits; default 128 bits.
 Missing information:
 Test vectors.
 Designers:
 Ran Canetti, Don Coppersmith, Rosario Gennaro, Shai Halevi,
Nick HowgraveGraham, Charanjit Jutla, Tal Rabin, J. R. Rao
 Published:
 February 2002
 References:
 Key length:
 128 bits.
 Designers:
 Ran Canetti, Don Coppersmith, Rosario Gennaro, Shai Halevi,
Nick HowgraveGraham, Charanjit Jutla, Tal Rabin, J. R. Rao
 Published:
 February 2002
 References:
 [see references for Scream]
 Key length:
 128 bits.
SEAL3.0BE[(Lbytes)]  Stream Cipher

 Designers:
 Phillip Rogaway,
Don Coppersmith
 Published:
 September 1997
 Alias:
 "SEALv3BE" (use for identifiers)
 Description:
 This is version 3.0 of SEAL, using bigendian byte order when XORing the
keystream with the plaintext for encryption. See the Comment section below.
 References:
 [Def, Test] P. Rogaway, D. Coppersmith,
"A SoftwareOptimized Encryption Algorithm," (revised September 1997).
http://www.cs.ucdavis.edu/~rogaway/papers/sealabstract.html
 [Inf] Bruce Schneier,
"Section 17.2 SEAL,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
"Section 6.4.1 SEAL,"
Handbook of Applied Cryptography,
CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap6.pdf,
.ps
 [Patent] P. Rogaway, D. Coppersmith,
"Softwareefficient pseudorandom function and the use thereof for
encryption,"
U.S. Patent 5,454,039, filed December 6 1993, issued September 26 1995.
 [Patent] P. Rogaway, D. Coppersmith,
"Softwareefficient pseudorandom function and the use thereof for
encryption,"
U.S. Patent 5,675,652, filed June 7 1995, issued October 7 1997.
 [An] Helena Handschuh, Henri Gilbert,
"^{2} Cryptanalysis of the SEAL Encryption Algorithm,"
Fast Software Encryption  FSE4,
Volume 1267 of Lecture Notes in Computer Science, pp. 112, 1997.
http://www.enst.fr/~handschu/seal.ps
 [An] Scott Fluhrer,
"Cryptanalysis of the SEAL 3.0 pseudorandom function family,"
In Proceedings of the Fast Software Encryption Workshop (FSE '01), 2001.
 Parameters:

Integer Lbytes
[creation/read, default 4096]  the number
of bytes of output generated for each position index (minimum 32,
maximum 65536, multiple of 32). This is equal to L/8 where L
is as defined in the SEAL paper.
 Key length:
 160 bits.
 Comments:
 The internal operation of SEAL is endianneutral, and is intentionally left
unspecified in the paper "A softwareoptimized encryption algorithm."
We therefore define two different algorithm names: SEAL3.0BE for
bigendian operation, and SEAL3.0LE for littleendian operation.
Note that bigendian order is consistent with SHA1 (which is used by the SEAL
key scheduling algorithm), with common practice for Internet protocols, and
with Wei Dai's Crypto++ library. For some applications these considerations may be
outweighed by speed on littleendian processors (or as suggested by Rogaway and
Coppersmith, the ciphertext could be labelled with the byteorder that has
been used).
 The Lbytes parameter was added in SCAN 1.0.13.
 Security comment:
 Note that the paper by Handschuh and Gilbert cryptanalyses SEAL 1.0 or 2.0
(which do not have SCAN algorithm names). SEAL 3.0 has been designed to prevent
the attack described in that paper. The attack by Scott Fluhrer distinguishes
the output stream from random after about 2^{44} bytes.
 Patent status:
 SEAL is patented in the United States by IBM.
SEAL3.0LE  Stream Cipher

 Designers:
 Phillip Rogaway,
Don Coppersmith
 Published:
 September 1997
 Alias:
 "SEALv3LE" (use for identifiers)
 Description:
 This is version 3.0 of SEAL, using littleendian byte order when XORing the
keystream with the plaintext for encryption. See the Comment section for
SEAL3.0BE.
 References:
 [see references for SEAL3.0BE]
 Parameters:

Integer Lbytes
[creation/read, default 4096]  the number
of bytes of output generated for each position index (minimum 32,
maximum 65536, multiple of 32). This is equal to L/8 where L
is as defined in the SEAL paper.
 Key length:
 160 bits.
 Comment:
 [see comment for SEAL3.0BE]
 Patent status:
 [see patent status for SEAL3.0BE]
 Designers:
 Ross Anderson,
Eli Biham,
Lars Knudsen
 Published:
 1998?
 References:
 [Def, An] Ross Anderson, Eli Biham, Lars Knudsen,
Serpent: A Proposal for the Advanced Encryption Standard,
http://www.cl.cam.ac.uk/ftp/users/rja14/serpent.pdf
 [Inf] Ross Anderson,
Serpent home page,
http://www.cl.cam.ac.uk/~rja14/serpent.html
 [Inf] Eli Biham,
Serpent page at Technion University,
http://www.cs.technion.ac.il/~biham/Reports/Serpent/
 [Inf] Dag Arne Osvik,
"Speeding up Serpent,"
March 13, 2000. Presented at the 3nd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/26daosvik.pdf
 [Inf] Jun Yajima, Masahiko Takenaka, Naoya Torii, Kouichi Itoh,
"Results of New Boolean Functions Search for Serpent Sboxes,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000511jyajima.pdf
 [An] Orr Dunkelman,
"An Analysis of Serpentp and Serpentpns,"
2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/dunkelman.pdf
 [An] T. Shimoyama,
"The nonlinear order of the Serpent Sboxes,"
Presented at the recent result session of AES2.
 [An] John Kelsey, Tadayoshi Kohno, Bruce Schneier,
"Preliminary Cryptanalysis of ReducedRound Serpent,"
3rd AES Candidate Conference, 2000.
http://www.counterpane.com/serpentaes.html
 [An] Tetsu Iwata, Kaoru Kurosawa,
"On the Pseudorandomness of AES Finalists  RC6, Serpent, MARS and Twofish,"
Presented at Fast Software Encryption 2000, New York.
 [An] Joan Daemen, Michael Peeters, Gilles Van Assche,
"Bitslice Ciphers and Power Analysis Attacks,"
Presented at Fast Software Encryption 2000, New York.
 [An] Ralph Wernsdorf,
"The Round Functions of SERPENT Generate the Alternating Group,"
Submitted to NIST as an AES comment, May 2000
http://csrc.nist.gov/encryption/aes/round2/comments/20000512rwernsdorf.pdf
 [An] John Kelsey, Tadayoshi Kohno, Bruce Schneier,
"Amplified Boomerang Attacks Against ReducedRound MARS and Serpent,"
Presented at Fast Software Encryption 2000, New York.
http://www.counterpane.com/boomerang.html
 [Patent] Ross Anderson, Eli Biham, Lars Knudsen,
"Fast Block Cipher,"
U.K. Patent Application 9722798.9. Filed October 30, 1997.
 [Impl] Frank Stajano, Markus Kuhn,
Serpent reference implementations (in C, Python and Ada),
http://www.cl.cam.ac.uk/~rja14/serpent.html
 [Test] NIST,
Serpent Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/serpentvals.zip
 Key length:
 Minimum 0, maximum 256, multiple of 8 bits; default 128 bits.
 Block size:
 16 bytes.
 Comments:
 The original C reference code uses an unconventional byte order when printing
test vectors (the order of bytes is reversed across the whole block). The
correct byte order is that defined by the Java reference
implementation, and by the NIST test vectors referenced above (i.e.
littleendian order).
 The range of specified key lengths has been extended since SCAN 1.0.12
(which only specified 128, 192 and 256 bits). This is an incompatible
change for the key lengths that were not previously supported.
 [[need to list implementations that use reversed order?]]
 Patent status:
 A patent has been applied for on Serpent (see references). However, quoting from
the Serpent
home page:
Serpent is now completely in the public domain, and we impose no restrictions on
its use. This was announced on the 21st August 1998 at the AES conference.
 Designers:
 Vincent Rijmen,
Joan Daemen,
Bart Preneel
Antoon Bosselaers,
Erik De Win
 Designers:
 This is the "Affine Transformation" variant of SHARK.
 References:
 [Def, An] Vincent Rijmen, Joan Daemen, Bart Preneel, Antoon Bosselaers, Erik De Win,
"The Cipher SHARK,"
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/shark/paper.ps
 [Impl] Vincent Rijmen, Joan Daemen, Bart Preneel, Antoon Bosselaers, Erik De Win,
SHARK reference implementation (in C),
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/shark/
 [An] Thomas Jakobsen, Lars Knudsen,
"The Interpolation Attack on Block Ciphers,"
Proceedings of Fast Software Encryption '97.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/interpol.ps
 Key length:
 128 bits.
 Block size:
 8 bytes.
 Missing information:
 Test vectors.
 Security comment:
 "The Interpolation Attack on Block Ciphers" analyses a "variant of SHARK,
which deviates only slightly from the proposed SHARK", reduced to 5 rounds.
SHARK normally has 6 rounds.
 Designers:
 Vincent Rijmen,
Joan Daemen,
Bart Preneel
Antoon Bosselaers,
Erik De Win
 Designers:
 This is the "Exor" variant of SHARK.
 References:
 [Def, An] Vincent Rijmen, Joan Daemen, Bart Preneel, Antoon Bosselaers, Erik De Win,
"The Cipher SHARK,"
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/shark/paper.ps
 [Impl] Vincent Rijmen, Joan Daemen, Bart Preneel, Antoon Bosselaers, Erik De Win,
SHARK reference implementation (in C),
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/shark/
 [An] Thomas Jakobsen, Lars Knudsen,
"The Interpolation Attack on Block Ciphers,"
Proceedings of Fast Software Encryption '97.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/interpol.ps
 [Test] Wei Dai,
Crypto++ 3.0, file sharkval.dat
http://www.eskimo.com/~weidai/cryptlib.html
 Key length:
 128 bits.
 Block size:
 8 bytes.
 Security comment:
 "The Interpolation Attack on Block Ciphers" analyses a "variant of SHARK,
which deviates only slightly from the proposed SHARK", reduced to 5 rounds.
SHARK normally has 6 rounds.
 Designer:
 U.S. National Security Agency
 Published:
 June 1998
 References:
 [Def, Test] U.S. National Institute of Standards and Technology,
SKIPJACK and KEA Specifications, May 1998.
http://csrc.nist.gov/encryption/skipjack/skipjack.pdf
HTML version
(test vectors corrected 10 February 1999).
 [An] Eli Biham, Alex Biryukov, Orr Dunkelman, Eran Richardson, Adi Shamir,
"Observations on the SkipJack Encryption Algorithm,"
http://www.cs.technion.ac.il/~biham/Reports/SkipJack/
 [An] Eli Biham, Alex Biryukov, Orr Dunkelman, Eran Richardson, Adi Shamir,
"Cryptanalysis of Skipjack Reduced to 31 Rounds using Impossible Differentials,"
http://www.cs.technion.ac.il/users/wwwb/cgibin/trget.cgi/1998/CS/CS0947.ps
 [An] Lars R. Knudsen, M.J.B. Robshaw, David Wagner,
"Truncated differentials and Skipjack,"
Proceedings of CRYPTO '99.
http://www.cs.berkeley.edu/~daw/papers/skipjackcrypto99.ps
 [An] Louis Granboulan,
"Flaws in differential cryptanalysis of Skipjack,"
In Proceedings of Fast Software Encryption: 8th International Workshop, Yokohama, Japan, 24 April 2001.
To appear in Lecture Notes in Computer Science, SpringerVerlag.
http://www.di.ens.fr/~granboul/recherche/publications/
 Key length:
 80 bits.
 Block size:
 8 bytes.
 Security comment:
 The "Observations on the SkipJack Encryption Algorithm" pages cited
above describe the following attack, among others:
This note summarizes our first week of analysis. The main result is an attack
on a variant, which we call SkipJack3XOR (SkipJack minus 3 XORs). The only
difference between SkipJack and SkipJack3XOR is the removal of 3 out of the
320 XOR operations. The attack uses the ciphertexts derived from about 500
plaintexts which are identical except for the second 16 bit word. Its total
running time is equivalent to about one million SkipJack encryptions, which
can be carried out in seconds on a personal computer.
This is still a preliminary result, but it reiterates our earlier comment that
SkipJack does not have a conservative design with a large margin of safety.
 Designer:
 ?
 Published:
 November 2000
 References:
 Key length:
 Minimum ?, maximum ?, multiple of ? bits; default 128 bits.
 Designer:
 ?
 Published:
 November 2000
 References:
 Key length:
 Minimum ?, maximum ?, multiple of ? bits; default 128 bits.
 Designer:
 ?
 Published:
 November 2000
 References:
 [see references for SOBERt16]
 Key length:
 Minimum ?, maximum ?, multiple of ? bits; default 128 bits.
SPEED64[(rounds)]  Block Cipher

 Designer:
 Yuliang Zheng
 Published:
 February 1997
 References:
 [Def, An] Yuliang Zheng,
"The SPEED Cipher,"
Proceedings of Financial Cryptography  First International Conference FC'97,
Volume 1318 of Lecture Notes in Computer Science, pp. 7189.
SpringerVerlag.
Available from
http://www.sis.uncc.edu/~yzheng/src/
 [Inf, Impl, Test] Yuliang Zheng,
SPEED reference implementation (in C),
Available from
http://www.sis.uncc.edu/~yzheng/src/
 [An] Chris Hall, John Kelsey, Bruce Schneier, David Wagner,
"Cryptanalysis of SPEED",
Fifth Annual Workshop on Selected Areas in Cryptography,
SpringerVerlag, August 1998.
http://www.counterpane.com/speedsac.html
 Parameters:

Integer rounds
[creation/read, default 64]  the number
of rounds to be performed (minimum 64, multiple of 4)
 Key length:
 Minimum 48, maximum 256, multiple of 16 bits; default 128 bits.
 Block size:
 8 bytes.
 Security comment:
 The "Cryptanalysis of SPEED" paper cited above breaks a
reduced round variant of SPEED with 28 rounds, using 2^{31} chosen
plaintexts, and argues that variants of SPEED with sufficient rounds to
resist the attacks given in the paper, are slower than many other
ciphers with comparable security.
SPEED128[(rounds)]  Block Cipher

 Designer:
 Yuliang Zheng
 Published:
 February 1997
 References:
 [see references for SPEED64]
 Parameters:

Integer rounds
[creation/read, default 64]  the number
of rounds to be performed (minimum 48, multiple of 4)
 Key length:
 Minimum 48, maximum 256, multiple of 16 bits; default 128 bits.
 Block size:
 16 bytes.
 Security comment:
 [see security comment for SPEED64]
SPEED256[(rounds)]  Block Cipher

 Designer:
 Yuliang Zheng
 Published:
 February 1997
 References:
 [see references for SPEED64]
 Parameters:

Integer rounds
[creation/read, default 64]  the number
of rounds to be performed (minimum 48, multiple of 4)
 Key length:
 Minimum 48, maximum 256, multiple of 16 bits; default 128 bits.
 Block size:
 32 bytes.
 Security comment:
 [see security comment for SPEED64]
Square[(rounds)]  Block Cipher

 Designers:
 Joan Daemen,
Vincent Rijmen
 Published:
 1997
 References:
 [Def, An] Joan Daemen, Lars Knudsen, Vincent Rijmen,
"The Block Cipher Square,"
Fast Software Encryption,
Volume 1267 of Lecture Notes in Computer Science (E. Biham, ed.), pp. 149165.
SpringerVerlag, 1997.
http://www.esat.kuleuven.ac.be/~cosicart/ps/VR9700.ps.gz
(PDF
version).
 [Inf, Impl] Joan Daemen, Lars Knudsen, Vincent Rijmen,
The Square Page,
http://www.esat.kuleuven.ac.be/~rijmen/square/
 [Test] Paulo Barreto,
Validation data set for Square v1.0,
http://www.esat.kuleuven.ac.be/~rijmen/downloadable/square/vdata
 Parameters:

Integer rounds
[creation/read, default 8]  the number
of rounds to be performed (minimum 8, multiple of 2)
 Key length:
 128 bits.
 Block size:
 16 bytes.
 Designers:
 David Wheeler,
Roger Needham
 Published:
 1994
 References:
 [Def, Impl] David Wheeler, Roger Needham,
"TEA, a Tiny Encryption Algorithm,"
Fast Software Encryption, Cambridge Security Workshop Proceedings,
Volume 809 of Lecture Notes in Computer Science (Ross Anderson, ed.), pp. 363366.
SpringerVerlag, 1994.
http://www.cl.cam.ac.uk/ftp/users/djw3/tea.ps
(PDF version)
 [An] John Kelsey, Bruce Schneier, David Wagner,
"RelatedKey Cryptanalysis of 3WAY, BihamDES, CAST, DESX, NewDES, RC2, and TEA,"
ICICS '97 Proceedings, SpringerVerlag, November 1997.
http://www.counterpane.com/relatedkey_cryptanalysis.html
 [An] Roger Fleming, David Wagner,
Subject: "An attack on a weakened version of TEA"
sci.crypt thread, October 1996.
Link to Google groups
 Key length:
 128 bits.
 Block size:
 8 bytes.
 Missing information:
 Test vectors.
 Comment:
 Bigendian byte order is used when converting the plaintext, ciphertext,
and key to 32bit words. Note that this may not match some other TEA
implementations.
 The algorithm "XTEA" (sometimes called "tean") was intended to be a
modification of TEA resistant to related key attacks. However, that
algorithm is not welldefined (it was implemented inconsistently, due
to an ambiguity in the paper describing it
[PS,
PDF]),
and is not included in SCAN.
 "Block TEA" is also not included in SCAN, and neither is
this
correction to Block TEA.
 Security comment:
 TEA is vulnerable to relatedkey attacks, and therefore it should only
be used with keys that are generated by a strong RNG, or by a source of
bits that are sufficiently uncorrelated (such as the output of a hash
function).
 Designers:
 Bruce Schneier,
John Kelsey, Doug Whiting,
David Wagner,
Chris Hall, Niels Ferguson
 Published:
 1998
 Alias:
 "OpenPGP.Cipher.10" [[implies 256bit key]]
 References:
 [Def, An] Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall,
Niels Ferguson,
"Twofish: A 128bit Block Cipher,"
15 June 1998. Presented at the 1st AES Conference.
http://www.counterpane.com/twofishpaper.html
[[see comment]]
 [Inf, Test, Impl] Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall,
Niels Ferguson,
The Twofish: A New Block Cipher Page,
http://www.counterpane.com/twofish.html
 [Inf] Bruce Schneier, Doug Whiting,
"Improved Twofish Implementations,"
December 2, 1998.
http://www.counterpane.com/twofishspeed.html
 [An] Niels Ferguson,
"Upper Bounds on Differential Characteristics in Twofish,"
Twofish Technical Report #1, August 17, 1998.
http://www.counterpane.com/twofishdifferential.html
 [An] Doug Whiting, David Wagner,
"Empirical Verification of Twofish Key Uniqueness Properties,"
Twofish Technical Report #2, September 22, 1998.
http://www.counterpane.com/twofishkeys.html
 [An] Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall,
Niels Ferguson,
"On the Twofish Key Schedule,"
Twofish Technical Report #3, Fifth Annual Workshop on Selected Areas in Cryptography,
Springer Verlag, August 1998.
http://www.counterpane.com/twofishkeysched.html
 [An] Fauzan Mirza, Sean Murphy,
"An Observation on the Key Schedule of Twofish,"
Presented at the 2nd AES Conference.
http://csrc.nist.gov/encryption/aes/round1/conf2/papers/mirza.pdf
 [An] Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall,
Niels Ferguson,
"Further Observations on the Key Schedule of Twofish,"
Twofish Technical Report #4, March 16, 1999.
http://www.counterpane.com/twofishks2.html
 [An] Niels Ferguson,
"Impossible Differential Attack of Simplified Twofish,"
Twofish Technical Report #5, October 1999.
http://www.counterpane.com/twofishimpossible.html
 [An] Bruce Schneier, John Kelsey, Doug Whiting, Niels Ferguson,
"A Twofish Retreat: RelatedKey Attacks Against ReducedRound
Twofish,"
Twofish Technical Report #6, February 2000.
http://www.counterpane.com/twofishrelated.html
 [An] Sean Murphy,
"The Key Separation of Twofish,"
March 15, 2000. Presented at the 3rd AES Candidate Conference.
http://csrc.nist.gov/encryption/aes/round2/conf3/papers/10smurphy.pdf
 [An] John Kelsey,
"Key Separation in Twofish,"
Twofish Technical Report #7, April 7 2000.
http://www.counterpane.com/twofishtr7.html
 [An] Sean Murphy,
"Differential Distributions for Twofish SBoxes,
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000524smurphy.pdf
 [An] Sean Murphy, Matt Robshaw,
"Differential Cryptanalysis, KeyDependent SBoxes, and Twofish,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000515smurphy.pdf
 [An] Lars Knudsen,
"Trawling Twofish (revisited),"
http://www.ii.uib.no/~larsr/papers/trawrevisited.ps or
http://csrc.nist.gov/encryption/aes/round2/comments/20000515lknudsen2.pdf
 [An] Bruce Schneier, John Kelsey, Doug Whiting, Niels Ferguson,
"A Second Twofish Retreat,"
Presented at the recent result session of AES3.
 [An] K. Daemen,
"Cryptanalysis of Twofish,"
Thesis, KU Leuven, 2000.
 [An] B. Preneel, A. Bosselaers, V. Rijmen, B. Van Rompay, L. Granboulan,
J. Stern, S. Murphy, M. Dichtl, P. Serf, E. Biham, O. Dunkelman, V. Furman,
F. Koeune, G. Piret, JJ. Quisquater, L. Knudsen, H. Raddum,
"Comments by the NESSIE Project on the AES Finalists,"
Submitted to NIST as an AES comment, May 2000.
http://csrc.nist.gov/encryption/aes/round2/comments/20000524bpreneel.pdf
 [An] Tetsu Iwata, Kaoru Kurosawa,
"On the Pseudorandomness of AES Finalists  RC6, Serpent, MARS and Twofish,"
Presented at Fast Software Encryption 2000, New York.
 [Test] NIST,
Twofish Test Values,
http://www08.nist.gov/encryption/aes/round1/testvals/twofishvals.zip
 Key length:
 Minimum 8, maximum 256, multiple of 8 bits; default 128 bits.
 Block size:
 16 bytes.
 Comment:
 The C and Java reference implementations differ from the specification in
"Twofish: A 128bit Block Cipher," for key lengths between 8 and 64 bits
inclusive. A strict reading of the specification would zeropad these keys
to 128 bits, and use k = 2; the reference implementations zeropad
them to 64 bits, and use k = 1. This algorithm follows the reference
implementations (however, the use of keys this small is definitely NOT
RECOMMENDED).
? WAKECFBBE  Stream Cipher

 Designer:
 David Wheeler
 Published:
 1993
 Description:
 This is WAKE in CFB mode, using bigendian byte order.
See the Comments section below.
 References:
 [Def, Impl] David Wheeler,
"A Bulk Data Encryption Algorithm,"
Fast Software Encryption, Cambridge Security Workshop Proceedings,
Volume 809 of Lecture Notes in Computer Science (Ross Anderson, ed.), pp. 127134.
SpringerVerlag, 1994.
http://www.cl.cam.ac.uk/Research/Security/docs/wake.ps
(PDF,
HTML versions).
 [Inf] Keith Lockstone, David Wheeler
WAKE  questions and answers,
http://www.cix.co.uk/~klockstone/wakeqna.htm
 Key length:
 128 bits.
 Missing information:
 Test vectors.
 Comments:
 The internal operation of WAKE is endianneutral, and is intentionally
left unspecified in the paper "A Bulk Data Encryption Algorithm."
We therefore define two different algorithm names for WAKE in
CFB mode: WAKECFBBE for bigendian operation, and WAKECFBLE for
littleendian operation. Note that this applies only to the byte order
of the keystream words to be exclusiveor'd with the plaintext and
ciphertext, not to the input key.
 The initial values of the four feedback registers are given directly by the
key. Each key word is represented in bigendian order (which is consistent
with the implementation in Wei Dai's Crypto++ library).
 Security comments:
 WAKE is insecure against a chosenplaintext or chosenciphertext attack.
 If a section of plaintext [[of what length?]] is zero, 32 bits of the key
are revealed.
? WAKECFBLE  Stream Cipher

 Designer:
 David Wheeler
 Published:
 1993
 Description:
 This is WAKE in CFB mode, using littleendian byte order.
See the Comments section for WAKECFBBE.
 References:
 [see the references for WAKECFBBE]
 Key length:
 128 bits.
 Missing information:
 Test vectors.
 Comments:
 [see comments for WAKECFBBE]
 There has an incompatible change in this algorithm since SCAN version
1.0.7; the input key words are now always interpreted as bigendian.
 Security comments:
 [see security comments for WAKECFBBE]
WiderWake4+1BE  Stream Cipher

 Designer:
 Craig Clapp
(based on WAKE, by David Wheeler)
 Published:
 January 1997
 Alias:
 "WiderWake41BE" (use for identifiers)
 Description:
 This is the 4+1 variant of WiderWake, using bigendian byte order.
See the Comments section below.
 References:
 [Def, Impl, Test] Craig Clapp,
Optimizing a Fast Stream Cipher for VLIW, SIMD, and Superscalar Processors,
Presented at the 4th annual Fast Software Encryption Workshop,
January 2022, 1997, Haifa, Israel.
http://standard.pictel.com/ftp/research/security/widerwake.pdf
 Key length:
 128 bits.
 Comments:
 There are two variants of WiderWake: 4+1, which is designed for
speed on processors with few registers, and 4+3, which is slightly
more conservative. The reference implementation and test vectors in the
paper "Optimizing a Fast Stream Cipher for VLIW, SIMD, and Superscalar
Processors," are for WiderWake4+1.
 The internal operation of WiderWake is endianneutral, and is
intentionally left unspecified in the paper cited above.
We therefore define two different algorithm names for each variant
of WiderWake: WiderWake4+1BE and WiderWake4+3BE for bigendian
operation, and WiderWake4+1LE and WiderWake4+3LE for littleendian
operation. Note that this applies to the byte order of the keystream
words to be exclusiveor'd with the plaintext and ciphertext, and to
the IV. The 128bit input key is always represented in bigendian order.
 WiderWake has a resynchronisation procedure, which uses an 8byte IV to
randomise the feedback words. This IV is represented as two 32bit words,
each using the same byte order as the keystream words (see above).
The IV can be set in the same way as would be used for a block cipher;
a resynchronisation is done whenever it is set. Note that a
resynchronisation is also always done before encrypting the first byte
of data, or when the cipher is reset (using a random IV, if one has not
been set explicitly).
 There have been incompatible changes in these algorithms since SCAN
version 1.0.7; the input key words are now always interpreted as
bigendian, and support for resynchronisation has been added.
WiderWake4+1LE  Stream Cipher

 Designer:
 Craig Clapp
(based on WAKE, by David Wheeler)
 Published:
 January 1997
 Alias:
 "WiderWake41LE" (use for identifiers)
 Description:
 This is the 4+1 variant of WiderWake, using littleendian byte order.
See the Comments section for WiderWake4+1BE.
 References:
 [see references for WiderWake4+1BE]
 Key length:
 128 bits.
 Comments:
 [see comments for WiderWake4+1BE]
? WiderWake4+3BE  Stream Cipher

 Designer:
 Craig Clapp
(based on WAKE, by David Wheeler)
 Published:
 January 1997
 Alias:
 "WiderWake43BE" (use for identifiers)
 Description:
 This is the 4+3 variant of WiderWake, using bigendian byte order.
See the Comments section for WiderWake4+1BE.
 References:
 [see references for WiderWake4+1BE]
 Key length:
 128 bits.
 Missing information:
 Test vectors.
 Comments:
 [see comments for WiderWake4+1BE]
? WiderWake4+3LE  Stream Cipher

 Designer:
 Craig Clapp
(based on WAKE, by David Wheeler)
 Published:
 January 1997
 Alias:
 "WiderWake43LE" (use for identifiers)
 Description:
 This is the 4+3 variant of WiderWake, using littleendian byte order.
See the Comments section for WiderWake4+1BE.
 References:
 [see references for WiderWake4+1BE]
 Key length:
 128 bits.
 Missing information:
 Test vectors.
 Comments:
 [see comments for WiderWake4+1BE]
× PBEPKCS5(digestName,DES/CBC)  Block Cipher Construction

 Designers:
 RSA Security, Inc.
 Aliases:
 "pbeWithMD2AndDESCBC" and "PBEWithMD2AndDES" for PBEPKCS5(MD2,DES/CBC).
 "pbeWithMD5AndDESCBC" and "PBEWithMD5AndDES" for PBEPKCS5(MD5,DES/CBC).
 Object Identifiers:
 1.2.840.113549.1.5.1 for PBEPKCS5(MD2,DES/CBC).
 1.2.840.113549.1.5.3 for PBEPKCS5(MD5,DES/CBC).
 Description:
 The passphrasebased encryption algorithm specified in version 1.5 of
PKCS #5. For the Java mapping, the key MUST be an instance of PBEKeySpec,
or a subclass of PBEKeySpec.
Note that these algorithms are only specified for compatibility with
Sun's JCE 1.2. The preferred way of doing passphrasebased encryption
in SCAN is described in the documentation for PassphraseHash.
 References:
 Parameters:

String digestName
[creation/read, no default]  the name
of the message digest to be used to generate the key and IV.
 Key length:
 64 bits as encoded, 56 bits excluding parity bits.
 Block size:
 8 bytes.
 Comment:
 The method described in PKCS #5 v1.5 cannot easily be generalised to support
ciphers other than DES. However, DES/CBC MUST still be specified as if it
were a parameter, for consistency with the names of other passphrasebased
cipher constructions.
 Security comment:
 The 56bit effective key length is too short to prevent bruteforce attacks.
× PBEPKCS12(digestName,cipherName
[,keyLength])  Cipher Construction

 Designers:
 RSA Security, Inc.
 Aliases:
 "pbeWithSHAAnd128BitRC4" for PBEPKCS12(SHA1,RC4,128).
 "pbeWithSHAAnd40BitRC4" for PBEPKCS12(SHA1,RC4,40).
 "pbeWithSHAAnd3KeyTripleDESCBC" for PBEPKCS12(SHA1,DESede/CBC,168).
 "pbeWithSHAAnd2KeyTripleDESCBC" for PBEPKCS12(SHA1,DESede/CBC,112).
 "pbeWithSHAAnd128BitRC2CBC" for PBEPKCS12(SHA1,RC2/CBC,128).
 "pbeWithSHAAnd40BitRC2CBC" for PBEPKCS12(SHA1,RC2/CBC,40).
 Object Identifiers:
 1.2.840.113549.1.12.1.1 for PBEPKCS12(SHA1,RC4,128).
 1.2.840.113549.1.12.1.2 for PBEPKCS12(SHA1,RC4,40).
 1.2.840.113549.1.12.1.3 for PBEPKCS12(SHA1,DESede/CBC,168).
 1.2.840.113549.1.12.1.4 for PBEPKCS12(SHA1,DESede/CBC,112).
 1.2.840.113549.1.12.1.5 for PBEPKCS12(SHA1,RC2/CBC,128).
 1.2.840.113549.1.12.1.6 for PBEPKCS12(SHA1,RC2/CBC,40).
 Description:
 The passphrasebased encryption algorithm specified in version 1.0 of
PKCS #12. For the Java mapping, the key MUST be an instance of PBEKeySpec,
or a subclass of PBEKeySpec.
Note that these algorithms are only specified for compatibility with
Sun's JCE 1.2. The preferred way of doing passphrasebased encryption
in SCAN is described in the documentation for PassphraseHash.
 References:
 Parameters:

String digestName
[creation/read, no default]  the name
of the message digest to be used to generate the key and (if needed)
the IV.

String cipherName
[creation/read, no default]  the name
of the cipher to be used for encryption/decryption.

Integer keyLength
[creation/read, default equal to the default
key length of the cipher given by cipherName]  the effective
bit length (i.e. excluding parity bits) to be used for the key.
 Key length:
 Same as the value of the keyLength property.
 Block size:
 Same as the block size of the cipher given by cipherName.
 Security comment:
 PBEPKCS12 does not define any way to iterate the hashing operation in
order to slow down a dictionary attack against the passphrase. It will
therefore become more vulnerable than necessary to attacks against weak
passphrases, as the performance of computing hardware increases.
 Description:
 A "noop" algorithm, for which the ciphertext is identical to the plaintext.
 Key length:
 0 bits.
 Security comment:
 This algorithm provides no security. (Note that its existance is not in itself
a security weakness; even without a noop algorithm, it would not be valid for
applications to assume that an arbitrary Cipher object or algorithm will provide
adequate security.)
Symmetric block cipher modes fall into two categories: blockoriented and byteoriented.
For blockoriented modes, the plaintext or ciphertext can only be processed one
block at a time. This means that a "padding scheme" is needed to specify how to
handle the last block of a message, i.e. the standard algorithm name will be of
the form "cipher/mode/padding". If messages are always an exact number
of blocks in length, "NoPadding" may be specified as the padding scheme.
For byteoriented modes, the plaintext or ciphertext can be processed one byte
at a time (by use of internal buffering if necessary). This means that a padding
scheme is not required, i.e. the standard name will be of the form
"cipher/mode". For backward compatibility, however, any of the forms
"cipher/mode", "cipher/mode/NoPadding", and
"cipher/mode/NONE" should be accepted when the mode is byteoriented.
The last two of these are deprecated.
 Description:
 Electronic Codebook Mode, as defined in NBS FIPS PUB 81.
 References:
 [Inf] U.S. National Bureau of Standards (now NIST),
"DES Modes of Operation,"
NBS FIPS PUB 81,
U.S. Department of Commerce, December 1980.
http://www.itl.nist.gov/div897/pubs/fip81.htm
 [Inf] Bruce Schneier,
"Section 9.1 Electronic Codebook Mode,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] sci.crypt FAQ, "Part 5: Product Ciphers,"
ftp://ftp.rtfm.mit.edu/pub/usenet/news.answers/cryptographyfaq/part05
 Comment:
 If a padding scheme is not specified (i.e. the algorithm name is given in the form
"cipherName/ECB"), then NoPadding MUST be
assumed (note that this is intentionally different to CBC and PCBC modes, for which
PKCSPadding would be used). The standard name always specifies which padding
method is used, i.e. it always has three components.
 Security comment:
 ECB mode will always encrypt identical plaintext blocks to identical ciphertexts.
This can be a weakness when the plaintext is not random, uniformly distributed,
and a multiple of the block size. If these conditions are not satisfied, a
different mode should probably be used.
 Description:
 Cipher Block Chaining Mode, as defined in NBS FIPS PUB 81.
 References:
 [Inf] U.S. National Bureau of Standards (now NIST),
"DES Modes of Operation,"
NBS FIPS PUB 81,
U.S. Department of Commerce, December 1980.
http://www.itl.nist.gov/div897/pubs/fip81.htm
 [Inf] Bruce Schneier,
"Section 9.3 Cipher Block Chaining Mode,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] sci.crypt FAQ, "Part 5: Product Ciphers,"
ftp://ftp.rtfm.mit.edu/pub/usenet/news.answers/cryptographyfaq/part05
 [Inf] M. Bellare, A. Desai, E. Jokipii, P. Rogaway,
"A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes
of Operation,"
http://wwwcse.ucsd.edu/users/mihir/papers/symenc.html
 Comment:
 If a padding scheme is not specified (i.e. the algorithm name is given in the
form "cipherName/CBC"), then PKCSPadding
MUST be assumed. The standard name always specifies which padding method is
used, i.e. it always has three components.
 Description:
 Propagating Cipher Block Chaining Mode.
 References:
 Comment:
 If a padding scheme is not specified (i.e. the algorithm name is given in the
form "cipherName/PCBC"), then PKCSPadding
MUST be assumed. The standard name always specifies which padding method is
used, i.e. it always has three components.
CFB[(feedbackBits)]  Byteoriented Mode

 Description:
 Cipher Feedback Mode, as defined in NBS FIPS PUB 81, with a feedback
vector of length feedbackBits bits.
 Aliases:
 "CFBn", where n is an integer, can be used as a deprecated alias
for "CFB(n)".
The values of n that may need to be supported for backward compatibility
are 8 and 64.
 References:
 [Inf] U.S. National Bureau of Standards (now NIST),
"DES Modes of Operation,"
NBS FIPS PUB 81,
U.S. Department of Commerce, December 1980.
http://www.itl.nist.gov/div897/pubs/fip81.htm
 [Inf] Bruce Schneier,
"Section 9.6 CipherFeedback Mode,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] sci.crypt FAQ, "Part 5: Product Ciphers,"
ftp://ftp.rtfm.mit.edu/pub/usenet/news.answers/cryptographyfaq/part05
 Parameters:

Integer feedbackBits
[creation/read, default equal to the
number of bits in a block]  the length of the feedback vector in bits
(from 1 bit, to the number of bits in a block)
 Comment:
 The value of feedbackBits does not affect the granularity of data
that can be encrypted or decrypted. Implementations MUST support
immediate processing of individual bytes, in a similar fashion to a stream
cipher. This means that it is never necessary to specify a padding scheme
(and therefore the standard name always has two components).
 Description:
 Output Feedback Mode, as defined in NBS FIPS PUB 81, except that the
feedback vector is restricted to be the same size as a block.
 References:
 [Inf] U.S. National Bureau of Standards (now NIST),
"DES Modes of Operation,"
NBS FIPS PUB 81,
U.S. Department of Commerce, December 1980.
http://www.itl.nist.gov/div897/pubs/fip81.htm
 [Inf] Bruce Schneier,
"Section 9.8 OutputFeedback Mode,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] sci.crypt FAQ, "Part 5: Product Ciphers,"
ftp://ftp.rtfm.mit.edu/pub/usenet/news.answers/cryptographyfaq/part05
 [An] Robert R. Jueneman,
"Analysis of Certain Aspects of Output Feedback Mode,"
Advances in Cryptology  CRYPTO '82 Proceedings
(D. Chaum, R. Rivest and A. Sherman, ed.),
Plenum Press, 1983, pp. 99127.
 [An] D.W. Davies, G.I.P. Parkin,
"The Average Size of the Key Stream in Output Feedback Mode,"
Cryptography, Proceedings of the Workshop on Cryptography,
BurgFeuerstein, Germany, March 29April 2, 1982,
SpringerVerlag, 1983, pp. 263279.
Also in Advances in Cryptology  CRYPTO '82 Proceedings,
Plenum Press, 1983, pp. 9798.
 Comments:
 Implementations MUST support immediate processing of individual bytes,
in a similar fashion to a stream cipher. This means that it is never
necessary to specify a padding scheme (and therefore the standard name
always has two components).
 The reason for not supporting feedback sizes less than the block size, is
that this greatly reduces the expected period of the keystream (e.g. from
about 2^{66} bytes to 2^{34} bytes, for a cipher with a block
size of 8 bytes).
InterleavedCBC(nStreams)  Blockoriented Mode

 Description:
 Interleaved Cipher Block Chaining Mode, with nStreams independent
IVs.
The length of the IV array required by
setIV
(or generated
randomly) will be nStreams * blockSize bytes.
 References:
 [Inf] U.S. National Bureau of Standards (now NIST),
"DES Modes of Operation,"
NBS FIPS PUB 81,
U.S. Department of Commerce, December 1980.
http://www.itl.nist.gov/div897/pubs/fip81.htm
 [Inf] Bruce Schneier,
"Section 9.3 Cipher Block Chaining Mode," and
"Section 9.12 Interleaving,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] sci.crypt FAQ, "Part 5: Product Ciphers,"
ftp://ftp.rtfm.mit.edu/pub/usenet/news.answers/cryptographyfaq/part05
 Parameters:

Integer nStreams
[creation/read, no default]  the
number of interleaved streams (minimum 1)
 If a padding scheme is not specified (i.e. the algorithm name is given in
the form "cipherName/InterleavedCBC(nStreams)"), then
PKCSPadding MUST be assumed. The standard
name always specifies which padding method is used, i.e. it always has
three components.
InterleavedPCBC(nStreams)  Blockoriented Mode

 Description:
 Interleaved Propagating Cipher Block Chaining Mode, with nStreams
independent IVs.
The length of the IV array required by
setIV
(or generated
randomly) will be nStreams * blockSize bytes.
 References:
 Parameters:

Integer nStreams
[creation/read, no default]  the
number of interleaved streams (minimum 1)
 Comment:
 If a padding scheme is not specified (i.e. the algorithm name is given in
the form "cipherName/InterleavedPCBC(nStreams)"), then
PKCSPadding MUST be assumed. The standard
name always specifies which padding method is used, i.e. it always has
three components.
InterleavedCFB(nStreams)  Byteoriented Mode

 Description:
 Interleaved Cipher Feedback Mode, with nStreams independent
IVs, and with each feedback vector of equal size to a block. The length of
the IV array required by
setIV
(or generated randomly) will
be nStreams * blockSize bytes.
 References:
 [Inf] U.S. National Bureau of Standards (now NIST),
"DES Modes of Operation,"
NBS FIPS PUB 81,
U.S. Department of Commerce, December 1980.
http://www.itl.nist.gov/div897/pubs/fip81.htm
 [Inf] Bruce Schneier,
"Section 9.6 CipherFeedback Mode," and
"Section 9.12 Interleaving,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] sci.crypt FAQ, "Part 5: Product Ciphers,"
ftp://ftp.rtfm.mit.edu/pub/usenet/news.answers/cryptographyfaq/part05
 Parameters:

Integer nStreams
[creation/read, no default]  the
number of interleaved streams (minimum 1)
 Comment:
 Implementations MUST support immediate processing of individual bytes,
in a similar fashion to a stream cipher. This means that it is never
necessary to specify a padding scheme (and therefore the standard name
always has two components).
CounterBE  Blockoriented Mode

 Description:
 Counter mode, with bigendian representation of block numbers.
 Alias:
 "CTRBE"
 References:
 [Inf] Bruce Schneier,
"Section 9.9 Counter Mode,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf] sci.crypt FAQ, "Part 5: Product Ciphers,"
ftp://ftp.rtfm.mit.edu/pub/usenet/news.answers/cryptographyfaq/part05
 [An] Helger Lipmaa, Phillip Rogaway, David Wagner,
"Comments to NIST Concerning AESmodes of Operations: CTRmode Encryption,"
Symmetric Key Block Cipher Modes of Operation Workshop,
Baltimore, Maryland, U.S., 20 October 2000.
http://www.tml.hut.fi/~helger/papers/lrw00/
 Comments:
 The block number starts at zero for the first block. It is zeropadded
on the left, so that the least significant byte is the last byte
of each block. No IV is used.
 If a padding scheme is not specified (i.e. the algorithm name is given in
the form "cipherName/CounterBE"), then
PKCSPadding MUST be assumed. The standard
name always specifies which padding method is used, i.e. it always has
three components.
 Security comment:
 Because the keystream depends only on the block number and key, this mode
MUST NOT be used to encrypt more than one message with the same key.
CounterLE  Blockoriented Mode

 Description:
 Counter mode, with littleendian representation of block numbers.
 Alias:
 "CTRLE"
 References:
 [see references for CounterBE]
 Comments:
 The block number starts at zero for the first block. It is zeropadded
on the right, so that the least significant byte is the first byte
of each block. No IV is used.
 If a padding scheme is not specified (i.e. the algorithm name is given in
the form "cipherName/CounterLE"), then
PKCSPadding MUST be assumed. The standard
name always specifies which padding method is used, i.e. it always has
three components.
 Security comment:
 Because the keystream depends only on the block number and key, this mode
MUST NOT be used to encrypt more than one message with the same key.
× KFB(m)  Byteoriented Mode

 Designers:
 Johan Håstad, Mats Näslund
 Published:
 October 2000
 Description:
 Key Feedback Mode, with m bits of keystream taken for each
application of the block cipher.
If cipher is a block cipher with block size n bits and
key length also n bits, then the SCAN name "cipher/KFB(m)"
refers to the keystream generator BMGL_{n,m,L}(cipher),
where L is the number of bits of output used (L is not
included in the cipher name because an arbitrary length of plaintext
can be encrypted by a SCAN stream cipher; however, application designers
should bear in mind that the
security bound depends on this value.) m is the number of
bits taken for each iteration of the block cipher; for a given cipher,
a lower m gives a better security bound.
 References:
 [Def, An] Johan Håstad, Mats Näslund,
Key Feedback Mode: A KeyStream Generator with Provable Security,
...
 [Inf, An] Johan Håstad, Mats Näslund,
BMGL: Synchronous Keystream Generator with Provable Security,
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/bmgl.zip
 [Test] Johan Håstad, Mats Näslund,
BMGL Test Values,
https://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/bmgl.zip
 Key length:
 The cipher key length must be the same as its block size.
 Security comment:
 The security bounds proven for KFB with a 256bit block cipher and m = 40,
in Corollary 13 of Håstad and Mats Näslund's paper, hold provided that
less than 2^{30} bits (128 MBytes) of output are used. The "provable
security" referred to in the paper is in the sense of a proven reduction from
predicting the keystream generator to breaking the cipher as a oneway function.
 Alias:
 "CiphertextStealing"
 References:
 [Def] Bruce Schneier,
"Section 9.1 Electronic Code Book Mode,"
"Figure 9.1 Ciphertext stealing in ECB mode,"
"Section 9.3 Cipher Block Chaining Mode," and
"Figure 9.5 Ciphertext stealing in CBC mode,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
 [Inf, Test] Ron Rivest,
"The RC5, RC5CBC, RC5CBCPad, and RC5CTS Algorithms,"
RFC 2040, October 1996.
 Comments:
 CTS is only defined for block ciphers in ECB and CBC modes.
 The "RC5CTS" mode in RFC 2040 is equivalent to RC5/CBC/CTS; this gives
a source of test vectors, at least for one cipher.
 The amount of data that must be buffered by the cipher implementation
is increased when ciphertext stealing is used (specifically, up to
two blocks can be buffered, for both encryption and decryption).
 If the total length of plaintext or ciphertext, excluding IV, is less
than or equal to one block when
doFinal
is called, a
BadPaddingException
will be thrown. (I.e. the minimum
length of plaintext that can be encrypted is one block plus one byte.)
 The diagrams in Applied Cryptography do not make clear the behaviour
when the plaintext or ciphertext length is an exact number of blocks.
In this case the "last" block is considered to be the last complete
block, rather than being of zerolength. This matches the specification
in section 8 of RFC 2040. Note that in this case the last two blocks of
the ciphertext will be interchanged when compared with ECB or CBC mode
with NoPadding.
 Description:
 An algorithm that appends (using bigendian bit order) a
single binary 1 bit, followed by as many binary 0 bits as needed
to complete a block. Viewed in terms of bytes, this corresponds
to a byte of 0x80, followed by as many 0x00 bytes as needed to
complete a block.
 Aliases:
 "PKCS#5", "PKCS#7", "PKCS5Padding"
 Description:
 The padding scheme described in PKCS #7 section 10.3, note 2
(this is a generalisation of the scheme described in PKCS #5
section 6.2, to block sizes between 1 and 255 bytes inclusive).
 References:
 Comment:
 When this algorithm is referenced using the "PKCS#5" or "PKCS5Padding" aliases,
it should not be assumed that block sizes other than 8 bytes will be supported.
 Description:
 Trailing Bit Complement. The data is padded with the complement
of the trailing bit (that is, the least significant bit of the
last byte) of the unpadded message: if the trailing bit
is '1', then '0' bits are appended, and if the trailing bit is
'0', then '1' bits are appended. Viewed in terms of bytes, this
corresponds to adding between 1 byte and a full block of 0x00 or
0xFF.
 References:
 Comment:
 TBC is rarely used compared to other padding schemes.
 Description:
 An algorithm name used to specify that for encryption, a
BadPaddingException
will be thrown when the
plaintext input is not an exact number of blocks, and for
decryption, that no unpadding will be done.
 Alias:
 "NONE"
Other Alleged Padding Schemes
 The SunJCE provider defines SSL3Padding, which is intended
to specify the padding method used in the SSL 3.0 protocol. However,
that algorithm cannot be used to implement padding in a way that is
compliant with SSL 3.0 (since there is no way to correctly support
records that use more than the minimum amount of padding).
For each symmetric cipher, there is a KeyGenerator with the same standard name and
aliases, that can be used to generate random keys for that cipher. Since the valid
key lengths, and any comments on the key encoding are given with the cipher
descriptions (and there is generally only one valid key encoding for a symmetric
cipher), there is no need for each KeyGenerator algorithm to be described separately.
Typically, the default key length for each algorithm is the one that will be used
in most cases. For DESede (Triple DES) and AES, more than one key length is,
or will be in common use (for example,
OpenPGP has three
different algorithm numbers for AES, according to key length).
For that reason, we specify three key generator names for AES, and two for DESede,
with different default key lengths. This should allow a more straightforward
mapping between a SCAN name, and the algorithms specified in various standards.
 Description:
 A KeyGenerator for AES with 128bit keys.
 Alias:
 "OpenPGP.Cipher.7"
 Object Identifiers:
 "2.16.840.1.101.3.4.1.1", "2.16.840.1.101.3.4.1.2", "2.16.840.1.101.3.4.1.3", "2.16.840.1.101.3.4.1.4"
 References:
 [see references for AES]
 Description:
 A KeyGenerator for AES with 192bit keys.
 Alias:
 "OpenPGP.Cipher.8"
 Object Identifiers:
 "2.16.840.1.101.3.4.1.21", "2.16.840.1.101.3.4.1.22", "2.16.840.1.101.3.4.1.23", "2.16.840.1.101.3.4.1.24"
 References:
 [see references for AES]
 Description:
 A KeyGenerator for AES with 256bit keys.
 Aliases:
 "AES", "OpenPGP.Cipher.9"
 Object Identifiers:
 "2.16.840.1.101.3.4.1.41", "2.16.840.1.101.3.4.1.42", "2.16.840.1.101.3.4.1.43", "2.16.840.1.101.3.4.1.44"
 References:
 [see references for AES]
 Description:
 A KeyGenerator for DESede with 2 independent
single DES keys (i.e. 128 bits of key material).
 References:
 [see references for DESede]
 Description:
 A KeyGenerator for DESede with 3 independent
single DES keys (i.e. 192 bits of key material).
 Alias:
 "OpenPGP.Cipher.2"
 References:
 [see references for DESede]
Alleged Symmetric Ciphers
 CAST, CAST3 are earlier versions of
CAST128
 LOKI89 is an earlier version of
LOKI91.
 E0 (used in the Bluetooth protocols).
 FEAL (variable # of rounds) is
broken.
 Khufu and Khafre are
broken.
 Akelarre (several versions) is broken.
 Cipherunicorn.
 Dogfish.
 GDES.
 NewDES.
 BEAST.
 BEAR, LION, LIONESS are PRP/SPRP constructions (need a new
category for these?)
Hand ciphers (these often work on a restricted character set rather than
bytes):