Cryptix

Standard Cryptographic
Algorithm Naming

Version 0.9.9 - 9 August, 1999
Draft version, under construction
FRAMES | NO FRAMES

This document gives references for a collection of cryptographic algorithms of various types. Each algorithm is assigned a standard ASCII name, and zero or more aliases. The intention is that the references specify each algorithm in sufficient detail that independent implementations will be able to interoperate.

The list has been designed initially for use by the Java Cryptography Architecture, but should be useful in any situation where a convention is needed for referring to algorithms by a string name. It can also serve as a source of references for definitions and cryptanalysis of various algorithms. The Cryptix Development Team intends to develop API mappings for languages other than Java in future (possibly based on existing cryptography libraries).

The accompanying Definitions and Conventions document includes important information on the conventions used in compiling this list, which you should read before using it for the first time:

The following are very useful resources for a wide range of algorithms:

Contents

MessageDigest algorithms

GOST-Hash MessageDigest
Alias:
"GOST-R-34.11-94"
Published:
1994
References:
Digest length:
32 bytes.
Security comments:

HAVAL[(digestLength[,passes])] Message Digest
Designers:
Yuliang Zheng, Josef Pieprzyk, Jennifer Seberry
Published:
1992
Alias:
"OpenPGP.Digest.7" is an alias to "HAVAL(20,5)".
References:
Parameters:
Digest length:
As specified by the digestLength parameter (in bytes).

MD2 Message Digest
Designer:
Ron Rivest
Aliases:
"1.2.840.113549.2.2", "OpenPGP.Digest.5"
References:
Digest length:
16 bytes.
Security comment:
N. Rogier and P. Chauvaud have found a method of generating collisions for MD2's compression function. Quoting from RSA Laboratories Security Bulletin #4:
[C]aution requires that MD2 be no longer recommended for new applications where collision-resistance is required. Questions about the continuing suitability of MD2 for existing applications remain open. [... O]ur recommendation would be to upgrade applications away from MD2 whenever it is practical.

MD4 Message Digest
Designer:
Ron Rivest
Published:
1990
Alias:
"1.2.840.113549.2.4"
References:
Digest length:
16 bytes.
Security comment:
Bert den Boer, Antoon Bosselaers and Hans Dobbertin have found a method of generating collisions for the full MD4 algorithm. Quoting from RSA Laboratories Security Bulletin #4:
[I]t has been shown that collisions for MD4 can be found in about a minute on a typical PC. [...] MD4 [...] should not be used.

MD5 Message Digest
Designer:
Ron Rivest
Alias:
"1.2.840.113549.2.5", "OpenPGP.Digest.1"
References:
Digest length:
16 bytes.
Security comment:
Hans Dobbertin has found a method of generating collisions for MD5's compression function. Quoting from RSA Laboratories Security Bulletin #4:
Given the surprising speed with which techniques on MD4 were extended to MD5 we feel that it is only prudent to draw a cautious conclusion and to expect that collisions for the entire hash function might soon be found.

In addition, the 128-bit output is arguably not long enough to make generating collisions using a birthday attack infeasible.

Panama Message Digest
Designers:
Joan Daemen, Craig Clapp
Published:
1998
References:
Digest length:
32 bytes.

RIPEMD-128 Message Digest
Designers:
Hans Dobbertin, Antoon Bosselaers, Bart Preneel
Published:
April 1996
Aliases:
"RIPEMD128", "1.3.36.3.2.2"
References:
Digest length:
16 bytes.
Security comment:
The 128-bit output is arguably not long enough to make generating collisions using a birthday attack infeasible.

RIPEMD-160 Message Digest
Designers:
Hans Dobbertin, Antoon Bosselaers, Bart Preneel
Published:
April 1996
Aliases:
"RIPEMD160", "1.3.36.3.2.1", "OpenPGP.Digest.3"
References:
Digest length:
20 bytes.

