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, SAFER-K and SAFER-SK). 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, "DES-Direct" and "SAFER-Direct" 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 backward-incompatible change, although an alias has been added for "Blowfish-ISK".] If the subkeys are not in fact random and independent (to a close-enough approximation), the cipher may become vulnerable to related-key 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.

3-Way
Designer: Joan Daemen Published: 1994 Alias: "ThreeWay" (use for identifiers) Key length: 96 bits. Block size: 12 bytes. Comment:

Block Cipher

The byte ordering convention is as follows: within each 12-byte block, the 32-bit words are represented in the same order as they are written in chapter 7 of Joan Daemen's thesis. Within each 32-bit 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: 3-Way is vulnerable to related-key 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).

AES128
Designers: Joan Daemen, Vincent Rijmen Alias: "OpenPGP.Cipher.7" Object Identifiers:

Block Cipher

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 128-bit block size and 10 rounds. Key length: 128 bits. Block size: 16 bytes.

AES192
Designers: Joan Daemen, Vincent Rijmen Alias: "OpenPGP.Cipher.8" Object Identifiers:

Block Cipher

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 128-bit block size and 12 rounds. Key length: 192 bits. Block size: 16 bytes.

AES256
Designers: Joan Daemen, Vincent Rijmen Alias: "OpenPGP.Cipher.9" Object Identifiers:

Block Cipher

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 128-bit block size and 14 rounds. Key length: 256 bits. Block size: 16 bytes.

Anubis

Block Cipher

Designers: Paulo Barreto, Vincent Rijmen Published: November 2000 Key length: Minimum 128, maximum 320, multiple of 32 bits; default 128 bits. Block size: 16 bytes.

Blowfish
Designer: Bruce Schneier Published: 1994 Alias: "OpenPGP.Cipher.4" Key length: Minimum 32, maximum 448, multiple of 8 bits; default 128 bits. Block size:

Block Cipher

8 bytes. Security comment: The weak keys described in Vaudenay's paper do not appear to be significant for full (16-round) Blowfish. Variant: "Blowfish-Direct" or "Blowfish-ISK" - the subkeys are specified (using the notation of Applied Cryptography) as P1..18 first, followed by S1, 0..255, S2, 0..255, S3, 0..255, and S4, 0..255. Each entry is represented as 4 bytes in big-endian order. Weak keys may be avoided by ensuring that no S-box has duplicate entries (i.e. that there does not exist i, j, k where j != k such that Si, j = Si, k).

BMGL

Stream Cipher

Designers: Johan Hstad, Mats Nslund Published: October 2000 Description: BMGL is an alias for "Rijndael-256/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. 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 Hstad and Nslund's paper, hold provided that less than 230 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 Rijndael-256 as a one-way function.

CAST-128

Block Cipher

Designers: Carlisle Adams, Stafford Tavares Published: 1997 Aliases: "CAST5", "OpenPGP.Cipher.3" 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 CAST-128 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 S-boxes is patented by Entrust Technologies, Inc.. However, quoting from RFC 2144, The CAST-128 cipher described in this document is available worldwide on a royalty-free basis for commercial and non-commercial uses.

CAST-256

Block Cipher

Designer: Carlisle Adams, Howard Heys, Stafford Tavares, Michael Wiener Published: June 1998 Alias: "CAST6" 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 S-boxes is patented by Entrust Technologies, Inc.. However, quoting from RFC 2612, The CAST-256 cipher described in this document is available worldwide on a royalty-free and licence-free basis for commercial and non-commercial uses.

CRYPTON-0.5

Block Cipher

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. Comment: "CRYPTON: A New 128-bit Block Cipher - Specification and Analysis" contains an error in the description of the byte permutation phi: on the right hand side of figure 4, b33 should be b03. 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]] CRYPTON-0.5 has been superceded by CRYPTON-1.0.

CRYPTON-1.0

Block Cipher

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). Key length: Minimum 0, maximum 256, multiple of 8 bits; default 128 bits. (Note that this is different from CRYPTON-0.5.) Block size: 16 bytes.

CS-Cipher

Block Cipher

Designers: Jacques Stern, Serge Vaudenay Published: 1998 Key length: Minimum 0, maximum 128, multiple of 8 bits; default 128 bits. Block size: 8 bytes. Patent status: CS-Cipher may be subject to patents by the Compagnie des Signaux.

DEAL

Block Cipher

