Standard Cryptographic Algorithm Naming (original) (raw)

Symmetric Ciphers

Also see the notes for block cipher modes andKeyGenerators.

Key scheduling

Ciphers that have different key schedules, but are otherwise identical are given different names (for example,SAFER-K andSAFER-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.

Designer:

Joan Daemen

Published:

1994

Alias:

"ThreeWay" (use for identifiers)

References:

Key length:

96 bits.

Block size:

12 bytes.

Comment:

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 big-endian order. This is consistent with the four test vectors in Crypto++ (note that the same four test vectors are included on page 659 ofApplied Cryptography, 2nd edition, with the words written in the opposite order).

For reference, the fourth test vector in this set is:

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

Designers:

Joan Daemen,Vincent Rijmen

Alias:

"OpenPGP.Cipher.7"

Object Identifiers:

Description:

AES128 is defined as Rijndael with a 128-bit block size and 10 rounds.

References:

Key length:

128 bits.

Block size:

16 bytes.

Designers:

Joan Daemen,Vincent Rijmen

Alias:

"OpenPGP.Cipher.8"

Object Identifiers:

Description:

AES192 is defined as Rijndael with a 128-bit block size and 12 rounds.

References:

[see references for AES128 andRijndael]

Key length:

192 bits.

Block size:

16 bytes.

Designers:

Joan Daemen,Vincent Rijmen

Alias:

"OpenPGP.Cipher.9"

Object Identifiers:

Description:

AES256 is defined as Rijndael with a 128-bit block size and 14 rounds.

References:

[see references for AES128 andRijndael]

Key length:

256 bits.

Block size:

16 bytes.

Designers:

Paulo Barreto,Vincent Rijmen

Published:

November 2000

References:

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:

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

Designers:

Johan Håstad, Mats Näslund

Published:

October 2000

Description:

BMGL is an alias for "Rijndael-256/KFB(40)"; that is, Rijndael with a 256-bit 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 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.

Designers:

Carlisle Adams,Stafford Tavares

Published:

1997

Aliases:

"CAST5", "OpenPGP.Cipher.3"

References:

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.

Designer:

Carlisle Adams, Howard Heys,Stafford Tavares, Michael Wiener

Published:

June 1998

Alias:

"CAST6"

References:

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.

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:

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:

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

Block size:

16 bytes.

Designers:

Jacques Stern,Serge Vaudenay

Published:

1998

References:

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.

Designer:

Lars Knudsen

Published:

May 1998

References:

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:

Designers:

Don Coppersmith, Horst Feistel, Walt Tuchmann,U.S. National Security Agency

Published:

1976

References:

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.

Designers:

Whitfield Diffie, Martin Hellman, Walt Tuchmann

Published:

1978-79

Aliases:

References:

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 DES-EDE2, 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:

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

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.

References:

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:

Designers:

Henri Gilbert, Marc Girault, Philippe Hoogvorst,Fabrice Noilhan,Thomas Pornin,Guillaume Poupard,Jacques Stern,Serge Vaudenay

Published:

May 1998

References:

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

References:

Parameters:

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

Designer:

Michael Paul Johnson

Published:

1995

References:

Parameters:

Key length:

Minimum 8, maximum 65536, multiple of 8 bits; default 128 bits.

Block size:

16 bytes.

Comments:

Designers:

Kazumaro Aoki, Masayuki Kanda, Tsutomu Matsumoto, Shiho Moriai, Kazuo Ohta, Miyako Ookubo, Youichi Takashima, Hiroki Ueda

Published:

June 1998

References:

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:

Parameters:

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:

Alias:

"GOST-28147-89"

Published:

1989

References:

Parameters:

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.

References:

Parameters:

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:

? HPC-2(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:

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:

Designer:

Matthew Kwan

Published:

1997

References:

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.

Designers:

Xuejia Lai, James Massey

Published:

1992

Alias:

"OpenPGP.Cipher.1"

Object Identifiers:

References:

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:

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 ]

Key length:

?

Missing information:

[see ]

× ISAAC-64-BE Stream Cipher

Designer:

Robert J. Jenkins Jr.

Published:

1996

References:

Key length:

?

Missing information:

ISAAC-64 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.

× ISAAC-64-LE Stream Cipher

Designer:

Robert J. Jenkins Jr.

Published:

1996

References:

[see references for ]

Key length:

?

Missing information:

[see ]

Designers:

Hervé Chabanne, Emmanuel Michon

Published:

1998

Description:

This algorithm refers to JEROBOAM version 2.0.

Alias:

"JEROBOAM-2.0"

References:

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

Designers:

David McGrew, Scott Fluhrer

Published:

October 2000

Description:

This is LEVIATHAN using big-endian 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.

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

References:

[see references for LEVIATHAN-BE]

Key length:

128 or 256 bits

Security comment:

[see Security comment for LEVIATHAN-BE]

Designers:

Laurence Brown,Matthew Kwan, Josef Pieprzyk,Jennifer Seberry

Published:

1991-92

References:

Key length:

64 bits.

Block size:

8 bytes.

Security comments:

Designers:

Laurence Brown, Josef Pieprzyk,Jennifer Seberry

Published:

1997

References:

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.

Designers:

Michael Jacobson Jr., Klaus Huber

Published:

August 1998

References:

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

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"

References:

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 "royalty-free" excludes the possibility of up-front 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:

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:

Parameters:

Key length:

128 bits.

Block size:

8 bytes.

? MISTY2[(rounds)] Block Cipher

Designer:

M. Matsui

Published:

January 1997

References:

Parameters:

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:

Parameters:

Key length:

128 bits.

Block size:

16 bytes.

Noekeon-Direct[(rounds)] Block Cipher

Designers:

Joan Daemen, Michaël 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.

References:

Parameters:

Key length:

128 bits.

Block size:

16 bytes.

Designers:

Joan Daemen,Craig Clapp

Published:

1998

References:

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:

Chang-Hyi Lee, Jeong-Soo 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 128-bit block version is defined as a SCAN algorithm.

Designer:

Ron Rivest

Published:

1998

References:

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

Designer:

Ron Rivest

Published:

September 1994 (see Comment section below)

Alias:

"ARCFOUR"

References:

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

RC4-drop[(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:

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

References:

Parameters:

Key length:

Minimum 8, maximum 2048, multiple of 8 bits; default 128 bits.

Comments:

Security comments:

RC5[(rounds)] Block Cipher

Designer:

Ron Rivest

Published:

January 1995

Alias:

"RC5-32"

References:

Parameters:

Key length:

Minimum 0; maximum 2040, multiple of 8 bits; default 128 bits.

Block size:

8 bytes.

Comments:

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)] Block Cipher

Designer:

Ron Rivest

Published:

January 1995

References:

[see references for RC5]

Parameters:

Key length:

Minimum 0; maximum 2040, multiple of 8 bits; default 128 bits.

Block size:

16 bytes.

Missing information:

Test vectors.

Comments:

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"

References:

Parameters:

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?

References:

[see references for RC6]

Parameters:

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

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.

References:

Key length:

Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.

Block size:

16 bytes.

Comments:

Rijndael-160 Block Cipher

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.

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]

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.

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]

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.

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]