SHA-0 Message Digest
Designers:
U.S. National Security Agency
Published:
January 1992
Alias:
"1.3.14.3.2.13"
References:
Digest length:
20 bytes.
Security comment:
This is the original version of the Secure Hash Algorithm, and has been superceded by SHA-1. Although the motivation for the change leading to SHA-1 was not made public by the NSA, the paper by Chabaud and Joux cited above provides evidence that this change improved security.

SHA-1 Message Digest
Designers:
U.S. National Security Agency
Published:
April 1995
Aliases:
"SHA", "SHA1", "1.3.14.3.2.26", "OpenPGP.Digest.2"
References:
Digest length:
20 bytes.

Tiger[(digestLength[,passes])] Message Digest
Designers:
Ross Anderson, Eli Biham
Published:
1996
Alias:
"OpenPGP.Digest.6" is an alias to "Tiger(24,3)".
References:
Parameters:
Digest length:
As specified by the digestLength parameter (in bytes).
Comment:
Although the "Tiger: A Fast New Hash Function" paper does not mention use of any number of passes/rounds other than 3, the reference implementation (available from the Tiger home page) supports a variable number of passes, and therefore we specify this as a parameter.

Parallel(digestNames+) Message Digest Construction
Description:
This output of this algorithm is obtained by concatenating the outputs of each of the listed algorithms. For example, "Parallel(SHA-1,RIPEMD-160)" produces a 40-byte output, the first half of which is calculated by applying SHA-1 to the input, and the second half by applying RIPEMD-160. Any non-zero number of algorithms may be listed, separated by commas.
Parameters:
Digest length:
The sum of the digest lengths of the component algorithms.
Security comments:

Mac algorithms (Message Authentication Codes)

CBC-MAC-DES-FIPS113 Mac
Description:
If EK denotes DES encryption, and the input message is split into blocks M0,... Mn-1 (using padding with zeroes for the last block), then:
References:
Key length:
64 bits as encoded; 56 bits excluding parity bits.
Truncated length:
Minimum 32, maximum 64, default 64 bits.
Comments:
Security comment:

