On cryptosystems untrustworthiness

Abstract

The reasons of cryptosystems untrustworthiness can be divided into 4 main groups: application of weak algorithms, cryptalgorithms wrong implementation or application and human factor. There is clear parallel between these reasons and computer system security violation ones.

Because of pointed reasons there were and still there are security problems in all kinds of software, where cryptalgorithms are used, be it operating systems; cryptographic protocols; clients and servers supporting them; office programs; user encryption utilities or popular archivers.

To proper implement your own cryptosystem you should not only learn somebody's mistakes and understand the reasons of their occurrence, but perhaps use sophisticated protection programming approaches and special design tools.

Cryptalgorithms are widely used in modern software not only for data encryption but also for authentication and integrity. To date there exist well-known and approved cryptalgorithms (both symmetric and asymmetric), whose strength is either mathematically proved or based on mathematically hard computational problem (factorization, discrete logarithm, etc.). The most famous ones are DES, GOST, RSA. These algorithms can be breaked only by solving this problem or by brute force.

On the other hand, information on errors and flaws in one or other program or on cracking some programs (including those using cryptalgorithms) appears in computer world and about all the time. It causes distrust to both specific programs and ability to protect anything with cryptography in general, not only against secret services, but also against hackers.

Thus, when designing secure systems it is necessary to learn history of attacks and flaws in cryptosystems and to understand the reasons of their occurrence. The promising research branch in this field is the analysis of successful attacks or detected cryptosystem vulnerabilities in order to generalize, classify and detect the reasons and regularity of their appearance and existence. This is the item of this paper.

By analogy with computer systems security violation reasons taxonomy [1], let us pick out the reasons for which cryptographic programs cannot be considered secure (see figure 1.):

1. Impossibility of strong cryptalgorithms use;
2. Cryptalgorithm implementation errors;
3. Cryptalgorithm wrong application;
4. Human factor.

Note that reasons in concern cover only two potential threats, namely confidentiality and integrity ones, leaving aside denial of service, which becomes more and more significant with the development of distributed cryptosystems.

1. Impossibility of applying strong cryptalgorithms

This kind of reasons is the most prevalent because of following factors.

Low rate of strong cryptalgorithms

It is one of the main factors hampering good algorithms usage in total ciphering or "on-the-fly" ciphering systems. In particular, while Norton DiskReet program is DES-implemented, it may not encrypt all the disk when the user changes his key, as it will take too much time. Just so, there is the option of compressed data password protection in Stac Electronics' Stacker on fly compression program. But it is physically unable to encipher its own file (usually of hundreds megabytes) with this password, that's why it contents with very weak algorithm and keeps hash-function of password along with data being protected. Cryptographic strength¹ of this function was examined and appeared to be 2⁸, i.e. a password can be breaked trivially.

Export restrictions

This reason is connected with cryptalgorithm export or with necessity of getting patent or rights. In particular, U.S. cryptalgorithms export is limited to 40-bit key length². Such strength evidently cannot be secure because of modern computer power. Even for personal computer, setting exhaustive search rate to 50000 passwords per second, we get exhaustive search time of about 4 months at average.

Among known export restricted software last versions of Internet browsers, Netscape Communications' Netscape Navigator and Microsoft's Internet Explorer, can be mentioned. They represent encryption with 128-bit key for U.S. users and with 40-bit key for the rest. The last version of ARJ 2.60 archiver, known for its weak archive enciphering algorithm, also can be referred to this group. Today U.S. users can use cryptographically strong GOST. The funny side of situation is that while algorithm is Russian, due to U.S. law even Russians still cannot use it in ARJ program.

Own cryptalgorithms usage

Paradoxical situation, when developers ignore known algorithms, often occurs, especially with freeware and shareware, in archivers or file encryption tools, for instance.

As we have already mentioned, ARJ archiver (up to version 2.60 inclusive) uses very weak encryption algorithm, simple XOR with password. It may seem that it could be used, because archived text must not absolutely be redundant and statistical cryptanalysis methods would not do here. But after detailed consideration it appeared that archived text possesses some nonrandom information (and it holds for any archiver), for example, Huffman table and other housekeeping information. That's why, if one knows exactly or can predict with certain probability the values of these housekeeping variables, he can also determine corresponding password characters with the same probability.