Rijndael-256 Block Cipher

Designers:

Joan Daemen,Vincent Rijmen

Published:

November 1998

Description:

This is Rijndael with a 256-bit 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]

SAFER-K[(rounds)] Block Cipher

Designer:

James Massey

Published:

December 1993.

Description:

This algorithm refers to the original version of SAFER, designed in 1993.

References:

Parameters:

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

References:

Parameters:

Key length:

64 or 128 bits; default 128 bits.

Block size:

8 bytes.

Comments:

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:

References:

Key length:

128, 192 or 256 bits; default 128 bits.

Block size:

16 bytes.

Comments:

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

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.

References:

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 64-bit block size and 128-bit key.

References:

[see references for SAFER++]

Key length:

128 bits.

Block size:

8 bytes.

Sapphire-II 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 Howgrave-Graham, 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 Howgrave-Graham, Charanjit Jutla, Tal Rabin, J. R. Rao

Published:

February 2002

References:

[see references for Scream]

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.

References:

Parameters:

Key length:

160 bits.

Comments:

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

References:

[see references for SEAL-3.0-BE]

Parameters:

Key length:

160 bits.

Comment:

[see comment for SEAL-3.0-BE]

Patent status:

[see patent status for SEAL-3.0-BE]

Designers:

Ross Anderson,Eli Biham,Lars Knudsen

Published:

1998?

References:

Key length:

Minimum 0, maximum 256, multiple of 8 bits; default 128 bits.