? CBC-MAC(cipherName) Mac
Description:
If EK denotes encryption with the block cipher named cipherName, and the input message is split into blocks M0, ... Mn-1 (using PKCS #7-style padding for the last block), then:
References:
Parameters:
Key length:
As defined by the cipher.
Truncated length:
Minimum 32 bits, maximum equal to the cipher block size. The default truncated length is 64 bits, or half of the cipher block size rounded up to the next multiple of 8 bits, whichever is greater.
Missing information:
Test vectors.
Comment:
The input is padded to a multiple of the cipher's block length by using PKCS #7-style padding (as defined by the PKCSPadding algorithm for block ciphers).
Security comment:
The paper "MDx-MAC and building fast MACs from hash functions," describes an attack on CBC-MAC which requires on the order of 2k/2 known texts, where k is the cipher block size in bits. This means that the security of CBC-MAC using a 64-bit cipher (i.e. most block ciphers designed before the AES process) is very limited.

HMAC(digestName) Mac Construction
Designers:
Mihir Bellare, Ran Canetti, Hugo Krawczyk, Adi Shamir
Published:
June 1996
References:
Parameters:
Key length:
As defined by the cipher.
Truncated length:
Minimum 32 bits, maximum equal to the message digest output length. The default is half the message digest output length, rounded up to the next multiple of 8 bits.

MD5-MAC Mac
Designers:
Bart Preneel, P.C. van Oorschot
Description:
The Mac algorithm obtained by applying the MDx-MAC method to MD5 (MDx-MAC is not defined as a construction, since it involves changes to the internal structure of the message digest being used).
Published:
1995
References:
Truncated length:
Minimum 32, maximum 128, default 64 bits.
Security comment:
MD5-MAC is claimed to require approximately 264 operations to forge a message (increasing the truncated length property from the default, 8 bytes, does not necessarily improve this).

RIPEMD-128-MAC(macLength) Mac
Designers:
Bart Preneel, P.C. van Oorschot
Description:
The Mac algorithm obtained by applying the MDx-MAC method to RIPEMD-128 (MDx-MAC is not defined as a construction, since it involves changes to the internal structure of the message digest being used).
Published:
1995
References:
Truncated length:
Minimum 32, maximum 128, default 64 bits.
Security comment:
RIPEMD-128-MAC is claimed to require approximately 264 operations to forge a message (increasing the truncated length property from the default, 8 bytes, does not necessarily improve this).

RIPEMD-160-MAC(macLength) Mac
Designers:
Bart Preneel, P.C. van Oorschot
Description:
The Mac algorithm obtained by applying the MDx-MAC method to RIPEMD-160 (MDx-MAC is not defined as a construction, since it involves changes to the internal structure of the message digest being used).
Published:
1995
References:
Truncated length:
Minimum 32, maximum 160, default 80 bits.
Security comment:
RIPEMD-160-MAC is claimed to require approximately 280 operations to forge a message (increasing the truncated length property from the default, 10 bytes, does not necessarily improve this).

? SSL3-MAC(digestName) Mac Construction
Designers:
Mihir Bellare, Ran Canetti, Hugo Krawczyk
Alias:
"SSL3MAC"
References:
Parameters:
Truncated length:
Minimum 32 bits, maximum equal to the message digest output length. The default is half the message digest output length, rounded up to the next multiple of 8 bits.
Comment:
This is an early version of HMAC, which should now be used in preference (except for compatibility with SSL version 3). The difference is that in SSL3-MAC, the padding strings 'ipad' and 'opad' are appended to the key, whereas in HMAC, they are exclusive-or'd with the zero-extended key.

! XMACR(cipherName) Mac Construction
Designers:
Mihir Bellare, R. Guérin, Phillip Rogaway
Description:
...
Published:
October 1995
References:
Parameters:
Truncated length:
Minimum 32 bits, maximum equal to the message digest output length. The default is half the message digest output length, rounded up to the next multiple of 8 bits.
Missing information:

Symmetric Ciphers

 See also Conventions for symmetric ciphers.

3-Way Block Cipher
Designer:
Joan Daemen
Published:
1994
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 denoted in chapter 7 of Joan Daemen's thesis as (a0, a1, a2), are given in that order. 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 in Applied Cryptography (page 659) with the words written in the opposite order (i.e. as a2 a1 a0).

For reference, the forth 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 PRNG, or by a source of bits that are sufficiently uncorrelated (such as the output of a hash function).

! AES Block Cipher
Description:
This name is reserved for the cipher that wins the NIST AES (Advanced Encryption Standard) contest. Its original name will be retained as an alias. If there is more than one winning algorithm, each winner will retain its original name, and this entry will be removed.
Aliases:
"AES128", "AES192", "AES256", "OpenPGP.Cipher.7", "OpenPGP.Cipher.8", "OpenPGP.Cipher.9"
References:
Key length:
128, 192 or 256 bits. Other lengths may also be supported. The default key length for AES depends on the KeyGenerator name; see the section on KeyGenerators.
Block size:
16 bytes. Other sizes may also be supported.
Patent status:
The AES winner will be available on a wordwide, non-exclusive, royalty-free basis, regardless of any patents.
Missing information:
Which algorithm will win ;-)

Blowfish Block Cipher
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 S. Vaudenay's paper do not appear to be significant for full (16-round) Blowfish.
Variant:
"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).

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

CAST-256 Block Cipher
Designer:
Carlisle Adams, Howard Heys, Stafford Tavares, Michael Wiener
Published:
June 1998
References:
Key length:
Minimum 128, maximum 256, multiple of 32 bits; default 128 bits.
Block size:
16 bytes.
Patent status:
CAST-256 is patented by Entrust Technologies, Inc. (see references). [[need reference to statement that licensing will be royalty-free.]]

