Hi list!

I have 2 questions about TripleDes- first about a problem I'm running into
implementing the tripleDES algorithm in the .net framework, and the second is
an academic one about what I thought I knew about tripleDES vs. how it's
implemented in the framework.

Question 1)
When I'm creating a new instance of an asymmetric algorithm (TripleDes), the
key that is randomly generated at instantiation isn't always the right
length. It flip flops between 8 and 24 bytes. Here's my code for generating
a new key and IV:


TripleDES whoIsJohnGalt = new TripleDESCryptoServiceProvider();
whoIsJohnGalt.Mode = CipherMode.CBC;
txtKey.Text = "";
txtKey.Text = Encoding.ASCII.GetString(whoIsJohnGalt.Key);
txtInitializationVector.Text = "";
txtInitializationVector.Text = Encoding.ASCII.GetString(whoIsJohnGalt.IV);


Any thoughts? When the key length goes to the 8 byte length, I get an
exception stating "Specified key is not a valid size for this algorithm."
This seems odd- I'm letting the framework handle the key generation for the
app, so I don't quite understand why it's the wrong length.

My encryption code block is as follows:

// Create the encryptor object, specifying 3DES as the
// encryption algorithm
Encryptor enc = new Encryptor(EncryptionAlgorithm.TripleDES);
// Get the connection string as a byte array
byte[] plainText =
Encoding.ASCII.GetBytes(txtConnectionString.Text);
byte[] key = Encoding.ASCII.GetBytes(txtKey.Text);

// Perform the encryption
byte[] cipherText = enc.Encrypt(plainText, key);
// Store the intialization vector, as this will be required
// for decryption
txtInitializationVector.Text = Encoding.ASCII.GetString(enc.IV);

// Display the encrypted string
txtEncryptedString.Text = Convert.ToBase64String(cipherText);


Question 2)
I read in wikipedia that TripleDes requires 3 56 bit keys. Why does the
..net framework accept only 128 or 192 bit keys for the TripleDes algorithm?
At the very least, I'd expect it to use a 168 bit key and split it up
manually. Why the discrepency between the standard and how it's called in
..Net? How can the algorithm work with just a 128 bit key? What's being done
with the extra bits in instances where we're using a 192 bit key?

Thanks!

-Patrick

lol! That's a fantastic response. Thanks for taking the time to share-
that's a far deeper explanation of Triple Des than anything I've read so far.
Now if I can just figure out why .Net's instantiating the cryptoservice
provider with an 8 bit key :)

Hi,


What a coincidence: Sunday afternoon, I just got back home from gym and
found myself in a writing mood and you asked a question about 3DES:-). Did
you already realize that you were kind of unlucky? :-).

First of all, to explain details of 3DES key length we have to start with
the DES. In 1973 the National Bureau of Standards (predecessor of NIST)
published solicitation for cryptosystem standard. Approximately the same
time Horst Feistel developed cipher known by the name Lucifer in IBM Watson
laboratory in New York. IBM published several technical reports concerning
design of Lucifer and proposed use the cipher for data encryption standard.
NSA become involved in the process and modified cipher by reducing key
strength from 128 bit to 56 bit and changing values of S-Boxes. Last was
actually shown to improve security of DES by defending it against
cryptanalytic attack that was unknown to public at the time of DES
standardization process. Differential cryptanalysis was (re)discovered in
public cryptographic community only in 1991 by Biham and Shamir, while as it
was known by the NSA in early 70th by the name T-attack (where T stays for
tickling see: Coppersmith's paper "The Data Encryption Standard and its
strength against attacks"). At least it looks that during time of DES
standardization process, all-mighty NSA didn't know linear cryptanalysis
that was invented in 1993 by Matsui;-).

Block size of DES is 64 bits and it was more natural to keep keys in 64 bits
blobs, so NSA suggested use of structural key being stored in 8 bytes array
with each 8th bit being parity bit. Rationale for parity bits dropped into
key structure supposed to add some redundancy that could allow checking key's
integrity. However, none has used parity bits for that purpose anyway and
everyone has agreed about another reason of adding parity bits to the key:
consensus was that reducing key length from to 56 was apparently done by NSA
for purposes being capable of breaking DES with brute force search. Fast
hardware DES was publicly demonstrated during middle of 70th. In 1977 Diffie
and Hellman did cost estimate of brute force DES machine containing about
10^6 fast hardware DES chips and capable of breaking DES in about two days
to be about 20 million USD (just guess how much it is in today's money:-)).
So, only few governments could afford building such machines for brute force
DES at that time (and it's logical to believe that NSA had that in the
middle of 70th). When it concerns brute force - 56 bits keys are 256 times
weaker than 64 bit keys and building 256 such machines for being capable
breaking the cipher with 64 bit keys was out of rich even for NSA.



Anyway, one of the distinctive characteristics of cryptographic researchers
is paranoia :-) (I recall David Wagner's reaction on accusing of paranoid
estimation of cryptographic design:

">This is paranoid point of view!

Yup. That's cryptography. I find that a touch of paranoia is often an
asset when doing cryptographic design.":-))

So, right from the publishing of DES there were many attempts to design
protocols using DES that would increase key security. One such naïve attempt
was suggestion for double DES - i.e. using two different DES keys to
sequentially encrypt the same text Y=ENC(K2, ENC(K1, X)). First of all it is
easy to see that is a classical definition of product cipher, and for
product cipher to add any security at all it is required that ciphers should
be non-idempotent cipher (or more generally called non-group cipher).
Idempotent or group ciphers have characteristic that applying them twice to
is actually equivalent of applying it only once with different key. DES is
not such cipher (as any modern block cipher), however, being a pseudo-random
function from 64 bit numbers space to itself DES has property that it forms
cycles of length SQRT(Pi*2^64/8) with the same probability. But
probabilistic DES cycles do not affect security of DES compostion. However,
as it was shown by Bellare and Rogaway, meet-in-the-middle attack (which
requires O(2^56) storage and encryption operations) makes that using two
different keys only adds one bit of security (instead of expected 56 bits).
Meet-in-the-middle attack is a brute force search that is done from two
opposite sides - first is encrypting plain text with all possible DES keys,
and second is decrypting product cipher text with all possible DES keys and
looking for collisions. Once collision is found - we have both keys in
Double DES. Therefore, for adding security to product cipher it is required
to use at least 3 DES operations in order: encrypt, decrypt, encrypt or
decrypt, encrypt, decrypt. And that is actually design of 3DES with 3 keys:
Y=encrypt(K3, decrypt(K2, encrypt(K1, X))). In case when K3==K1 it is called
as 3DES with two keys. However, modified meet-in-the-middle (with ridiculous
storage requirements) could be used against 3DES with 3 keys that makes some
people to argue that strength of 3DES 3 keys is not much better than 3DES 2
keys and lies in area between 112 and 128 bits of security. Note that 128
bit AES provides better security and higher speed - several 10th (if not
hundreds) times faster than 3DES.

However, since we use DES keys for 3DES - they are expected to be given in
64bit structure containing 8 parity bits. Therefore, many standard
cryptographic packages are expecting 3DES keys to be passed in multiple of
64 bits and treat 128 bit block as 3DES with 2 keys and 196 bits as 3DES
with 3 keys, while as actually it will be only 112 and 168 bits that are
used in key schedule.



Wow, great to know that you read that @#$% right to the end. Now you know
why I told you that "you were a bit unlucky" :-).



-Valery.

http://www.harper.no/valery



[quoted text, click to view]