Designer: Lars Knudsen Published: May 1998 Key length: 128, 192 or 256 bits; default 128 bits. Block size: 16 bytes. Comment: The paper "DEAL: A 128-bit 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 128-Bit 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 related-key attacks and equivalent keys for DEAL (described in the DEAL AES forum on NIST's web site, and in the paper "Key-Schedule 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 Davies-Meyer).
Block Cipher

DES

Designers: Don Coppersmith, Horst Feistel, Walt Tuchmann, U.S. National Security Agency Published: 1976 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 56-bit effective key length is too short to prevent brute-force attacks.

DESede
Designers: Whitfield Diffie, Martin Hellman, Walt Tuchmann Published: 1978-79 Aliases:

Block Cipher

"DES-EDE2" (always 2-key) "DES-EDE3", "OpenPGP.Cipher.2" (always 3-key) "TripleDES", "3DES" (default key length implemented inconsistently by different providers)

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 DES-EDE3 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. two-key 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. three-key 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 2108 steps of computation are sufficient to break three-key triple DES. If one concentrates on the number of single DES operations and assumes the other operations to be much faster, 290 of these are enough. Better attacks than this are available against two-key triple DES (which should only be used for backward compatibility, if at all).

DESX

Block Cipher

Designer: Ron Rivest Description: If K, K1 and K2 are the subkeys encoded as described below, then encryption and decryption are defined by: EDESX[K, K1, K2](P) = EDES[K](P XOR K1) XOR K2 DDESX[K, K1, K2](C) = DDES[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. Key length: 128 or 192 bits; default 192 bits, as encoded. See security comments for the effective key length.

Block size: 8 bytes. Comments:

Implementations MUST ignore (i.e. not check) the parity bits of the singleDES key. KeyGenerators for DESX SHOULD generate entirely random keys (possibly avoiding DES weak keys). In the case of a 16-byte key, the input to the "hash procedure" which generates K2 is the original user key, without any adjustment to parity. There do not appear to be any "official" test vectors for DESX, so for reference we provide the following (the first was calculated using Mark Riordan's C implementation, and the second by hand based on official DES test data):
key = <0123456789ABCDEF1011121314151617> plaintext = <4445535864657378> ciphertext = <D8FA5084FAD4B35C> key = <01010101010101010123456789ABCDEF1011121314151617> plaintext = <94DBE082549A14EF> ciphertext = <9011121314151617>

Security comments:

The paper "How to protect DES against exhaustive key search" proves that attacks on DESX that assume a "black-box" model for DES require a work factor of 2118. 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 related-key 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).
Block Cipher

DFC

Designers: Henri Gilbert, Marc Girault, Philippe Hoogvorst, Fabrice Noilhan, Thomas Pornin, Guillaume Poupard, Jacques Stern, Serge Vaudenay Published: May 1998 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.

DFCv2-128(rounds,s)

Block Cipher

Designers: Louis Granboulan, Phong Nguyen, Fabrice Noilhan, Serge Vaudenay Published: August 2000 Parameters:

[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?)
Integer rounds

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 well-specified 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)
Designer: Michael Paul Johnson Published: 1995 Parameters:

Block Cipher

[creation/read, no default] - the number of rounds to be performed (minimum 10)

Integer rounds

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

E2

Designers: Kazumaro Aoki, Masayuki Kanda, Tsutomu Matsumoto, Shiho Moriai, Kazuo Ohta, Miyako Ookubo, Youichi Takashima, Hiroki Ueda Published: June 1998 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])]
Designers: Dianelos Georgoudis, Damian Leroux, Billy Simn Chaves Published: 1998 Parameters:
Integer blockSize

Block Cipher

[creation/read, default 16] - the length of a block in bytes

(8 to 128) [creation/read, default 8] - the number of rounds to be performed (minimum 8)

Integer rounds

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 Javareference 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 258 chosen plaintexts and very little time for the analysis; it works for about 2-33.0 of the keyspace. A linear attack that uses 256 known texts and works for 2-31.8 of the keyspace. A ciphertext-only linear attack using 264 ciphertexts (also for 2-31.8 of the keyspace).

A differential attack on the decryption function that requires 236 chosen ciphertexts and works for 2-29.3 of the keyspace.
Block Cipher

? GOST
Alias: "GOST-28147-89" Published: 1989 Parameters:

[write only, default as given in Applied Cryptography] the S-boxes to be used by this cipher instance. sboxes[i-1][j] represents the output of S-box i, for an input valuej. 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.
byte[][] sboxes