Further usage of such a weak algorithm leads to successful plaintext attack: if an adversary knows at least one file from encrypted archive he could easily determine archive password and extract all the rest files (for given plaintext, ARJ strength is 2⁰ !). Even if all the files are encrypted, simple XOR allows to get exhaustive search rate of 350000 password per second on Pentium.

The same we have in the case of popular programs from Microsoft Office 95, where to determine a password one must know only 16 plain bytes of .doc or .xls file which are to be present there, whereupon it is sufficient to look through only 2⁴ variants. Microsoft Office 97 contains improved encryption algorithms, allowing exhaustive search only, but... not everywhere! MS Access 97 uses absolutely primitive algorithm, while XOR-encrypting with fixed constant not data but password!

Novell Netware network operating system (3.x and 4.x versions) also uses its own hash algorithm. Hash-function has 32-byte value, derived from user original password by truncation a password with the length of more than 32 characters with XOR operation or by replication a password with the length of less than 32 characters, in the input and 16-byte hash-value (Hash16) in the output. It is this value (for Novell Netware 3.x) to be stored in bindery data base as "PASSWORD" property.

One of the main features of cryptographically strong hash-function is that it should not allow easy collisions (such as crypt() function, used in UNIX and based on mathematically strong cryptalgorithm DES). It is this feature that is violated in Novell Netware's hash function.

The procedure was built, which for given hash-value after some search (about few seconds on 80386+ computer) generates 32-byte sequence, which is not, of course, a true password, but is perceived by Novell Netware as such, since being processed by hash algorithm it has exactly available hash value in the output.

The same hash algorithm remained also in Novell Netware 4 version.

Microsoft, in turn, also has significant shortcomings in its main hash algorithm, applied for local (NetBIOS protocol) and global (CIFS and http protocols) networks authentication in all of its operating systems since Windows 3.11, so called LM-hash (Lan Manager-hash) [4]. (However, Microsoft pleads that it remained since OS/2 and was designed by IBM).

It runs as follows:

1. Password is converted into 14-character string by truncating longer passwords or by complementing shorter passwords with zeros.
2. All the lowercase characters are changed into uppercase ones. Numeric and special characters are stayed unchanged.
3. 14-byte string is divided into two 7-byte halves.
4. Fixed constant is encrypted on each of these halves as on DES-key, resulting in two 8-byte strings.
5. These strings are merged to form 16-bit hash-value.

It is obvious that attacks against LM-hash are easily crowned with success due to the following:

• Converting all the characters into the uppercase further restricts a few number of possible combinations (26+10+32=68) for each one.
• Two 7-byte "halves" are encrypted independently, i.e. two "halves" may be chosen by exhaustive search independently; and passwords of length more than 7 characters are not stronger than 7-character length passwords. Thus, to guarantee password disclosure we must look through only (68⁰+68¹+...+68⁷) > 7× 10¹² instead of 94⁰+94¹+... 94¹⁴ > 4× 10²⁷ (i.e. nearly 10¹⁵ times less) combinations. Moreover, passwords with the length of less than or equal 7 characters are easy to recognize, because the second half of hash is the same value AAD3B435B51404EE, resulting from fixed constant encryption on the seven-zero key.
• There is no salt, as in crypt(), so two users with the same password will always get the same hash-value. So we may compile a dictionary of hashed passwords beforehand and search the unknown password in it.

2. Cryptalgorithm implementation errors

Although cryptographically strong or certified algorithms are used in this case, this group of reasons leads to cryptosystem security violation because of algorithms wrong implementation.

Decrease of cryptographic strength while key generation

This reason has various examples, when cryptosystem truncates user password or generates data from it of the bit length less than a password one is. For example:

1. A lot of (old) UNIX versions truncate user password up to 8 byte before hashing. It's interesting, that Linux 2.0, for example, while keeping users to enter alphanumerical passwords, does not test if 8-character password beginning is also alphanumerical. That is why the user, having set the highly safe passwordIsgood19 password, will be surprised at hacker logging in on his behalf with a trivial password password.
2. Novell Netware allows user passwords up to 128 byte, i.e. 68¹²⁸ > 2⁷⁷⁹ combinations (including case-insensitive Latin alphabetic, numeric and special characters). But here hash-function (vide supra) has only 32-byte value in the input, limiting effective password length to the same value. Moreover, hash output has only 128 bit length, i.e. 2¹²⁸ combinations. It causes further decrease of effective length to =21 characters³, i.e. 6 times as against original.
3. Entirely the same situation is with RAR-archiver of 1.5x version, where password of 10 characters length does not increase time for its disclosure.

