Re: Encryption key changing the encryption logic.

From: John E. Hadstate (jh113355_at_hotmail.com)
Date: 02/22/04 

Date: Sun, 22 Feb 2004 10:23:29 -0500

"Cesar Bremer Pinheiro" <cesarbremer@raseac.com.br> wrote in message
news:4c3656f.0402212001.3dca9455@posting.google.com...

> I have seen a lot of encryption algorithms, and all of
> them have in common the fact that the encryption algorithm is
> immutable, and the security is in the key.

> Is possible to develop a technique where
> the key could build part of the logic inside the encryption algorithm?

There is a subtle problem buried in this proposal. It implies a design
based on "security through obscurity."

Modern cryptography more or less plays by a set of rules known as
Kerckhoffs' Principles, one of which is, "compromise of the system should
not inconvenience the correspondents." This has commonly been interpreted
to mean that the crypto system itself is fully transparent and that all the
cipher security is carried in a secret key that can be changed easily.

If you adhere to these rules, then no matter how many different algorithms
your key selector can specify, they are all visible to the world. So, in a
sense, you have gained nothing. Part of your key chooses 1-of-N ciphers
(like a big "switch" statement) and the rest keys the cipher. Your
adversary knows which key bits select which algorithm and, in practice, N is
too small to add much strength.

Let's suppose we change gears slightly and consider the key to be a "tape"
or "program" of finite length. We feed this tape into an interpreter which
decides among various elementary crypto operations based on what it sees on
the tape. It seems likely that, just as with any other computer programming
language, this tape will be able to construct a large number of nonsensical
programs and a relatively small number of useful, secure programs. There
are two practical ramifications of this.

First, whoever builds the key (now a program) must be an expert
cryptographer. Keys will not be easy to generate. Second, the size of the
keys will greatly increase (because of all those nonsense combinations that
can't be used), making key exchange cumbersome.

Consider that the most optimum implementation of AES in a general-purpose
instruction set is probably between 1 and 8 K-bits and then compare that to
the 128 bits needed for a secure AES key. I think it's clear that the
key-as-cryptoalgorithm approach loses.

So what's left?

Relevant Pages

  • Re: Update on my Enc+Auth Mode
    ... > through the encryption algorithm (that has the effect ... in OCB he never proves that OCB is secure. ... under certain instances you reduce OCB to the security of the cipher. ...
    (sci.crypt)
  • Re: Password length and bit number of encryption algorithm?
    ... The password factor and the encryption algorithm choice factor are two ... somewhat independent security issues to consider. ... On the other side it will be pointless to use a robust password model ... that allow to use an huge keyspace if the encryption algorithm used is ...
    (sci.crypt)
  • Re: Password length and bit number of encryption algorithm?
    ... The password factor and the encryption algorithm choice factor are two ... somewhat independent security issues to consider. ... On the other side it will be pointless to use a robust password model ... that allow to use an huge keyspace if the encryption algorithm used is ...
    (sci.crypt)
  • Re: TEA security
    ... > How does TEA (Tiny Encryption Algorithm) hold up in terms of security? ... Lack of any sound theory and the design paper lacks test vectors. ...
    (sci.crypt)
Quantcast