🚀 go-pugleaf

In article <8801132010.AA15994@decwrl.dec.com> kruger@whyvax.dec.com (Hart for CCCP chief in '88) writes:
<Maybe someone can answer a question that's been bothering me for a while now.
<If you need an absolutely (provably) secure code, the key must be as long as
<the message. Even if it is not, a very short (and fairly random) datum will
<be hard to decode. So why not embed the real key in the message? ie, the
<external "key" is designed only to decrypt the randomly selected internal
<key, which is the one that decodes the real message. ....
<I am proposing a key of perhaps 128 bytes. ... Now, your 16
<byte key need only decrypt a patternless "plaintext" key. And the longer key
<can be used to make a much nastier encryption. Why isn't this done?

They problem is that a "secure" cipher according to current definitions,
requires that the message still be secure even if the encryption method is 
known! Under your technique, if I known the method all I have to do to crack
the message is start my computer rolling thru all possible 16 byte keys.
(hmm 256**16 = 3.4e38.... this may take a while!)

Your are also confusing the "rules" for substitution and transposition
ciphers with the more modern techniques. For the "old" ciphers, a key length
needs to be at least as long as the message (or the messages must be short).
You also need to change the key frequently. 

What matters with modern "bit-wise" encryption is not the key _length_ so
much as the size of the "key space". Your 16 byte key (did you _really_
mean byte? DES only uses _7_!!!) generates an ENORMOUS key space.

-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I used to be a hacker. Now I'm a 'microcomputer specialist'.
You know... I'd rather be a hacker."