Why triple encryption instead of split+encrypt?

Why do people do tripple DES and *shudder* tripple IDEA
instead of doing some form of non-redundant secret splitting
and then encrypting with multiple keys.

For example, instead of triple DES, why not

A) divide the compressed plaintext into blocks of n*64 (where n=2 in the
   simple example, higher in the overkill examples)

B) Split each block into n parts such that:

     i)   The splitting can be reversed.
     ii)  During the inverse of the splitting each bit in the plaintext is
          dependent on several bits from each of the parts of the splittext.
     iii) The total number of bits in the splittext is the same as in the
          plaintext.
    
   The last point will make this form of secret spliting relatively
   insecure, but that's OK for this application (I think, this is
   really what I'm asking you.)

C) Now, for each n*64 bit block you have n blocks of 64 bits. Hook these
   together in n chains and encrypt with DES with different keys in CBC,
   CFB or OFB mode.

D) Unencrypt on the other end.

You can make the key size arbitrarily large and it takes much less time
than triple DES and its immune to meet in the middle attacks. So why do
we use triple DES?

If I am wrong about the security of point B-iii, am I correct that by
switching to a secure secret splitting algorithm and setting n=2, we
still get faster performance for the same cryptanalytical hardness as
triple DES?

Cheers,

JWS

solman@mit.edu says:
> Why do people do tripple DES and *shudder* tripple IDEA
                   ^^^^^^^triple.

> instead of doing some form of non-redundant secret splitting
> and then encrypting with multiple keys.

Because people like algorithms that work quickly and don't expand
their data by a factor of two or three. As I've noted before, in spite
of protestations, the evidence is good that splitting and encryption
doesn't by you much over simple superencipherment.

Perry

> 
> solman@mit.edu says:
> > Why do people do triple DES and *shudder* triple IDEA
> > instead of doing some form of non-redundant secret splitting
> > and then encrypting with multiple keys.
> 
> Because people like algorithms that work quickly and don't expand
> their data by a factor of two or three. As I've noted before, in spite
> of protestations, the evidence is good that splitting and encryption
> doesn't by you much over simple superencipherment.

Although I mentioned "true" secret splitting at the end of my post, I was
refering to non-redundant secret splitting in most of the post. That is,
for each 128 bit block, you split it into two 64 bit blocks. Obviously you
have to make sure that in the inverse of the split, each bit of the 128 is
dependent on multiple bits in both 64 bit parts.

This is obviously not as secure as traditional secret splitting, but you
don't need it to be because this isn't a threshold scheme. You just need
to guarantee that knowing one half does not allow you to reassemble the
other half. I am claiming that you can allow the crypt analyst to remove
half of the entropy from the plaintext (did I phrase that right? probably
not :( ) and the other half will still require successful cryptanalysis
of DES and since you can't tell if you're right until you get both halves,
meet in the middle does not work.

So, is a secret splitting algorithm that does NOT increase redundancy
followed by DES with different keys on both halves as secure as triple
DES? I believe so, but I would like your opinions on the issue before
I consider implementing this. If it works it would be especially nice
because it allows arbitrary extension of keysize without substantially
increasing the time required for computation.

I have a hunch that if I'm wrong, its because the time required to do secure
non-redundant secret splitting is as large as the time I'm saving.

JWS

have you considered

	des | tran | des | tran | des ?

> have you considered
> 
> 	des | tran | des | tran | des ?

My point is that you can get the same level of
security with much less effort/computation.

BTW, am I incorrect in my belief that the additional
security provided by the 32 bit shifting TRAN operation
suggested for the 3DEA hardly provides any additional
security? (i.e. if they could break 3 IDEA operations
or 3 DES operations, they can break them with
32 bit shifting TRAN operations interleaved in just
about the same amount of time.) It looks like it would
make meet-in-the middle attacks take up substantially
more memory and make identifying successful decryptions
slightly more difficult, but for security against nearly
brute force there isn't much difference between
2^(47) and 2^(47.2) operations. 

JWS