Why Migrating to Triple DES is Not Easy

Why Migrating to Triple DES is Not Easy
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,
c○Copyright Okiok Data 2002 8