Key length: 256 bits. Block size: 8 bytes. Missing information: Test vectors. Security comment: The paper "A chosen key attack against the secret S-boxes of GOST" cited above describes how to recover the S-boxes in about 232 encryptions. The main significance of this is on tamperproof hardware implementations where the S-boxes were assumed to be secret; for a software implementation, they should be assumed to be public in any case.

HPC-1(blockSize[,backup])

Block Cipher

Designer: Rich Schroeppel Published: 1998 Description: This is the original HPC cipher submitted as a first round AES candidate. Parameters:
Integer blockSize

[creation/read, default 16] - the length of a block in bytes

(minimum 1)

[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 all-zeroes] - an array of 8 64-bit 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.
Integer backup

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 high-order bits of the last byte of the encoding. Any unused low-order bits of the last byte are ignored. For example, the key given by the 11-bit sequence <01010101 010>2, would be encoded as the byte array { 0x55, 0x40 | junk }, wherejunk & 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 128-bit keys, has an expected work factor of 289, and works for 1/256 of the keyspace. The analysis is extended to HPC with a 192-bit key and a 256-bit 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 HPC-2) is intended to correct this problem, but has not yet had a significant amount of analysis. Also note that with the default all-zeroes spice value, much of the work being done by the cipher has no cryptographic effect.
Block Cipher

? HPC-2(blockSize[,backup])

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

Parameters:
Integer blockSize

[creation/read, default 16] - the length of a block in bytes

(minimum 1) [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 all-zeroes] - an array of 8 64-bit 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.
Integer backup

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 HPC-1] Security comment:

Note that with the default all-zeroes spice value, much of the work being done by the cipher has no cryptographic effect.
Block Cipher

ICE

Designer: Matthew Kwan Published: 1997 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 256 work and at most 256 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 3-round 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 3-round characteristic for LOKI91 (a similar block cipher that makes use of four identical 12 to 8-bit S-boxes). 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.

IDEA
Designers: Xuejia Lai, James Massey Published: 1992 Alias: "OpenPGP.Cipher.1" Object Identifiers:

Block Cipher

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 Key length:

128 bits. Block size: 8 bytes. Comments:

A version of the IDEA C reference code available in April and early May 1999 contained a bug in the code for multiplication mod 216+1, which occurs when multiplying two zero words; this bug is not caught by the standard test vectors. An additional test vector that does catch the bug (and incidentally demonstrates a weakness of IDEA's key schedule, but that's beside the point) is:
key = <00000000000000000000000000000000> plaintext = <0000000000000000> ciphertext = <0001000100000000>

The test vectors, reference implementation and papers that were previously available from the Ascom web site (including the important paper on side channel attack hardening) have all disappeared from that site.

Congratulations to Ascom, iT_Security, Mediacrypt, or whatever its name is this week, for providing an excellent example of how not to handle web site reorganisations. Fortunately all of these files were recoverable from web.archive.org (thanks to Jason Harris for pointing this out). 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.

ISAAC-BE

Stream Cipher

Designer: Robert J. Jenkins Jr. Published: 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.

? JEROBOAM

Stream Cipher

Designers: Herv Chabanne, Emmanuel Michon Published: 1998 Description: This algorithm refers to JEROBOAM version 2.0. Alias: "JEROBOAM-2.0" Key length: 128 or 248 bits Missing information: I have not yet read either of the referenced papers, so I don't know whether byte-order is specified, status of test vectors, etc.

LEVIATHAN-BE
Designers: David McGrew, Scott Fluhrer Published: October 2000

Stream Cipher

Description: This is LEVIATHAN using big-endian byte order, when XORing the keystream with the plaintext for encryption. Key length: 128 or 256 bits Security comment: The output of LEVIATHAN can be distinguished from a random stream given about ??? MBytes of output.

LEVIATHAN-LE

Stream Cipher

Designers: David McGrew, Scott Fluhrer Published: October 2000 Description: This is LEVIATHAN using little-endian byte order, when XORing the keystream with the plaintext for encryption. Key length: 128 or 256 bits Security comment: [see Security comment for LEVIATHAN-BE]

LOKI91

Block Cipher

Designers: Laurence Brown, Matthew Kwan, Josef Pieprzyk, Jennifer Seberry Published: 1991-92 Key length: 64 bits. Block size: 8 bytes. Security comments:

LOKI91 is vulnerable to related-key attacks, with a work factor of about 260 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 reduced-round variants of LOKI91 with up to 12 rounds (the full cipher has 16 rounds). The fixed 64-bit key length is too short to prevent brute-force attacks.
Block Cipher