CRYPTON-0.5 Block Cipher
Designer:
Chae Hoon Lim
Published:
1998
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.

CRYPTON Block Cipher
Designer:
Chae Hoon Lim
Published:
December 1998
Aliases:
"CRYPTON-1.0"
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.

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

DEAL Block Cipher
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:

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

DESede Block Cipher
Designers:
Whitfield Diffie, Martin Hellman, Walt Tuchmann
Published:
1978
Aliases:
"TripleDES", "DES-EDE3", "3DES", "OpenPGP.Cipher.2"
References:
Key length:
128 or 192 bits; default 192 bits, as encoded. 112 or 168 bits excluding parity.
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).

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.

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:

DFC Block Cipher
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.
Comments:
The additional parameters described in the "DFC Update" paper (the block size m bits, number of rounds r, and adjustment to key scheduling s) may be added in future.

If so, the proposed name for the generalised version is "DFC-m[(r[,s])]" (on the basis that each value of m will normally require a different implementation, whereas changes to r and s can easily be handled by a single implementation; also note that the variable key length does not need to be expressed as a parameter). For DFC-128, r would default to 8, and s to 4.

The key schedule change suggested in "DFC Update" is not specified precisely enough to define a new algorithm name for it, yet.

Patent status:
DFC 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:

E2 Block Cipher
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 (TecApro International S.A.)
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:

? GOST Block Cipher
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(blockSize[,backup]) Block Cipher
Designer:
Rich Schroeppel
Alias:
"HastyPudding"
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 }, where junk & 0xE0 == 0. The value of the key's effectiveBitLength parameter is used to determine how many bits of the encoding are significant.
Security comments:

ICE Block Cipher
Designer:
Matthew Kwan
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.

IDEA Block Cipher
Designers:
Xuejia Lai, James Massey
Aliases:
  • "OpenPGP.Cipher.1"
  • "1.3.6.1.4.1.188.7.1.1.1" is an alias to "IDEA/ECB"
  • "1.3.6.1.4.1.188.7.1.1.2" is an alias to "IDEA/CBC"
  • "1.3.6.1.4.1.188.7.1.1.3" is an alias to "IDEA/CFB"
  • "1.3.6.1.4.1.188.7.1.1.4" is an alias to "IDEA/OFB"
    (source for OIDs)
