🚀 go-pugleaf

In article <1ht56mINNbl3@transfer.stratus.com> cme@ellisun.sw.stratus.com (Carl Ellison) writes:
>It's the code using MD5 or exponentiation which would be the encryption
>code -- not the digest or exponentiation code itself.

Which is ironic, of course, considering that all of the cryptographic
strength of the resulting cipher would come from MD5, not the code
that turns it into a cipher. The latter is completely linear, so it
contributes nothing on its own.

This topic got discussed here over a year ago. At the time I think we
settled on a DES-inspired, "braided" Feistel structure that looked
like this:

Divide plaintext P into two halves, P1 and P2.

A = MD5(Key1,P1) XOR P2
C1 = MD5(Key2,A) XOR P1
C2 = MD5(Key3,C1) XOR A

Now concatenate to produce ciphertext C = C1,C2.  To decrypt, reverse
the steps:

A = MD5(Key3,C1) XOR C2
P1 = MD5(Key2,A) XOR C1
P2 = MD5(Key1,P1) XOR A

And P = P1,P2.

Note the use of three separate keys, one for each round. This is
important. (I think the formal proofs of this algorithm's security
require this.)  They can be generated from a single key by successive
MD5 hashing, if desired.  Also, the actual complete MD5 function need
not be used here; you could extract its internal "transform" function
and use it instead, as long as you're willing to use its internal
block sizes of 64 bytes in, 16 bytes out. In this case, the subkeys
would each be 48 bytes and P and C would be 32 bytes, which might be a
bit unwieldly for some applications.

Also, this algorithm won't be as fast as MD5 used for hashing. A
single turn of the MD5 "crank" crunches 64 bytes of input, but here
the encryption of 32 bytes of data requires three executions of MD5 --
6 times slower.

Phil