LOKI97
Designers: Laurence Brown, Josef Pieprzyk, Jennifer Seberry

Published: 1997 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 256 chosen plaintexts, and an attack using Linear Cryptanalysis, estimated as requiring at most 256 known plaintexts.

MAGENTA

Block Cipher

Designers: Michael Jacobson Jr., Klaus Huber Published: August 1998 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 264 chosen plaintexts, and 264 work. It also notes that "given a ciphertext, one can decrypt it by swapping its two halves, re-encrypting 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).

MARS

Block Cipher

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: "MARS-2" 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 royalty-free basis, worldwide, regardless of AES outcome." (See this press release.) However, it is not clear whether "royaltyfree" excludes the possibility of up-front license fees.

? MDC

Stream Cipher

Designer: Peter Gutmann Published: October 1992 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 MDC-2 and MDC-4 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)]
Designer: M. Matsui Published: January 1997 Parameters:

Block Cipher

[creation/read, default 8] - the number of rounds to be performed (minimum 8, multiple of 4)

Integer rounds

Key length: 128 bits. Block size: 8 bytes.

? MISTY2[(rounds)]
Designer:

Block Cipher

M. Matsui Published: January 1997 Parameters:

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

Key length: 128 bits. Block size: 8 bytes. Missing information: Test vectors.

Noekeon[(rounds)]

Block Cipher

Designers: Joan Daemen, Michal Peeters, Gilles van Assche, Vincent Rijmen Published: November 2000 Parameters:

[creation/read, default 16] - the number of rounds to be performed (minimum 16)

Integer rounds

Key length: 128 bits. Block size: 16 bytes.

Noekeon-Direct[(rounds)]

Block Cipher

Designers: Joan Daemen, Michal Peeters, Gilles van Assche, Vincent Rijmen Published: November 2000 Description: This is the "direct-key" 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. Parameters:

[creation/read, default 16] - the number of rounds to be performed (minimum 16)

Integer rounds

Key length: 128 bits.

Block size: 16 bytes.

? Panama

Stream Cipher

Designers: Joan Daemen, Craig Clapp Published: 1998 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.

? Rainbow

Block Cipher

Designers: Chang-Hyi Lee, Jeong-Soo Kim Key length: Minimum 128, maximum 256, multiple of 32 bits; default 128 bits. Block size: 16 bytes. Missing information: Test vectors. Comment: Only the 128-bit block version is defined as a SCAN algorithm.

RC2
Designer: Ron Rivest Published: 1998 Key length: Minimum 0; maximum 1024, multiple of 8 bits; default 128 bits. Block size: 8 bytes. Comment:

Block Cipher

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

RC4

Stream Cipher

Designer: Ron Rivest Published: September 1994 (see Comment section below) Alias: "ARCFOUR" 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 RC4-drop for further discussion. The RC4 keystream is distinguishable from random given about 2 Gbytes of the stream. RC4 is vulnerable to related-key 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).
Stream Cipher

RC4-drop[(nbytes)]

Description: This algorithm is the same as RC4, except that the first nbytes bytes of keystream are discarded after key scheduling.

Alias: "MARK-4" is an alias for RC4-drop(256). Parameters:

[creation/read, default 768] - the number of bytes to be dropped after key scheduling (minimum 0, maximum 65536)
Integer nbytes

Key length: Minimum 8, maximum 2048, multiple of 8 bits; default 128 bits. Comments:

For the purposes of SCAN, "RC4-drop" 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 "MARK-4" for RC4-drop(256) was apparently suggested by Bryan Olson, in a posting to sci.crypt. In SCAN 1.0.15, "MARK-4" was a standard name rather than an alias; this is technically an incompatible change.

Security comments:

The RC4 keystream is distinguishable from random given about 2 Gbytes of the stream (independent of how many bytes are dropped). The paper by Ilya Mironov says: Our most conservative recommendation is based on the experimental data on the tail probability of the strong uniform time T (Section 5.5). This means that discarding the initial 12 256 bytes most likely eliminates the possibility of a strong attack. Dumping several times more than 256 bytes from the output stream (twice or three times this number) appears to be just as reasonable a precaution. We recommend doing so in most applications. I.e. the "most conservative" recommendation is to use RC4-drop(3072), but RC4-drop(768) "appears to be just as reasonable". The latter is the default for this algorithm.

