Why Migrating to Triple DES is Not Easy

Why Migrating to Triple DES is Not Easy 

Abstract 

Financial institutions are performing large scale migrations of their systems 

from DES to triple-DES. In this white paper we describe the basic 

characteristics of DES and triple-DES and look at the security properties 

that a financial transaction system will want to achieve. We then look at the 

problems related with a migration from DES to triple-DES, enumerating and 

discussing several points that we suggest should be considered. Finally, we 

give some suggestions that will help ease the problems of migration.

Contents 

1 Introduction 1 

2 Single DES and triple-DES 1 

3 Security properties wanted 3 

4 Migration issues 4 

4.1 DES is the weakest link . . . . . . . . . . . . . . . . . . . . . . . 4 

4.2 The algorithm itself . . . . . . . . . . . . . . . . . . . . . . . . . 5 

4.3 Key blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

4.4 Hardware update . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

4.5 Software/Firmware update . . . . . . . . . . . . . . . . . . . . . 7 

4.6 Payment application database . . . . . . . . . . . . . . . . . . . . 7 

4.7 Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

4.8 Old vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . 8 

5 Easing the migration 9 

6 Conclusion 10

1 Introduction 


DES, the Data Encryption Standard, is a cryptographic algorithm that was standardized 

in 1977 by the National Institute of Science and Technology (NIST). 

When the financial industry started to deploy ATMs they opted for DES for securing 

transactions. This choice was reinforced by the development of X9 standards 

for financial transactions that were based on DES. DES has stood the test of time, 

no attack against this encryption algorithm in practice has been better than brute 

forcing the key space. However, DES uses short keys, with current technology 

the key space (of size 2 56 ) can be exhausted in around 56 hours using one single 

machine worth less than 250 000 US dollars, or in 22 hours with the combined 

help of a network of about 100 000 personal computers. This means that single 

DES is no longer secure. On the other hand, triple-DES, as defined in ANSI 9.52, 

is considered to be secure. Indeed, NIST renewed the DES standard in 1983 and 

1988, in 1993 it renewed it with hesitation and controversy and in 1999 DES was 

to be used only in legacy systems. NIST, in 1999, standardized triple-DES, based 

on ANSI 9.52. Triple-DES is a secure replacement for single DES, it is not currently 

feasible to exhaustively search the key space of triple-DES, nor will it be 

in the near future unless drastic unpredictable technological and/or cryptanalysis 

advancements occur. 

In 1993 the financial industry had started replacing DES by triple-DES for 

the confidentiality of keys residing in cryptographic processors. In 1999, with 

the concordance of NIST no longer approving single DES, the financial industry 

started planning a migration, which consists of replacing single DES with triple- 

DES in all its systems wherever single DES is used. 

This migration plan however places the industry, which uses single DES widely, 

in a challenging position. As will be discussed in this document, the process of 

migrating from single DES to triple-DES is not as simple as just substituting one 

algorithm for another. 

2 Single DES and triple-DES 

DES is a block cipher, encryption algorithm, which encrypts messages of block 

size 64 bits and produces cryptograms of length 64 bits using a 56-bit key (DES 

keys are actually 64 bits in length but 8 bits act as parity bits so only 56 bits are 

actually used for encryption). 

c○Copyright Okiok Data 2002 1


We say that DES has strength 2 56 , meaning that the most efficient way to attack 

DES in practice 1 is to search its key space of size 2 56 . That is, to attack DES in 

practice one has to try each and every possible key until the correct encryption 

key is identified, this takes on average 2 56 /2 = 2 55 steps. 

Triple-DES, noted as 3DES from here on, uses 2 keys, chosen independently 

at random, to DES encrypt a message multiple times. There are also ways to use 

3DES with 3 different keys, but these schemes do not give a significant amount 

of extra security in theory and are not considered in financial systems. The most 

common technique is to encrypt the initial plaintext message with one key, decrypt 

the result with a second key and finally encrypt this last result with the first 

key again. This is known as E-D-E double length key 3DES encryption and is 

illustrated in the following figure. 

1 other attacks exist in theory, but they demand an unreasonable amount of known or chosen 

plaintext-ciphertext pairs which renders the attacks unpractical. 



E-D-E 3DES is compatible with single DES (when KL and KR are identical, 

E-D-E 3DES produces the same result as single DES). From here on, when we 

will talk about 3DES we will be referring to double length key E-D-E 3DES. 

The strength of 3DES is approximately 2 112 since using two 56 bit keys in E-D-E 

