Re: Encryption key changing the encryption logic.
From: John E. Hadstate (jh113355_at_hotmail.com)
Date: 02/25/04
- Next message: Richard Heathfield: "Re: anybody interested in math on Big Numbers"
- Previous message: Peter Fairbrother: "Re: double encyphering with an enigma"
- In reply to: John Savard: "Re: Encryption key changing the encryption logic."
- Next in thread: John Savard: "Re: Encryption key changing the encryption logic."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 25 Feb 2004 07:01:51 -0500
"John Savard" <jsavard@ecn.aSBLOKb.caNADA.invalid> wrote in message
news:403900a4.819170@news.ecn.ab.ca...
> On Sun, 22 Feb 2004 10:23:29 -0500, "John E. Hadstate"
> <jh113355@hotmail.com> wrote, in part:
> >"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.
>
> Yes, but if it's very important to you to win a fight, isn't it useful
> to consider fighting dirty?
I've got nothing against fighting dirty. Relying on "security by obscurity"
is just fighting drunk.
>
> (In other words, your post failed to explain, or even hint, _why_
> Kerchoff's dicta are useful to adhere to.)
Chalk it up to the fact that I have some respect for the intelligence of
some of those with whom I choose to correspond.
>
> >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.
>
> All that proves is this would be a bad way to implement the suggested
> principle.
Yep. But since the OP didn't get down to specifics, we're left to guess at
what he might have been thinking.
>
> <rearrangement>
Kind of destroys the connection between Kerckhoffs and what follows, don't
you think?
>
> >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 us suppose we _do_ adhere to this particular dictum of Kerchoff,
> because there are reasons for it.
>
> These reasons are:
>
> - it makes it possible to distribute an encryption program to others,
> who can judge the strength of its algorithm;
>
> - it makes it possible for the cryptographic community to pass
> judgement of the security of the algorithm, avoiding weaknesses by an
> error on the part of the designer;
>
> - it is the only realistic assumption, because code can be
> disassembled and so on and so forth.
>
> It still is not clear that "N is too small to add much strength".
How big do you envision "N": 8, 32, 128? Can you name 128 credible ciphers?
>
> You are making the error of adopting an either-or mentality here.
No, I'm trying to guess at the most likely possibilities given limited time,
something that you apparently couldn't or wouldn't do until I gave you
something to talk about.
> Either the key has to include a program for the algorithm, or it has
> to pick the algorithm from a short list of possibilities, such as 1)
> Rijndael, 2) Safer+, 3) CAST-256, et cetera.
>
> It is possible to make _part_ of the logic of a cipher variable, and
> still have an arrangement where every combination is strong. This has
> the advantage that attacks based on tracing a particular weakness in
> the round function consistently through the cipher become impossible.
> For example: let us think of a cipher with a 512-bit block size, and
> eight Feistel rounds.
>
> In each round, the F-function consists of either one (or two, if it
> has a Feistel structure) rounds of one block cipher, followed by one
> or two rounds of a different block cipher.
>
> And these pairs of block ciphers are chosen at random from 8
> possibilities. That gives N as being 56 to the 8th power, or
> 96,717,311,574,016, which adds more than 46 bits to the size of the
> key. The 8 choices for rounds are taken from 8 block ciphers known to
> be strong.
Sorry, this design is covered under the 1-of-N discussion and your design is
foolish. You can't possibly analyze the strength of 56**8 ciphers, the vast
majority of which are likely to be worthless.
> Also, using a key-dependent S-box makes N *enormously* large, and
> leads to a real change in the logic. (Of course, to have genuine
> changes in S-box structure, one usually has to risk a slight
> possibility of weak keys.)
>
A key dependent S-box doesn't change the algorithm at all. If the strength
of the algorithm depends solely on the construction of the S-box and the
S-box is key dependent, you've got a bad design.
- Next message: Richard Heathfield: "Re: anybody interested in math on Big Numbers"
- Previous message: Peter Fairbrother: "Re: double encyphering with an enigma"
- In reply to: John Savard: "Re: Encryption key changing the encryption logic."
- Next in thread: John Savard: "Re: Encryption key changing the encryption logic."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