Unmodified RC4 is vulnerable to related-key and other key scheduling attacks. Despite the fact that discarding the first 768 bytes of keystream appears to prevent the known attacks, it is still recommended to use RC4drop only 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).

RC5[(rounds)]
Designer: Ron Rivest Published: January 1995 Alias: "RC5-32" Parameters:

Block Cipher

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

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 RC5-64). 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 RC5-64 are patented by RSA Security, Inc.

? RC5-64[(rounds)]
Designer: Ron Rivest Published: January 1995 Parameters:

Block Cipher

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

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 RC5-64). 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 RC5-64 are patented by RSA Security, Inc.

RC6[(rounds)]

Block Cipher

Designers: Ron Rivest, Matthew Robshaw, Raymond Sidney, Yiqun Lisa Yin Published: 1998? Alias: "RC6-32" Parameters:

[creation/read, default 20] - the number of rounds to be performed (minimum 8, multiple of 4)

Integer rounds

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 RC6-64). Patent status: RSA Security, Inc., has several patents pending on RC6 (covering all versions).

? RC6-64[(rounds)]

Block Cipher

Designers: Ron Rivest, Matthew Robshaw, Raymond Sidney, Yiqun Lisa Yin Published: 1998?

Parameters:

[creation/read, default 20] - the number of rounds to be performed (minimum 8, multiple of 4)

Integer rounds

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 RC6-64). Patent status: RSA Security, Inc., has several patents pending on RC6 (covering all versions).

Rijndael

Block Cipher

Designers: Joan Daemen, Vincent Rijmen Published: November 1998 Description: This is Rijndael with a 128-bit block size. The number of rounds is 6 + max(Nk, Nb), where Nb = 4, and Nk is the number of 32-bit words in the key. 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 "Rhine-dahl".
Block Cipher

Rijndael-160
Designers: Joan Daemen, Vincent Rijmen Published: November 1998

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

Rijndael-192

Block Cipher

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

Rijndael-224

Block Cipher

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

Rijndael-256
Designers: Joan Daemen, Vincent Rijmen

Block Cipher

Published: November 1998 Description: This is Rijndael with a 256-bit block size. The number of rounds is always 14. Key length: Minimum 128, maximum 256, multiple of 32 bits; default 128 bits. Block size: 32 bytes. Comments: [see comments for Rijndael]

SAFER-K[(rounds)]

Block Cipher

Designer: James Massey Published: December 1993. Description: This algorithm refers to the original version of SAFER, designed in 1993. Parameters:

[creation/read, default null (indicating key-lengthdependent)] - the number of rounds to be performed (minimum 6). When the value of this property is null, 6 rounds are used for a 64-bit key, and 10 rounds for a 128-bit key.
Integer rounds

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 K-64", "SAFER K-128", etc. Because a SCAN algorithm may have variable-length keys, all of these are referred to as "SAFER-K". Security comment: As a result of the key schedule attack by Lars Knudsen cited above, SAFER-K has been superceded by SAFER-SK.

SAFER-SK[(rounds)]
Designer: James Massey Published: September 1995. Description:

Block Cipher

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 SAFER-SK(13). Parameters:

[creation/read, default null (indicating key-lengthdependent)] - the number of rounds to be performed (minimum 8). When the value of this property is null, 8 rounds are used for a 64-bit key, and 10 rounds for a 128-bit key.
Integer rounds

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 SK-64", "SAFER SK-128", etc. Because a SCAN algorithm may have variable-length keys, all of these are referred to as "SAFER-SK". SAFER_SK.TXT suggests a maximum of 10 rounds for a 64-bit key, and 12 rounds for a 128-bit 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 128-bit key with 8 or 9 rounds (i.e. less than the default), but this is definitely not recommended. A 40-bit key schedule has also been specified for SAFER-SK; this is not required to be implemented, and application designers should not assume that a SAFER-SK implementation will support 40-bit keys.
Block Cipher