Block size:

16 bytes.

Comments:

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:

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:

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:

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.

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 SOBER-t16]

Key length:

Minimum ?, maximum ?, multiple of ? bits; default 128 bits.

SPEED-64[(rounds)] Block Cipher

Designer:

Yuliang Zheng

Published:

February 1997

References:

Parameters:

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)] Block Cipher

Designer:

Yuliang Zheng

Published:

February 1997

References:

[see references for SPEED-64]

Parameters:

Key length:

Minimum 48, maximum 256, multiple of 16 bits; default 128 bits.

Block size:

16 bytes.

Security comment:

[see security comment for SPEED-64]

SPEED-256[(rounds)] Block Cipher

Designer:

Yuliang Zheng

Published:

February 1997

References:

[see references for SPEED-64]

Parameters:

Key length:

Minimum 48, maximum 256, multiple of 16 bits; default 128 bits.

Block size:

32 bytes.

Security comment:

[see security comment for SPEED-64]

Square[(rounds)] Block Cipher

Designers:

Joan Daemen,Vincent Rijmen

Published:

1997

References:

Parameters:

Key length:

128 bits.

Block size:

16 bytes.

Designers:

David Wheeler,Roger Needham

Published:

1994

References:

Key length:

128 bits.

Block size:

8 bytes.

Missing information:

Test vectors.

Comment:

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

Designers:

Bruce Schneier, John Kelsey, Doug Whiting,David Wagner, Chris Hall, Niels Ferguson

Published:

1998

Alias:

"OpenPGP.Cipher.10" [[implies 256-bit key]]

References:

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

Designer:

David Wheeler

Published:

1993

Description:

This is WAKE in CFB mode, using big-endian byte order. See the Comments section below.

References:

Key length:

128 bits.

Missing information:

Test vectors.

Comments:

Security comments:

? WAKE-CFB-LE Stream Cipher

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.

References:

[see the references for WAKE-CFB-BE]

Key length:

128 bits.

Missing information:

Test vectors.

Comments:

Security comments:

[see security comments for ]

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.

References:

Key length:

128 bits.

Comments:

WiderWake4+1-LE 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 little-endian byte order. See the Comments section for WiderWake4+1-BE.

References:

[see references for WiderWake4+1-BE]

Key length:

128 bits.

Comments:

[see comments for WiderWake4+1-BE]

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

References:

[see references for WiderWake4+1-BE]

Key length:

128 bits.

Missing information:

Test vectors.

Comments:

[see comments for WiderWake4+1-BE]

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

References:

[see references for WiderWake4+1-BE]

Key length:

128 bits.

Missing information:

Test vectors.

Comments:

[see comments for WiderWake4+1-BE]

× PBE-PKCS5(digestName,DES/CBC) Block Cipher Construction

Designers:

RSA Security, Inc.

Aliases:

Object Identifiers:

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 for PassphraseHash.

References:

Parameters:

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_]) Cipher Construction

Designers:

RSA Security, Inc.

Aliases:

Object Identifiers:

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 for PassphraseHash.

References:

Parameters:

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.

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 byte-oriented. 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.

Description:

Electronic Codebook Mode, as defined in NBS FIPS PUB 81.

References:

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:

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)] Byte-oriented Mode

Description:

Cipher Feedback Mode, as defined in NBS FIPS PUB 81, with a feedback vector of length feedbackBits bits.

Aliases:

"CFB_n_", 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:

Parameters:

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:

Comments:

InterleavedCBC(nStreams) Block-oriented 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:

Parameters:

If a padding scheme is not specified (i.e. the algorithm name is given in the form "cipherName/InterleavedCBC(nStreams)"), thenPKCSPadding 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.

References:

Parameters:

Comment:

If a padding scheme is not specified (i.e. the algorithm name is given in the form "cipherName/InterleavedPCBC(nStreams)"), thenPKCSPadding MUST be assumed. The standard name always specifies which padding method is used, i.e. it always has three components.

InterleavedCFB(nStreams) Byte-oriented 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:

Parameters:

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"

References:

Comments:

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"

References:

[see references for Counter-BE]

Comments:

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

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 Håstad and Mats Näslund'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

Alias:

"CiphertextStealing"

References:

Comments:

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.

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

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.

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"

References:

[see references for AES]

Description:

A KeyGenerator for AES with 192-bit 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 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"

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