3DES is effectively equal to using one 112-bit key. A brute force search of 3DES 

2 112 key space is currently not feasible nor will it be in the near future. 

3 Security properties wanted 

Many security properties are wanted in a financial transaction system. We will 

not go into details and enumerate all of the security properties wanted but simply 

mention a couple of them in an informal way so as to motivate some of the 

discussions in the following sections. 

SP1 A cryptographic key should not be in cleartext in any single point of the 

system. This is the basic security property that a financial institution must 

achieve in order for users to have any sort of trust in the system. This is also 

an important point when different institutions interchange financial data between 

themselves, the security of one institution depends on that of others. 

To achieve this property cryptographic keys must be stored in secure cryptographic 

processors, if they are ever outside these processors they must be 

in a form that does not compromise the security of the keys, such as in split 

knowledge (under the possession of different individuals having certain permissions), 

or encrypted under another cryptographic key which is protected 

in a secure cryptographic processor. 

SP2 Security against known key attacks, if a working key in the system is 

discovered, this should not enable an attacker to figure out the values of any 

other keys in the system. Some would say that if a system is secure, no 

single key will ever be compromised so there is no need to worry about this 

security property, but as we will see later on this can be a dangerous way of 

thinking. 

SP3 The security of any 3DES key should be 2 112 . It should not be possible 

for example to break a 3DES key by breaking one or a couple of single 

DES keys. If a cryptographic key is to be protected by another one, this 

last key should be of cryptographic strength equal or greater than the key 

it is protecting. This implies for example, among other things, that if any 



working key is a 3DES key, the key encryption key should be a 3DES key as 

well. 

SP4 It should not be possible to combine different key parts in order to trick 

a secure cryptographic processor into revealing information that can 

lead to breaking any cryptographic key secured by the processor. This is 

important to consider for example when deciding how keys protected outside 

a security processor should be stored. 

Of course, when analyzing the security of a system, the above security properties 

must be specified more formally, and others should be enumerated, but the 

above list is enough for us to be able to discuss about security problems related to 

migrating from DES to 3DES. 

4 Migration issues 

It is not sufficient to simply replace single DES with 3DES, security wise and 

operationally wise. In what follows we discuss about several problems that might 

arise and issues that should be considered when attempting to migrate from single 

DES to 3DES. 

4.1 DES is the weakest link 

A system is just as secure as its weakest link. In a system that is composed of 

PIN pads, ATMs, acquiring hosts, switches, alternate switches, processors, etc., if 

a single entity in the system still utilizes single DES there is a possibility that the 

security of the whole system might be compromised by an attack on single DES. 

As an extreme example, consider a secure cryptographic processor of an acquiring 

host that uses a 3DES master file key (MFK), but also uses a single DES key 

exchange key (KEK); the confidentiality of all keys that are sent to the processor 

can be compromised, even if the keys stored in the local database are protected by 

3DES encryption, so the fact that the MFK key is 3DES does not provide much 

of a security advantage. Less obvious examples can also lead to extreme security 

breakage. Consider the attack against the IBM 4758 cryptoprocessors using the 

CCA software that was found enabling an individual with a certain permission to 

extract all DES and 3DES keys from the processors ([9]). The attack was made 

possible by a combination of things that existed because the processors had to 



continue to support single DES even though 3DES was used for protecting the 

keys. 

Due to the complexity of financial systems, it is not feasible to replace all keys 

with 3DES keys right away, systems will have to live in a heterogeneous state. 

It is important however to analyze each situation and to consider how the system 

satisfies the security properties wanted. Most certainly, until all keys are replaced 

with 3DES keys, the system will not achieve 2 112 security, but the system can be 

upgraded progressively so as to withstand more and more attacks. Security, as in 

this case, is often an incremental process. 

4.2 The algorithm itself 

When using 3DES certain variants of modes of operations are available which are 

not for single DES. Some of these variants may seem attractive at first glance because 

of their performance gain properties, unfortunately they are not all secure. 

For example, for single DES, cipher-block chaining (CBC) is a good mode to use 

since it is provably secure [3]. However, there are different ways of implementing 

CBC mode for 3DES, one can use triple-outer-CBC mode (CBC mode applied directly 

to 3DES) or triple-inner-CBC mode (a variant, a multiple encryption mode 

of operation where the feedbacks are taken from the single DES operations of 

which 3DES is composed of). We do not describe these modes in further detail 