References:
  • [Def, An] X. Lai,
    "On the design and security of block ciphers",
    ETH Series in Information Processing (J.L. Massey, ed.), Vol. 1, Hartung-Gorre Verlag, Konstanz Technische Hochschule (Zurich), 1992.
  • [Inf, An] X. Lai, J.L. Massey, S. Murphy,
    "Markov Ciphers and Differential Cryptanalysis,"
    Advances in Cryptology - EUROCRYPT '91, Volume 547 of Lecture Notes in Computer Science (D.W. Davies, ed.), pp. 17-38. Springer-Verlag, 1991.
  • [Inf] The IDEA Algorithm page,
    http://www.ascom.ch/infosec/idea.html.
  • [Inf] Bruce Schneier,
    "Section 13.9 IDEA,"
    Applied Cryptography, Second Edition, John Wiley & Sons, 1996.
    [[note: there is an error in the description; diagram is correct.]]
  • [Inf] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
    "Section 7.6 IDEA,"
    Handbook of Applied Cryptography, CRC Press, 1997.
  • [An] Joan Daemen, René Govaerts, Joos Vandewalle,
    "Weak Keys of IDEA,"
    Advances in Cryptology - CRYPTO '93 Proceedings, Volume 773 of Lecture Notes in Computer Science (D. Stinson, ed.), pp. 224-231. Springer-Verlag, 1994.
    http://www.esat.kuleuven.ac.be/~rijmen/downloadable/daemen/ideaw.ps.gz (or here)
  • [An] Joan Daemen, René Govaerts, Joos Vandewalle,
    "Cryptanalysis of 2.5 Rounds of IDEA,"
    ESAT-COSIC Technical Report 93/1, 1993.
    http://www.esat.kuleuven.ac.be/~cosicart/ps/JD-9306.ps.gz
  • [An] J. Borst, L. Knudsen, V. Rijmen,
    "Two attacks on reduced IDEA," Advances in Cryptology - EUROCRYPT '97 Proceedings, Volume 1233 of Lecture Notes in Computer Science (W. Fumy, ed.), pp. 1-13. Springer-Verlag, 1997.
    ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/rijmen/idea.ps.gz
  • [An] L. Knudsen, V. Rijmen,
    "Truncated Differentials of IDEA,"
    ESAT-COSIC Technical Report 97-1.
    ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/idea_trunc.ps.Z
  • [An] J. Kelsey, B. Schneier, D. Wagner,
    "Key-Schedule Cryptanalysis of 3-WAY, IDEA, G-DES, RC4, SAFER, and Triple-DES",
    Advances in Cryptology - Crypto '96 Proceedings, pp. 237-251. Springer-Verlag, August 1996.
    http://www.counterpane.com/key_schedule.html
  • [An] J. Kelsey, B. Schneier, D. Wagner, C. Hall,
    "Side Channel Cryptanalysis of Product Ciphers",
    ESORICS '98 Proceedings pp. 97-110, Springer-Verlag, September 1998.
    http://www.counterpane.com/side_channel.html
  • [An] E.G. Giessmann, G. Lassmann,
    "A Side Channel Cryptanalysis of the IDEA Cipher",
    Submitted to CRYPTO '99.
  • [Inf, An] Ascom Systec, Ltd.
    "Side Channel Attack Hardening of the IDEATM Cipher,"
    Ascom Systec White Paper (corrected version, May 1999).
    http://www.ascom.ch/infosec/downloads/sidechannel.pdf
  • [Impl, Test] Ascom Systec, Ltd.
    IDEA C Source Code and Test Data (corrected version, May 1999).
    http://www.ascom.ch/infosec/downloads.html
Key length:
128 bits.
Block size:
8 bytes.
Comment:
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>
Security comment:
IDEA is vulnerable to key schedule attacks, and therefore it should only be used with keys that are generated by a strong PRNG, 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. The licensing policy is described here.

! ISAAC Stream Cipher
Designer:
Robert J. Jenkins Jr.
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.

! ISAAC-64 Stream Cipher
Designer:
Robert J. Jenkins Jr.
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.

? JEROBOAM Stream Cipher
Designer:
Hervé Chabanne, Emmanuel Michon
Published:
1998
Description:
This algorithm refers to JEROBOAM version 2.0.
Alias:
"JEROBOAM-2.0"
References:
  • [Def, An] Hervé Chabanne, Emmanuel Michon,
    "JEROBOAM",
    Fast Software Encryption '98, Volume 1372 of Lecture Notes in Computer Science (S. Vaudenay, ed.), pp. 49-59. Springer-Verlag, 1998.
  • [Def, An] Emmanuel Michon,
    Rapport de stage d'option scientifique: étude cryptologique du chiffreur JEROBOAM,
    LATEX Document 2ε, 74 ko, Ecole Polytechnique, June 1997.
Key length:
128 or 248 bits