SAFER+

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"

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 theJava 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 (meet-in-the-middle 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++.

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 128-bit block size. Key length: 128 or 256 bits; default 128 bits. Block size: 16 bytes.

Block Cipher

SAFER++-64

Block Cipher

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 64-bit block size and 128bit key. Key length: 128 bits. Block size:

8 bytes.

Sapphire-II

Stream Cipher

Designer: Michael Paul Johnson Published: January? 1995 Key length: Minimum 8, maximum 2040, multiple of 8 bits; default 128 bits. Missing information: Test vectors.

Scream

Stream Cipher

Designers: Ran Canetti, Don Coppersmith, Rosario Gennaro, Shai Halevi, Nick Howgrave-Graham, Charanjit Jutla, Tal Rabin, J. R. Rao Published: February 2002 Key length: 128 bits.

Scream-F

Stream Cipher

Designers: Ran Canetti, Don Coppersmith, Rosario Gennaro, Shai Halevi, Nick Howgrave-Graham, Charanjit Jutla, Tal Rabin, J. R. Rao Published: February 2002 Key length: 128 bits.

SEAL-3.0-BE[(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 big-endian byte order when XORing the keystream with the plaintext for encryption. See the Comment section below. Parameters:

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

Key length: 160 bits. Comments:

The internal operation of SEAL is endian-neutral, and is intentionally left unspecified in the paper "A software-optimized encryption algorithm." We therefore define two different algorithm names: SEAL-3.0-BE for bigendian operation, and SEAL-3.0-LE for little-endian operation. Note that big-endian order is consistent with SHA-1 (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 little-endian processors (or as suggested by Rogaway and Coppersmith, the ciphertext could be labelled with the byte-order 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 244 bytes. Patent status: SEAL is patented in the United States by IBM.

SEAL-3.0-LE

Stream Cipher

Designers: Phillip Rogaway, Don Coppersmith Published: September 1997 Alias: "SEALv3LE" (use for identifiers) Description: This is version 3.0 of SEAL, using little-endian byte order when XORing the keystream with the plaintext for encryption. See the Comment section for SEAL-3.0-BE. Parameters:

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

Key length: 160 bits.

Comment: [see comment for SEAL-3.0-BE] Patent status: [see patent status for SEAL-3.0-BE]

Serpent
Designers: Ross Anderson, Eli Biham, Lars Knudsen Published: 1998? Key length: Minimum 0, maximum 256, multiple of 8 bits; default 128 bits. Block size: 16 bytes. Comments:

Block Cipher

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 theJava reference implementation, and by the NIST test vectors referenced above (i.e. little-endian 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.

SHARK-A

Block Cipher

Designers: Vincent Rijmen, Joan Daemen, Bart Preneel Antoon Bosselaers, Erik De Win Designers: This is the "Affine Transformation" variant of SHARK. 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.

SHARK-E

Block Cipher

Designers: Vincent Rijmen, Joan Daemen, Bart Preneel Antoon Bosselaers, Erik De Win Designers: This is the "Exor" variant of SHARK. 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.

SKIPJACK

Block Cipher

Designer: U.S. National Security Agency Published: June 1998 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 SkipJack-3XOR (SkipJack minus 3 XORs). The only difference between SkipJack and SkipJack-3XOR 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.

SNOW
Designer: ?

Stream Cipher

Published: November 2000 Key length: Minimum ?, maximum ?, multiple of ? bits; default 128 bits.

SOBER-t16
Designer: ? Published: November 2000 Key length: Minimum ?, maximum ?, multiple of ? bits; default 128 bits.

Stream Cipher

SOBER-t32
Designer: ? Published: November 2000 Key length: Minimum ?, maximum ?, multiple of ? bits; default 128 bits.

Stream Cipher

SPEED-64[(rounds)]
Designer: Yuliang Zheng Published: February 1997 Parameters:

Block Cipher

[creation/read, default 64] - the number of rounds to be performed (minimum 64, multiple of 4)
Integer rounds

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

SPEED-128[(rounds)]
Designer: Yuliang Zheng Published: February 1997

Block Cipher

Parameters:

[creation/read, default 64] - the number of rounds to be performed (minimum 48, multiple of 4)
Integer rounds

Key length: Minimum 48, maximum 256, multiple of 16 bits; default 128 bits. Block size: 16 bytes.

SPEED-256[(rounds)]
Designer: Yuliang Zheng Published: February 1997 Parameters:

Block Cipher

[creation/read, default 64] - the number of rounds to be performed (minimum 48, multiple of 4)
Integer rounds

Key length: Minimum 48, maximum 256, multiple of 16 bits; default 128 bits. Block size: 32 bytes.

Square[(rounds)]
Designers: Joan Daemen, Vincent Rijmen Published: 1997 Parameters:

Block Cipher

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

Integer rounds

Key length: 128 bits. Block size: 16 bytes.

? TEA
Designers: David Wheeler, Roger Needham Published: 1994 Key length:

Block Cipher

128 bits. Block size: 8 bytes. Missing information: Test vectors. Comment:

Big-endian byte order is used when converting the plaintext, ciphertext, and key to 32-bit 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 well-defined (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 related-key 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).

Twofish

Block Cipher

Designers: Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson Published: 1998 Alias: "OpenPGP.Cipher.10" [[implies 256-bit key]] 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 128-bit Block Cipher," for key lengths between 8 and 64 bits inclusive. A strict reading of the specification would zero-pad these keys to 128 bits, and use k = 2; the reference implementations zero-pad 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).

? WAKE-CFB-BE
Designer: David Wheeler

Stream Cipher

Published: 1993 Description: This is WAKE in CFB mode, using big-endian byte order. See the Comments section below. Key length: 128 bits. Missing information: Test vectors. Comments:

The internal operation of WAKE is endian-neutral, 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: WAKECFB-BE for big-endian operation, and WAKE-CFB-LE for little-endian operation. Note that this applies only to the byte order of the keystream words to be exclusive-or'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 big-endian order (which is consistent with the implementation in Wei Dai's Crypto++ library).

Security comments:

WAKE is insecure against a chosen-plaintext or chosen-ciphertext attack. If a section of plaintext [[of what length?]] is zero, 32 bits of the key are revealed.
Stream Cipher

? WAKE-CFB-LE

Designer: David Wheeler Published: 1993 Description: This is WAKE in CFB mode, using little-endian byte order. See the Comments section for WAKE-CFB-BE. Key length: 128 bits. Missing information: Test vectors. Comments:

[see comments for WAKE-CFB-BE]

There has an incompatible change in this algorithm since SCAN version 1.0.7; the input key words are now always interpreted as big-endian.

Security comments: [see security comments for WAKE-CFB-BE]

WiderWake4+1-BE

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 big-endian byte order. See the Comments section below. 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 endian-neutral, and is intentionally left unspecified in the paper cited above. We therefore define two different algorithm names for each variant of WiderWake: WiderWake4+1-BE and WiderWake4+3-BE for big-endian operation, and WiderWake4+1-LE and WiderWake4+3-LE for little-endian operation. Note that this applies to the byte order of the keystream words to be exclusive-or'd with the plaintext and ciphertext, and to the IV. The 128-bit input key is always represented in bigendian order. WiderWake has a resynchronisation procedure, which uses an 8-byte IV to randomise the feedback words. This IV is represented as two 32-bit 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 big-endian, and support for resynchronisation has been added.
Stream Cipher

WiderWake4+1-LE

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 little-endian byte order. See the Comments section for WiderWake4+1-BE. Key length: 128 bits.

? WiderWake4+3-BE

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 big-endian byte order. See the Comments section for WiderWake4+1-BE. Key length: 128 bits. Missing information: Test vectors.

? WiderWake4+3-LE

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 little-endian byte order. See the Comments section for WiderWake4+1-BE. Key length: 128 bits. Missing information: Test vectors. Comments: [see comments for WiderWake4+1-BE]

PBE-PKCS5(digestName,DES/CBC)
Designers:

Block Cipher Construction

RSA Security, Inc. Aliases:

"pbeWithMD2AndDES-CBC" and "PBEWithMD2AndDES" for PBEPKCS5(MD2,DES/CBC). "pbeWithMD5AndDES-CBC" and "PBEWithMD5AndDES" for PBEPKCS5(MD5,DES/CBC).

Object Identifiers:

1.2.840.113549.1.5.1 for PBE-PKCS5(MD2,DES/CBC). 1.2.840.113549.1.5.3 for PBE-PKCS5(MD5,DES/CBC).

Description: The passphrase-based 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 passphrase-based encryption in SCAN is described in the documentation forPassphraseHash. Parameters:

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

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 passphrase-based cipher constructions. Security comment: The 56-bit effective key length is too short to prevent brute-force attacks.

PBE-PKCS12(digestName,cipherName [,keyLength])
Designers: RSA Security, Inc. Aliases:

Cipher Construction

"pbeWithSHAAnd128BitRC4" for PBE-PKCS12(SHA-1,RC4,128). "pbeWithSHAAnd40BitRC4" for PBE-PKCS12(SHA-1,RC4,40). "pbeWithSHAAnd3-KeyTripleDES-CBC" for PBE-PKCS12(SHA1,DESede/CBC,168). "pbeWithSHAAnd2-KeyTripleDES-CBC" for PBE-PKCS12(SHA1,DESede/CBC,112). "pbeWithSHAAnd128BitRC2-CBC" for PBE-PKCS12(SHA1,RC2/CBC,128). "pbeWithSHAAnd40BitRC2-CBC" for PBE-PKCS12(SHA1,RC2/CBC,40).

Object Identifiers:

1.2.840.113549.1.12.1.1 for PBE-PKCS12(SHA-1,RC4,128). 1.2.840.113549.1.12.1.2 for PBE-PKCS12(SHA-1,RC4,40). 1.2.840.113549.1.12.1.3 for PBE-PKCS12(SHA-1,DESede/CBC,168). 1.2.840.113549.1.12.1.4 for PBE-PKCS12(SHA-1,DESede/CBC,112). 1.2.840.113549.1.12.1.5 for PBE-PKCS12(SHA-1,RC2/CBC,128). 1.2.840.113549.1.12.1.6 for PBE-PKCS12(SHA-1,RC2/CBC,40).

Description: The passphrase-based 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 passphrase-based encryption in SCAN is described in the documentation forPassphraseHash. Parameters:

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

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:

PBE-PKCS12 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.

NullCipher

Stream Cipher

Description: A "no-op" 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 no-op algorithm, it would not be valid for applications to assume that an arbitrary Cipher object or algorithm will provide adequate security.)

Block Cipher Modes

Symmetric block cipher modes fall into two categories: block-oriented and byteoriented. For block-oriented 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 byte-oriented 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 byte-oriented. The last two of these are deprecated.

ECB

Block-oriented Mode

Description: Electronic Codebook Mode, as defined in NBS FIPS PUB 81. 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.

CBC

Block-oriented Mode

Description: Cipher Block Chaining Mode, as defined in NBS FIPS PUB 81. 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.

PCBC

Block-oriented Mode

Description: Propagating Cipher Block Chaining Mode. 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)]

Byte-oriented 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. Parameters:

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

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

OFB
Description:

Byte-oriented Mode

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. 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 266 bytes to 234 bytes, for a cipher with a block size of 8 bytes).
Block-oriented Mode

InterleavedCBC(nStreams)

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. Parameters:

[creation/read, no default] - the number of interleaved streams (minimum 1)

Integer nStreams

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)