While the upper bound of password length is formed by cryptalgorithms use, the lower limitation is connected with bit or entropy notation. In case with Novell Netware to get hash-value with 128-bit entropy one must use a password of at least =69 bit⁴ length or at least 22 characters⁵. Unlimiting minimal password length in a lot of cryptosystems results in successful exhaustive search when searching not for keys but for passwords.

Lack of weak key testing

Some cryptalgorithms (in particular, DES, IDEA), when ciphering on specific keys, cannot guarantee proper cryptographic strength level. Such keys are called weak. It is known 4 weak and 12 semi-weak keys for DES. And while the probability of meeting them is > 2× 10^-16, we should not neglect it in serious cryptographic systems.

The cardinality of weak keys set for IDEA is neither more nor less than 2⁵¹ (however, since there are 2¹²⁸ keys on the whole, the probability of meeting them is 3× 10⁷ less than in DES).

Insufficient protection against malicious software

Malicious software includes computer viruses, Trojan horses and other software, able to eavesdrop secret key or plaintext and to substitute strong algorithm for weak one. If the programmer does not provide for sufficient protection against malicious software, it can violate cryptosystem security. It is mostly topical for operating systems without built-in security or access control services, such as MS DOS or Windows 95:

1. Password eavesdropping. Let us recall the oldest way of password eavesdropping, known since mainframe, when the "phantom" program emulates operating system prompt, suggesting a user to enter his name and password, stores it in certain file and terminates with the message "Invalid password". In MS DOS and Windows there exists a lot of logic bombs for reading and storing keyed-in passwords (by eavesdropping suitable interrupt), for example, when DiskReet v. 6.0 utility is running.
2. Cryptalgorithm substitution. As an example we may consider a logic bomb, posed as accelerator application, Turbo Krypton, for instance. This logic bomb substitutes GOST 28147-89 encryption algorithm, implemented by "Krypton-3" board (demo version), for another simple and easy decryptable algorithm [1].
3. E-mail Trojan horse. The last example is the attempt of "Trojan horse" to percolate through electronic mail, occurred in June 1998. The letter contained a pornographic picture and FREECD.EXE file, which decrypted provider connection passwords (Dial-Up) and sent them to ispp@usa.net, while user was amusing himself by the letter.

Dependence on time of key processing

This is relatively new aspect of cryptalgorithms incorrect implementation, called "Timing attacks" and discussed in [2], where it is shown that a lot of cryptosystems process different inputs for different time interval. The reasons for this are both hardware (different number of cycles per operation, hitting into processor cash, etc.) and software (especially while time optimization of the program). Time interval may depend on both encryption key and encrypted data.

Hence, an adversary, possessing detailed information on cryptalgorithm implementation or encrypted data and being able to measure the time of data processing somehow (for example, by analysis of data packet sending time), can try to fit a secret key. This paper [2] describes in detail attacks against RSA, Diffie-Hellman and DSS implementing systems, while the key can be obtained by elaboration bit by bit, a number of necessary time measuring is proportionate to key length.

While these research has not been brought to specific result (to compute a secret key), considered example demonstrates that crucial systems (including cryptosystems) programming is to be extremely careful and perhaps require special secure programming approaches and special design tools (especially compilers).

Software implementation errors

It is clear that this factor will always be present until programs are written by human beings. Novell Netware 3.12 operating system can serve a good example, where in spite of highly considered authentication system, in which, as Novell says, "unencrypted password is never transmitted", a bug in SYSCON program v. 3.76 was detected, due to which just plain password finds itself in one of network packets. This is not the case in neither earlier nor later versions of this program, so we may call it pure programmer's error. This error can be revealed only if supervisor changes one's password (including himself). Apparently, keyboard buffer gets somehow into network packet.

Trapdoors