LOKI91 Block Cipher
Designers:
Laurence Brown, Matthew Kwan, Josef Pieprzyk, Jennifer Seberry
Published:
1991-92
References:
  • [Def, An] Laurence Brown, Matthew Kwan, Josef Pieprzyk, Jennifer Seberry,
    "Improving Resistance to Differential Cryptanalysis and the Redesign of LOKI,"
    Advances in Cryptology - ASIACRYPT '91 Proceedings, Springer-Verlag, 1993, pp. 36-50.
  • [Inf] Bruce Schneier,
    "Section 13.6 LOKI,"
    Applied Cryptography, Second Edition, John Wiley & Sons, 1996.
  • [An] Eli Biham,
    "New Types of Cryptanalytic Attacks Using Related Keys,"
    CS 753, Computer Science Department, Technion -- Israel Institute of Technology, September 1992.
    http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/1992/CS/CS0753.ps
  • [An] Lars Knudsen,
    "Cryptanalysis of LOKI91,"
    Volume 718 of Lecture Notes in Computer Science, pp. 196-208. Springer-Verlag, 1992.
    ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/loki91.ps.Z
  • [An] Lars Knudsen,
    "Block ciphers - analysis, design and applications,"
    PhD. Thesis, DAIMI PB 485, Aarhus University, 1994.
  • [An] Toshio Tokita, Tohru Sorimachi, Mitsuru Matsui,
    "Linear cryptanalysis of LOKI and S2DES,"
    Volume 917 of Lecture Notes in Computer Science, pp. 293-306. Springer-Verlag, 1994.
  • [An] Lars Knudsen, M.J.B. Robshaw,
    "Non-linear Approximations in Linear Cryptanalysis,"
    Volume 1070 of Lecture Notes in Computer Science, pp. 224-236. Springer-Verlag, 1996.
    ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/nonlinear.ps.Z
  • [An] Kouichi Sakurai, Souichi Furuya,
    "Improving Linear Cryptanalysis of LOKI91 by Probabalistic Counting Method,"
    Volume ??? of Lecture Notes in Computer Science. Springer-Verlag, 1997.
  • [An] Lars Knudsen,
    "New potentially weak keys for DES and LOKI,"
    Advances in Cryptology - EUROCRYPT '94 Proceedings, Volume 950 of Lecture Notes in Computer Science (A. De Santis, ed.), pp. 419-424. Springer Verlag, 1995.
    ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/knudsen/potential.ps.Z
Key length:
64 bits.
Block size:
8 bytes.
Security comments:
  • LOKI91 is vulnerable to 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 PRNG, 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.

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

MARK-4 Stream Cipher
Description:
"Modified alleged RC4". This uses the same algorithm as RC4, but with the first 256 bytes of keystream discarded after key scheduling.
References:
  • [Def] Bruce Schneier,
    "Section 17.1 RC4,"
    Applied Cryptography, Second Edition, John Wiley & Sons, 1996.
  • [Def] Anonymous,
    Subject: RC4 Algorithm revealed,
    Posting to Usenet newsgroups sci.crypt, alt.security, comp.security.misc, and alt.privacy, September 14 1994.
    (Message-ID: <sternCvKL4B.Hyy@netcom.com>)
    Archived at ftp://idea.sec.dsi.unimi.it/pub/security/crypt/code/rc4.revealed.gz
  • [An] J. Kelsey, B. Schneier, D. Wagner,
    "Key-Schedule Cryptanalysis of 3-WAY, IDEA, G-DES, RC4, SAFER, and Triple-DES",
    Advances in Cryptology - Crypto '96 Proceedings, pp. 237-251. Springer-Verlag, August 1996.
    http://www.counterpane.com/key_schedule.html
Key length:
Minimum 8, maximum 2048, multiple of 8 bits; default 128 bits.
Comment:
For the purposes of SCAN, "MARK-4" 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 Data Security, Inc.'s proprietary cipher of the same name.

The name "MARK-4" was apparently suggested by Brian Olson, in a posting to sci.crypt.

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
References:
  • [Def, An] Carolynn Burwick, Don Coppersmith, Edward D'Avignon, Rosario Gennaro, Shai Halevi, Charanjit Jutla, Stephen M. Matyas Jr., Luke O'Connor, Mohammad Peyravian, David Safford, Nevenko Zunicof,