Block-oriented 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. Parameters:

[creation/read, no default] - the number of interleaved streams (minimum 1)

Integer nStreams

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)
Description:

Byte-oriented Mode

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. Parameters:

[creation/read, no default] - the number of interleaved streams (minimum 1)

Integer nStreams

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

Counter-BE

Block-oriented Mode

Description: Counter mode, with big-endian representation of block numbers. Alias: "CTR-BE" Comments:

The block number starts at zero for the first block. It is zero-padded 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/Counter-BE"), 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.

Counter-LE

Block-oriented Mode

Description: Counter mode, with little-endian representation of block numbers. Alias: "CTR-LE" Comments:

The block number starts at zero for the first block. It is zero-padded 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/Counter-LE"), 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)

Byte-oriented Mode

Designers: Johan Hstad, Mats Nslund 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 BMGLn,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. Key length: The cipher key length must be the same as its block size. Security comment: The security bounds proven for KFB with a 256-bit block cipher and m = 40, in Corollary 13 of Hstad and Mats Nslund's paper, hold provided that less than 230 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 one-way function.

Block Cipher Padding CTS

Alias: "CiphertextStealing" Comments:

Padding

CTS is only defined for block ciphers in ECB and CBC modes. The "RC5-CTS" 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 zero-length. 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.
Padding

OneAndZeroes

Description: An algorithm that appends (using big-endian 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.

PKCSPadding

Padding

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

TBC

Padding

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. Comment: TBC is rarely used compared to other padding schemes.

NoPadding
Description:

Padding

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

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

AES128

Block Cipher

Description: A KeyGenerator for AES with 128-bit 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"

AES192
Description: A KeyGenerator for AES with 192-bit keys.

Block Cipher

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"

AES256
Description: A KeyGenerator for AES with 256-bit 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"

Block Cipher

DES-EDE2

Block Cipher

Description: A KeyGenerator for DESede with 2 independent single DES keys (i.e. 128 bits of key material).

DES-EDE3

Block Cipher

Description: A KeyGenerator for DESede with 3 independent single DES keys (i.e. 192 bits of key material). Alias: "OpenPGP.Cipher.2" Alleged Symmetric Ciphers

CAST, CAST3 are earlier versions of CAST-128 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. G-DES. 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):

Solitaire (a.k.a. "Pontifex" in Neal Stephenson's book Cryptonomicon) is broken. Mirdek is broken