in this document (see [10] if interested), it suffices to know that they are two variants 

of CBC for 3DES. Although triple-inner-CBC mode can appear to be more 

appealing since it can be pipelined, thus allowing for more efficient implementations, 

triple-inner-CBC mode is significantly weaker than outer-inner-CBC mode 

under certain attack models and is not recommended ([4]). 

When migrating from single DES to 3DES and designing a new system or 

looking for existing solutions, it might also be fruitful to consider other encryption 

algorithms as well, such as the AES, which will become a U.S. government 

standard may 26th, 2002. If when migrating to 3DES you also make your system 

ready to accept other encryption algorithms or modes of operations, you will have 

an advantage and will save time and money in the long run. Flexibility is our 

friend here. 


4.3 Key blocks 


Current key blocks 2 such as the key block for the keys encrypted in the payment 

application key databases, and the key blocks for the key exchange keys, are not 

adequate to support 3DES. Attacks have been presented ([7], [5]) against key 

blocks currently used by the financial institutions, in which keys can be used for 

functionalities that they where not intended for, and knowledge of certain working 

keys can leak knowledge of other keys, violating security property SP2. The 

attacks work even if the key blocks use encryption with a provably secure mode of 

operation such as CBC, even when used in combination with variants or control 

vectors 3 . The techniques of the attacks are based on substituting parts of the keys 

and brute forcing single DES keys twice. This can be done on average in 2×2 55 = 

2 56 steps, which is much smaller than 2 112 (the number of steps needed to try each 

and every double length 3DES key). This clearly violates security properties SP3 

and SP4. It is crucial to cryptographically tie the functionality of a key to the key 

itself, this can be achieved by securely using a MAC or a digital signature scheme 

for example, or an encryption mode of operation that also provides integrity such 

as the one described in [8]. A proposal to ANSI X.9F for a new key block format 

is described in [5]. What is important to remember is that encryption alone does 

not provide integrity. 

4.4 Hardware update 

There are obvious problems if hardware, such as PIN pads, ATMs and cryptographic 

processors, cannot be upgraded in the field. Even if upgrades can be done 

in the field, migration has to be coordinated with other devices and software. If a 

PIN pad can only use single DES and a switch has been upgraded to use 3DES, 

the switch needs to be configured to be backwards compatible with single DES. 

This backwards compatibility feature could potentially be used to the advantage 

of an attacker (as was discussed in section 4.1). 

There is also a question of speed. 3DES encryption and decryption takes approximately 

three times longer to execute than does single DES encryption and 

2 a key block is a data structure for specifying the value and attributes of a key that is to be 

stored or exchanged, key blocks for private keys usually use some sort of encryption. 

3 variants and control vectors are bitpatterns that are bound to encrypted keys by a XOR operation 

with the encrypting key. If a naive attacker introduces into a cryptoprocessor a cryptogram 

of a key bounded by a control vector or variant of the wrong type the cryptoprocessor’s decryption 

operation should simply produce garble and no useful information about the key would be 

revealed. This technique does not work when encrypting keys longer then the block size. 



decryption 4 . Memory allocation and caching can also affect the speed of execution 

of 3DES encryption and decryption, especially during the key setup stages. 

Some custom designed cryptoprocessors also deal poorly with the safeguarding 

of 3DES keys in memory register, some key parts can get overwritten in their 

register slots by other 3DES key parts or single DES keys if allocation is not done 

correctly. This was observed in a PIN pad we once evaluated, the problem had 

to do more with the architecture of the hardware rather than 3DES itself however, 

mostly due to the fact that some embedded systems have limited storage space. 

The lesson to learn is that a cryptoprocessor can work perfectly well when it only 

does single DES but start showing strange behavior when using 3DES. 

4.5 Software/Firmware update 

Command sets will undoubtedly be modified if a system is to support 3DES. It 

is crucial to make certain that there will be no compatibility problems and that 

security is not affected. For example, one can have software running on a device 

which will accept to load new software after verifying a MAC. If the new software 

is needed to use 3DES, but the old software’s MAC is based on single DES, one 

needs to make sure that this procedure is secure in the given context (for example, 

it is secure if you still trust single DES). 

It is highly recommended to analyze any new transaction set, to be convinced 

of this one simply has to look at the recent API-level attacks on embedded systems 

described in [2]. 

4.6 Payment application database 

We already talked about the need for a new key block in section 4.3. It is also 

important to consider the simple fact that 3DES keys are larger than single DES 