Trapdoors occur in cryptosystems for obvious reasons: the designer wishes to control information, being processed in his system, and reserves the right to decrypt it without user key. Perhaps, they are used for debugging too and are left in finished products for certain reasons. Naturally it becomes known to sufficiently wide circle of persons sooner or later and the value of such cryptosystem becomes next to nothing. The most wide-known ones are AWARD BIOS (up to 4.51PG version) with its universal "AWARD_SW" password and Paradox database management system from Borland International, also including "superpasswords" "jIGGAe" and "nx66ppx".

In real earnest of implementation trapdoors (in this case they evidently use explicitly weak algorithms or store a key along with data) are those algorithms, which allow a third party to read encrypted message, as in caused a sensation CLIPPER project, where the state, known for snooping its citizens' secrets, had played a role of a third party.

Random number generator (RNG) shortcomings

Strong, mathematically tested and correctly implemented RNG is of great importance for cryptosystem as well as mathematically strong and correct cryptalgorithm, otherwise its shortcomings may influence overall cryptographic strength of the system. Moreover, pseudorandom number generator (PRNG) is generally used for RNG computer modeling, characterized by period, dispersion and seed. PRNG application can be scarcely called a happy choice for cryptosystems, so strong cryptosystems use physical RNG (special board) for these purposes, or at least generate a number for PRNG initialization, with the use of physical values (time of user's keystroke, for instance).

Short period and bad dispersion are among mathematical shortcomings of RNG and appear when you take your own RNG for some reasons. In other words, it is dangerous to use your own RNG, as well as your own cryptalgorithm.

In a case of short period (when a number of pseudorandom values, produced by generator, is less than a number of possible key values) an adversary can cut down time overhead for key searching, by looking through not keys, but pseudorandom values and generating keys from these values.

Given generator with a bad dispersion, an adversary can also cut down average search overhead, if he looks through the most likely pseudorandom numbers.

The most common error, even for tested PRNG, is its wrong initialization. Here initialization number either has less information bits than generator itself or is being chosen from nonrandom numbers and can be predicted with one or other probability.

Such situation occurred with Netscape Navigator of version 1.1. It initiated PRNG with current time in seconds (sec) and microseconds (usec) and process identificators (pid and ppid). The researches have cleared up that such scenario gives 47 significant bits of information at most (note, that this generator was used for getting 40- or 128(!)-bit keys). But when adversary

1. was able to intercept network transferred packets, and
2. had an account at the computer with running program,

he could easily learn sec, pid and ppid with high probability. When the second condition was not met, an adversary could try to set time with network demon time; pid could be obtained through SMTP demon (generally it was located in Message-ID field). Furthermore, ppid was either a few different from pid, or just equal to 1.

The unssl program was written, which found 40-bit secret key in a minute at average, searching for microseconds.

3. Cryptalgorithms wrong application

Because of this group of reasons cryptographically strong and correctly implemented algorithms appear to be untrustworthy.

Short key

This is the most obvious reason. The question arises: why strong cryptalgorithms may use short keys? Perhaps, because of following:

1. some algorithms can work with variable-length key, providing different cryptographic strength; it is the designer to choose necessary length for desirable strength and efficiency. Sometimes this desire is limited by other circumstances, such as export restrictions. (An example here is Norton Secret Stuff program that can be breaked in a few days because of 32-bit Blowfish key use).
2. some algorithms were developed long ago, when their key length was thought more than sufficient for required security level.

RSA algorithm, breaking of which is equivalent to factorization problem solving, was the first to meet with a great advance of computer power. In March 1994 8-months factoring of a 129-digit (428-bit⁶) number was completed. 600 volunteers and 1600 machines, communicated via electronic mail, carried out the computation. The calculation was the equivalent of 5000 MIPS-years⁷.

The progress in factorization problem solving is conditioned greatly not only by computer power growth but also by recent new efficient algorithms. (Factoring the next 130-digit number took only 500 MIPS-years). Today 512-bit numbers factorization is realistic. Since numbers of such a kind have been used in PGP just not long ago, we may assert that it is the most highly developed branch of cryptography and number theory.

On January 29, 1997, RSA Labs announced a competition for breaking RC5 symmetric algorithm. 40-bit key was cracked 3.5 hours later! (It didn't even need to computers Internet communication; Berkley University local network of 250 machines was sufficient). 48-bit key was cracked in 313 hours. Thus, it became obvious that the key length, which meets export restrictions, cannot provide even minimum safety.

Simultaneously with RC5 breaking, 56-bit key DES, a pillar of American cryptography, was challenged. It capitulated on July 17, 1997, in 140 days after competition had begun (it took about 450 MIPS-years to test about 25% of possible keys). Without no doubt, it was outstanding achievement, meant that DES' days as encryption standard were numbered. Indeed, when in the beginning of 1998 the next competition for DES key determination was crowned with success in 39 days only, U.S. National Institute of Standards and Technology (NIST) announced a competition for AES (Advanced Encryption Standard) confirmation. AES is to be entirely public symmetric algorithm with 128-, 192-, 256-bit key and 128-bit block.

Wrong choice of algorithm class

This is also widespread reason, when a designer chooses good but absolutely unsuitable algorithm for his purposes. Mostly it is encryption instead of hashing or symmetric algorithm instead of asymmetric one.

A lot of examples may be given here. Among them there are almost all the programs, restricting with password computer access while it is powering on or loading, for example, AMI BIOS, which stores encrypted version of password (easily decryptable) instead of hashed one.

It is naturally to use asymmetric cryptography, which doesn't allow to fit a key even when the entire traffic is eavesdropped, in all network authentication procedures. However, such algorithms (from network computer systems) are yet implemented only by Novell Netware 4.x, the rest are satisfied (in the best case!) with ordinary "challenge-response" scenario, where one may carry out rather a quick search of eavesdropped "challenge" and "response" values.

Repeated usage of cipher keystream

Windows 3.x and Windows 95 early versions' encryption-relevant vulnerability have already become classical example. Microsoft programmers, known for their security knowledge, applied RC4 (representing none other than stream encryption) several times with the same keystream to different data (network resources, stored in .pwl-type files).

It turned out that one of data sets of .pwl file represents extremely specific text, namely 20-character user name (in uppercase) and resource pointers set (see Table 1). Thus, guessing user name (which often coincides with file name) allows to compute at least 20 byte of a keystream. Since keystream remains unchanged while other resources are being encrypted (it is the main error of RC4 application in this case), one can compute the first 20 bytes of all resources, containing the length of each of them. After the length computing one can determine pointer values, thus adding several tens of bytes to guessed keystream. This algorithm is implemented in the wide-known glide program.

Figure 2. .PWL file format.

Storing a key along with data

For this reason data, encrypted with cryptographically strong and correctly implemented algorithm, can be decrypted easily. This is because of problem being solved specific, when it is impossible to enter a key from without, and it is stored somewhere inside, practically in plaintext form. In other words, the most vulnerable algorithm here will be not encryption on key but key encryption (on some secondary key). But since this secondary key cannot be stored on the outside (it evidently follows from the problem characteristics), the rest data will be decrypted without exhaustive search sooner or later.

Typical examples here are all of WWW-, ftp-, e-mail-clients. The point is that for base (the most common) authentication in these protocols a password is to be transferred to server in public. That is why client programs are to encrypt (but not hash) a password, and with fixed key, in order not to pester a user with endless requests. Hence, all your passwords, practically exposed, are kept somewhere inside any browser, e-mail- or ftp-client (be it Netscape Communicator, Eudora, Outlook, FAR, etc.), and it takes no trouble to decrypt them. (By the way, password is mostly not even encrypted but encoded by algorithm of base-64 type in such programs).

4. Human factor

Human operator errors are perhaps the most expensive and widespread in all crucial system. As for cryptosystems, unskilled user's work brings to naught the strongest cryptalgorithm and the most correct implementation and application of such algorithm.

Firstly it is conditioned by password choice. Clearly, short or sensible passwords are easy to remember, but they are also easy to disclose. Without any doubt, long or senseless passwords are better in cryptographic strength sense, but in general users cannot remember them: they write them down on a slip of paper, which can be either lost or fallen into adversary's hands.

Last years are signed by attention paid to solving of this conflict, but good password choice recommendations are out of the scope of this paper.

Since inexperienced users usually choose either short or sensible passwords, there are two methods of their disclosure: exhaustive search attack and dictionary attack.

Exhaustive search attacks had got a good chance of success due to the great advance of computer power (see also "Short key"). If in UNIX crypt() function, answering for password hashing, was being executed for nearly 1 second on PDP machine, its execution rate was 15000 times increased (!) in the space of twenty years. Hackers (and designers, who limited password length to 8 characters) could not even imagine exhaustive search attack quite recently, and now this attack succeeds in 80 days at average⁸. Table 1 demonstrates exhaustive password search rate for several cryptosystems.

But let return some years back, when computer power was not enough for exhaustive password search. Nonetheless, hackers have invented a witty approach, benefited from the fact that in general user chooses sensible word or some information about himself or his friends (name, birthday, etc.) as a password. Since any language includes at most 100000 words, it will not take much time to look them through, moreover, from 10 to 40% of existing passwords can be guessed with a simple "dictionary attack" scheme. (By the way, up to 50% of these passwords can be guessed with the help of dictionary of only 1000 words!). Even Morris' virus (in 1988!) used this approach, especially as dictionary file, commonly used by corrector programs, is often at hand in UNIX. As for "own" passwords, one can get much information about user from the /etc/passwd file: user login name, name and surname, home directory. Morris' virus benefited from following assumptions [3]:

• login user name is used as a password;
• doubled user name is used as a password;
• the same read from right to left;
• user name or surname;
• the same in lowercase.

Today users have already understood that they would not choose such passwords, but computer security experts will scarcely wait for use of such simple passwords to their liking as 34jXs5U@bTa!6. Therefore even experienced user uses cunning and chooses passwords like hope1, user1997, pAsSwOrD, toor, roottoor, parol, gfhjkm, asxz. Clearly, all of them are generally based on sensible word and some simple transformation, such as adding a numeric character, adding a year, changing upper-lower case every letter, writing a word backwards, adding a word written backwards, writing national (Russian) word in Latin, typing national word with the Latin keyboard, forming a password of neighbour keys of a keyboard, etc.

So you should not be surprised at hackers" cracking such "sophisticated" password, they are not more stupid than users and have already inserted the rules of possible word transformation into their programs. In the most advanced programs (John The Ripper, Password Cracking Library) these rules may be programmable and be given in special language by hacker himself.

Here is an example of such exhaustive search strategy efficiency. A lot of books on security recommend to choose two sensible words, divided by a sign (good!password, for example), as a safe password. Let us count, how much time it would take to crack such passwords at average, if such a rule is included into cracker-program set (given dictionary of 10000 words, with 10 numeric characters and 32 punctuation marks and special symbols as dividing signs, Pentium of 15000 crypt/sec rate): =140000 seconds or less than 1.5 days!

Summary

Since this paper was being working on in 1996, the situation with cryptography usage in application programs has been changing for the better indisputably. Gradually the developers realize that it is necessary to apply proved algorithms, the problem of cryptalgorithm export is set in motion in a number of countries, new algorithms and standards with more key length and efficiency for all processor types implementation, from 8-bit to RISC processors, are developed.

Nevertheless, a huge gap still remains between strength level and safety of existing cryptalgorithm software, where "infantile" flaws are being discovered up to now (the last example is Microsoft's PPTP application [4]), and cryptographic strength level, demonstrated by recent algorithms and protocols, tested independently by leading cryptanalysts, where one of the most serious vulnerabilities requires 2⁶⁵ ciphertext blocks and then looking through 2⁵⁸ variants, or the same plaintext, encrypted with 2³³ different but interdependent keys, and then analysis complexity of 2⁵⁷ [5].

I should like to hope for future implementation and application of such algorithms to keep the high level of safety.

¹ Cryptographic strength here and further means key amount needed for key determination by exhaustive search.

² It was such till recently. Now it is 56 bit.

³ [ ] - integer part (the nearest integer from below).

⁴ ] [ - the nearest integer from above.

⁵ It is obvious that we get the same values both here and in the example above, but because of rounding off from different sides it appears one symbol difference.

⁶ It approximately corresponds to 56 bit for symmetric algorithms.

⁷ million instructions per second in a year.

⁸ Special boards or concurrency can give several digits reduction of time overhead.

1. "Theory and practice of information security". Moscow, "Yachtsman", 1996.
2. Paul C. Kocher. Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems
3. Mark W. Eichin, Jon A. Rochils. With Microscope and Tweezers: An Analysis of the Internet virus of November 1988
4. Bruce Schneier, Peter Mudge. Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP)
5. Eli Biham, Lars R. Knudsen, Cryptanalysis of the ANSI X9.52 CBCM Mode, CS 0928, Proceedings of Eurocrypt'98.