keys and that the format of the key blocks will be different. One should make sure 

that databases will be able to handle this change. 

4.7 Key Management 

Key management is probably one of the more complex parts of any cryptosystem. 

New kinds of cryptographic keys means new kinds of key management. Key 

exchange methods (manual or automated) for 3DES will differ from those for 

4 if no pipelining is done. 



single DES. For example, split knowledge schemes for 3DES are different than 

those for single DES and it is important to make sure that the new schemes that 

will be used continue to satisfy the security requirements. When one splits a 3DES 

key between two individuals, a typical scheme will produce four parts, K1L and 

K2L, which when XORed together forms KL (the first part of the 3DES key) as 

well as K1R and K2R which when XORed together forms KR (the other part of 

the 3DES key). Now, the scheme is secure if the first person is in custody of K1L 

and K1R, and the second person is in custody of K2L and K2R. This way, neither 

individual has any information what so ever about the 3DES key. However, if the 

first individual is in custody of K1L and K2L, and the second of K1R and K2R, 

each individual learns information about the key (notably, one whole part of the 

key by XORing both of the individual’s parts together). If one of the individuals 

can have access to the encryption of a message under the key in question (most 

processors will have a command that will allow them to do so), they simply need 

to do the equivalent of a brute force attack on a single DES key to compute the 

whole 3DES key. Thus, there is not 2 112 security. 

Key generation is another important part of key management. It is important 

to securely generate random 3DES keys, poor randomness if often a weak point 

in a cryptosystem, (see [6] for a motivational example.) For example, one should 

not generate a 3DES key by first generating a single DES key, defining it to be 

KL, and then using a known variant in order to generate KR from KL. Both part 

of the 3DES key should be generated independently and uniformly at random. 

4.8 Old vulnerabilities 

Most systems have vulnerabilities, see for example [1]. Some security vulnerabilities 

are known and they are considered acceptable in certain contexts. It all 

depends on the outcome of a risk analysis, which is a very important step to take 

when migrating a system. It is important to fully study the risks that might arise 

and determine the best way to manage them, to accomplish this one needs to know 

the security properties that must be achieved and the security state of the system 

and evaluate the risks. Risk analysis should be done at every phase of the migration 

plan. 

When migrating to 3DES, with the goal of achieving 2 112 security, it is also 

important to reconsider old vulnerabilities. It might have been acceptable for a 

system to be vulnerable to a 2 56 brute force attack at the time of deployment 

and accreditation, but it is probably no longer acceptable. When you modify a 

system that has old vulnerabilities you also risk the danger of creating new ones, 



sometimes even worst ones. One should take time to analyze the problem, review 

the security properties that the system is to respect and make sure that the updated 

system does not introduce any new security loopholes. It is important to try to 

solve old security problems and avoid new vulnerabilities. 

5 Easing the migration 

In this section we give a list of checkpoints useful for easing a migration from 

single DES to 3DES. This is not intended to be an exhaustive list but simply a 

bases for reflection on planning the migration. The items are not presented in any 

particular order. 

1. Make sure that implementations of DES can be configured to use 3DES. 

As mentioned in section 4.4, just because an implementation states that it 

is 3DES compatible does not necessarily mean that it will work with ease. 

Before planning a migration to 3DES, make sure that the system is capable 

of using 3DES. Systems already deployed may require re-certificaton/reaccreditation. 

2. Validate that the system satisfies the new algorithm’s memory requirements. 

Double length 3DES keys are twice as long, and new block formats for encrypting 

3DES keys might have some extra overhead. One should verify that 

databases, processors, etc., can handle this increase in data size. 

3. 3DES keys should not be protected using single DES keys. It is important 

to verify that DES does not become the weakest link in any segment of the 

system. 

4. Planning ahead. One should plan the hardware and software updates, so that 

everything is coordinated as necessary. Procedures need to be reviewed and 

most probably updated. 

5. If both single DES and 3DES are to be supported, it might be useful to 

split the system into two parts, one that securely uses 3DES and no single 

DES encryption and the other that continues to use single DES. For example, 

instead of having two cryptoprocessors configured to both use single 

DES and 3DES, have one cryptoprocessor simply use single DES and the 

other strictly use 3DES. This may require modifications to the transaction 

dispatcher in order for it to act differently depending on the end point. This 

enables at least part of the system to attain 3DES security, instead of having 



the whole system vulnerable to single DES because it is needed for backwards 

compatibility or other functionality that is not part of the migration 

plan. 

6. Sending managers on site in order to load new keys can be costly. It might 

be useful to try to synchronize on site hardware update with on site physical 

key loading. 

7. Certain cryptographic keys will no longer be used, evaluate the key hierarchy 

and decommission obsolete keys. Managing keys is a challenging task, 

keeping unused keys around simply adds to the complexity. 

8. It might be useful to construct wrappers around existing encryption technology, 

so that these can be changed and updated more conveniently (DES to 

3DES, or DES to AES for example). One has to be careful however so as to 

not give way to security weaknesses based on backward compatibility of the 

encryption technology. 

9. Risk Analysis. This is probably the most important part of the migration. As 

discussed in section 4.8, risk analysis should be done at every phase of the 

migration plan. 

These are just a few suggestions and points to be considered. Migrating from 

single DES to 3DES is not easy, but careful planning and adequate analysis and 

support can ease the process. 

6 Conclusion 

The Data Encryption Standard (DES) has allowed financial institutions thru out 

the world to share automated self-service facilities while maintaining open competition 

on the market. This 1977 based cryptographic standard is no longer considered 

secure and the general approach (approved by NIST and the financial industry) 

is to replace DES by 3DES everywhere encryption is done. We have pointed 

out and discussed many issues concerning migration to 3DES. Banks will need to 

carefully review their own implementation to take into account these concerns. 


References 


[1] ANDERSON, R. Why cryptosystems fail, from communications of the ACM, 

november, 1994. In William Stallings, Practical Cryptography for Data Internetworks, 

IEEE Computer Society Press, 1996. 1996. 

[2] ANDERSON, R., AND BOND, M. API level attacks on embedded systems. 

IEEE Computer 34 (October 2001). 

[3] BELLARE, M., KILIAN, J., AND ROGAWAY, P. The security of the cipher 

block chaining message authentication code. JCSS: Journal of Computer 

and System Sciences 61 (2000). 

[4] BIHAM, E. Cryptanalysis of multiple modes of operation. In Proc. 4th 

International Advances in Cryptology Conference – ASIACRYPT ’94 (1994), 

pp. 278–292. 

[5] COMPAQ COMPUTER CORPORATION. A proposal to ANSI X.9F for a new, 

standard key block to enable secure storage, transmission and control of 

cryptographic keys, 2002. 

[6] GOLDBERG, I., AND WAGNER, D. Randomness and the Netscape browser. 

Dr. Dobb’s Journal of Software Tools 21, 1 (Jan. 1996), 66, 68–70. 

[7] HOPKINS, D. Private Communication (2001). 

[8] JUTLA, C. S. Encryption modes with almost free message integrity. 

In Advances in Cryptology – EUROCRYPT ’ 2001 (Innsbruck, Austria, 

2001), B. Pfitzmann, Ed., vol. 2045 of Lecture Notes in Computer Science, 

Springer-Verlag, Berlin Germany, pp. 525–542. 

[9] M. BOND, R. C. Extracting a 3des key from an ibm 4758. 

http://www.cl.cam.ac.uk/ rnc1/descrack/. 

[10] MENEZES, A. J. A. J., VAN OORSCHOT, P. C., AND VANSTONE, S. A. 

Handbook of applied cryptography. The CRC Press series on discrete mathematics 

and its applications. CRC Press, 2000 N.W. Corporate Blvd., Boca 

Raton, FL 33431-9868, USA, 1997. 


About Okiok Data 


OKIOK DATA has been at the forefront of the Information Security field since 

1983. The new business models born from the use of IT have brought about a 

number of new business risks. Counting on its many years of experience in IT 

security, OKIOK DATA proposes a set of services that will help you manage 

these risks in a manner that is appropriate for your business: Analysis of your 

requirements, your systems architecture, and the threats linked to your business 

activities. Diagnostics on the security level of your systems and identification of 

the areas of weaknesses. Product comparisons and recommendations on security 

measures and products that will help control your risks. Whether you wish to add 

specific security expertise in a timely fashion, or to simply complement your team 

of security professionals, OKIOK DATA’s experts can get involved at any stage 

of your projects, including at the corporate strategic level. Our clients come from, 

amongst others, the financial world, telecommunications, health and governments. 

3945 St-Martin West 

Laval (Quebec) 

Canada, H7T 1B7 

Phone: (450) 681-1681 

Fax: (450) 681-1682 

www.okiok.com

Why Migrating to Triple DES is Not Easy

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?