Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Q: Kerchhoffs' principle

6 views
Skip to first unread message

Mok-Kong Shen

unread,
Jan 4, 2010, 4:50:09 PM1/4/10
to
The following question may be absolutely trivial, but I am anyway
confused at the moment and not sure of the answer.

Kerchhoffs' principle requires that one makes use of publicly-known
algorithms, if I don't err. Consider however the case where one employs
a combination of publicly-known algorithms, where the actual combination
depends (in an undisclosed way) at setup time on certain bits taken
from a secret key, with the rest of key being used for the individual
algorithms. Does one violate thereby Kerchhoffs' principle or not?

Thanks in advance,

M. K. Shen

amzoti

unread,
Jan 4, 2010, 5:16:42 PM1/4/10
to

1. Do you think he knew there would be agencies that specialize in
these areas and had and probably still have special skills and
resources over the general public?
2. Many of his principles can be extended to account for things today
- but know that some of those are outdated - like the one about
memorizing key material - no way Jose
3. Remember what era those were written in - and I am not saying they
are bad - for example - the public vetting process for things like
AES, hash algorithms and stream ciphers help the community at large.
Many wonderful cryptographers are in the university and private
companies and much progress has been made - but much is still not
known. Having people with special skills in these areas makes us all
aspire to be better at our craft.

Another recent example of this is the GSM break. Security is hard -
period!

When you don't spend the correct time, resources of have necessary
skills and build up the assurance - you likely failed.

Very few people - if any - actually know what the heck is secure -
heck, I am not even sure most people know how to properly pose the
question, understand the risks and understand the weakest link in
their designs.

Most stuff on the market today should be called privacy - because it
is certainly not security.

bert

unread,
Jan 4, 2010, 5:18:59 PM1/4/10
to

If knowledge of the undisclosed combination would
be of assistance to an attacker, then yes, such a
system would violate Kerchhoffs' principle.

Another view of his principle is that the minimum
amount of material should need to be kept secret.
The more there is to keep secret, the harder it is
to keep it secret, and the greater the change that
would need to be made to the system if some of the
secret material were to become known. On that view,
a system where only the key needs to be kept secret
is the best of all. It's not that the algorithm
ought to be publicly-known, just that obtaining
knowledge of it should be of no help to an enemy.
--

unruh

unread,
Jan 4, 2010, 6:01:53 PM1/4/10
to

If information could be found out, without knowing a key, they you
should assume that that information is public. Thus if you have a
cryptosystem which others can use, then you have to assume that your
enemy will have a copy as well. Since it is common to a whole bunch of
people, there is no way to ensure that it will not become comnon
knowledge to your enemy. If the thing is used only between you and the
one person you are communicating with, then it is fine to keep it
secret. Ie, Kerchoffs' principle means that you should assume that the
algorithm is public knowledge. That does not mean you cannot try to keep
it secret as an extra layer of protection but that should not for a part
of your security estimate.

Many algorithms work as you suggest-- the key itself determines which
transformation of the data are carried out, and in what order. You have
to assume that the attacker knows this, knows not only which of the
subalgorithms are used but also exactly how a key determines which
transfomation are carried out. All he does not know is the details of
the key itself.
Thus the selection criteria are public knowledge. Ie, "the combination
depends (in a known way) at setup time on certain bits taken from the
secret key" is what you have to assume. You may try to keep it secret,
but you will almost certainly fail, unless your algorithm is a "one off"
deal which is never reused for anyone else.

Joseph Ashwood

unread,
Jan 4, 2010, 9:27:18 PM1/4/10
to
"Mok-Kong Shen" <mok-ko...@t-online.de> wrote in message
news:hhtnqe$eud$00$1...@news.t-online.com...

> Kerchhoffs' principle requires that one makes use of publicly-known
> algorithms, if I don't err.

You do err, in the same way that most err is the application of Kerchhoff.
Kerchhoff's principal in question is that the level of security is not
affected by publication. In practice this means we publish our algorithms so
that others can catch our mistakes, the publication does nto affect the
security but it does improve our understanding of the security and so
affects our usage and improves our security in practice. It is always
important to realize that publication does not make something secure, just
as lack of publication does not make something secure.

To answer your further question, you'll want to take a look at "Cascade
Ciphers: The Importance of Being First" basically the combined system will
be at least as secure as the first cipher used.
Joe

Mok-Kong Shen

unread,
Jan 5, 2010, 9:04:15 AM1/5/10
to
amzoti wrote:
[snip]

> Most stuff on the market today should be called privacy - because it
> is certainly not security.

An average common user is certainly not in a position to know the "real"
quality of a security software. He has no choice but to rely on the
reputation of the producer and assume that nobody (e.g. at the shop)
has done any malicious manipulation on the particular piece he
acquires. BTW, the same is with OS. In the days of Intel's 8080/8086,
the OS was on a large plastic disk and many, who knew the assembler,
could read the entire OS of a PC much like reading a novel. Now with
Windows, where there are such things as automatic connection with
remote sites to download updates and their automatic installation and
with the myriad of virus, trojans (some such are rumored to even stem
from official sides) etc., the real experts, who knows what "exactly"
happens on his computer, are rare, unfortunately.

M. K. Shen

Mok-Kong Shen

unread,
Jan 5, 2010, 9:09:43 AM1/5/10
to
Joseph Ashwood:

> "Mok-Kong Shen" wrote:
>> Kerchhoffs' principle requires that one makes use of publicly-known
>> algorithms, if I don't err.
>
> You do err, in the same way that most err is the application of
> Kerchhoff. Kerchhoff's principal in question is that the level of
> security is not affected by publication. In practice this means we
> publish our algorithms so that others can catch our mistakes, the
> publication does nto affect the security but it does improve our
> understanding of the security and so affects our usage and improves our
> security in practice. It is always important to realize that publication
> does not make something secure, just as lack of publication does not
> make something secure.

So it does mean: (1) if one has one's own algorithm, one should publish
it (in order not to have the disadvantage of errors undetected), (2) if
one takes an algorithm from others, one should only take one that is
publicly-known. Taking both these together, it amount to the same as I
wrote above in my humble view.

> To answer your further question, you'll want to take a look at "Cascade
> Ciphers: The Importance of Being First" basically the combined system
> will be at least as secure as the first cipher used.

Even and Goldreich wrote in a paper that a cascade of cipher A with
cipher B is at least as hard to crack as any of its stages indivicually.
It is a stronger result than what you qouted in my view. BTW, it seems
that, except for loss of universal compatibility, one could have
certain (key dependent) permutations of round keys of block ciphers
like AES without adverse effects.

Thanks,

M. K. Shen

unruh

unread,
Jan 5, 2010, 1:05:57 PM1/5/10
to
On 2010-01-05, Mok-Kong Shen <mok-ko...@t-online.de> wrote:
> amzoti wrote:
> [snip]
>> Most stuff on the market today should be called privacy - because it
>> is certainly not security.
>
> An average common user is certainly not in a position to know the "real"
> quality of a security software. He has no choice but to rely on the

That is why insisting on open source security products is important.
Even if you cannot examine the code, someone can, and can report on the
problems. It makes the manufacturer more careful as well.

> reputation of the producer and assume that nobody (e.g. at the shop)
> has done any malicious manipulation on the particular piece he

Bad assumption. You should be able to test it. Whether you do or not is
up to you, but you should be able to.


> acquires. BTW, the same is with OS. In the days of Intel's 8080/8086,
> the OS was on a large plastic disk and many, who knew the assembler,
> could read the entire OS of a PC much like reading a novel. Now with
> Windows, where there are such things as automatic connection with
> remote sites to download updates and their automatic installation and
> with the myriad of virus, trojans (some such are rumored to even stem
> from official sides) etc., the real experts, who knows what "exactly"
> happens on his computer, are rare, unfortunately.

Which again argues for opensource OS as well. If something suspicious
comes up you can check.


>
> M. K. Shen

unruh

unread,
Jan 5, 2010, 1:14:08 PM1/5/10
to
On 2010-01-05, Mok-Kong Shen <mok-ko...@t-online.de> wrote:
> Joseph Ashwood:
>> "Mok-Kong Shen" wrote:
>>> Kerchhoffs' principle requires that one makes use of publicly-known
>>> algorithms, if I don't err.
>>
>> You do err, in the same way that most err is the application of
>> Kerchhoff. Kerchhoff's principal in question is that the level of
>> security is not affected by publication. In practice this means we
>> publish our algorithms so that others can catch our mistakes, the
>> publication does nto affect the security but it does improve our
>> understanding of the security and so affects our usage and improves our
>> security in practice. It is always important to realize that publication
>> does not make something secure, just as lack of publication does not
>> make something secure.
>
> So it does mean: (1) if one has one's own algorithm, one should publish
> it (in order not to have the disadvantage of errors undetected), (2) if
> one takes an algorithm from others, one should only take one that is
Yes, to both. However this is not Kerchoff's principle.

> publicly-known. Taking both these together, it amount to the same as I
> wrote above in my humble view.

No.

>
>> To answer your further question, you'll want to take a look at "Cascade
>> Ciphers: The Importance of Being First" basically the combined system
>> will be at least as secure as the first cipher used.
>
> Even and Goldreich wrote in a paper that a cascade of cipher A with
> cipher B is at least as hard to crack as any of its stages indivicually.

While this may be true in general, it is not true always. Consider
cypher A as DES, and cypher B as DES inverse. The combination is clearly
far less secure than either individually.

> It is a stronger result than what you qouted in my view. BTW, it seems
> that, except for loss of universal compatibility, one could have
> certain (key dependent) permutations of round keys of block ciphers
> like AES without adverse effects.

One could, or one could weaken it. It depends on what you do. But you
should assume that your opponent knows what you did. Ie, it does not
strengthen the cypher even in the best of cases.
And since your knowledge of crypto is not as good as the people who
designed AES, the chances that you unkowingly weaken it is relatively
high.

Secrecy of the cypher IS a form of security defense. But it should not
be relied on. IF you use your cypher only with one other person, it may
be a very good defense. If you use it with hundreds, it is a bad
defense, because someone will leak the details to your opponent-- by
accident or design.

>
> Thanks,
>
> M. K. Shen

Mok-Kong Shen

unread,
Jan 5, 2010, 4:03:51 PM1/5/10
to
unruh wrote:
[snip]

> Which again argues for opensource OS as well. If something suspicious
> comes up you can check.

I doubt that an average normal user is in a position (has the knowledge
and time) to check that a file of an opensource OS he downloaded from
somewhere is absolutely ok, in the sense of free from manipulations.
Similarly, he can't know whether a piece of hardware he acquires is ok.
Of course, the probability of bugs should be negligible in general, but
it might not be exactly zero under some rather unusual contexts (e.g.
where one or one's organization is the target for manipulations for
some reasons), I would surmise.

M. K. Shen

unruh

unread,
Jan 5, 2010, 4:08:10 PM1/5/10
to
On 2010-01-05, Mok-Kong Shen <mok-ko...@t-online.de> wrote:
> unruh wrote:
> [snip]
>> Which again argues for opensource OS as well. If something suspicious
>> comes up you can check.
>
> I doubt that an average normal user is in a position (has the knowledge

You did not read. Although that particular user might not be capable,
others are, and with opensource ANYONE can check.Because the manufacurer
knows this they are liable to be more careful to get everything right.

> and time) to check that a file of an opensource OS he downloaded from
> somewhere is absolutely ok, in the sense of free from manipulations.
> Similarly, he can't know whether a piece of hardware he acquires is ok.
> Of course, the probability of bugs should be negligible in general, but
> it might not be exactly zero under some rather unusual contexts (e.g.
> where one or one's organization is the target for manipulations for
> some reasons), I would surmise.

If one has an organization one is hardly "the average normal user" and
the chances taht someone can actually check is much much higher.

And you do not have to accept what is delivered, you can download from
elsewhere instead, and say, run diff to see what the differences are.
>
> M. K. Shen

WTShaw

unread,
Jan 6, 2010, 10:57:37 AM1/6/10
to
On Jan 5, 12:14 pm, unruh <un...@wormhole.physics.ubc.ca> wrote:

>
> Secrecy of the cypher IS a form of security defense. But it should not
> be relied on. IF you use your cypher only with one other person, it may
> be a very good defense. If you use it with hundreds, it is a bad
> defense, because someone will leak the details to your opponent-- by
> accident or design.
>

Which takes you back to the key(s), then there are two good rules:
1) Protect the source of the key so that even if you get it by hook or
crook any future keys are kept obscure.
2) Don't betray your key(s) with a from of encryption that utilizes
the whole key. It is better to use an algorithm that never uses key(s)
in a simpleton manner.

Got it? Protect sources. Protect methods; let's call that the Valerie
Protection Protocol

Mok-Kong Shen

unread,
Jan 6, 2010, 12:52:42 PM1/6/10
to
unruh wrote:

> And you do not have to accept what is delivered, you can download from
> elsewhere instead, and say, run diff to see what the differences are.

I certainly believe that opensource is extremely fine. My point is that
one should nonetheless not equate that to "perfectness". For otherwise
there wouldn't have been a need for a rigorously proved kernel
(according to a recent news there was such a task done, involving
considerable effort). Further, if my memory is right, one of the UNIX
creators after long years revealed a backdoor that was detected by
nobody else.

M. K. Shen

David Eather

unread,
Jan 6, 2010, 1:12:49 PM1/6/10
to

Who is Valerie?

What did they do in this field? (I'd just like to know - see, I know of
Kerchhoff and his principle so I know why he is worth listening to and
what he said - I would like to know the same about Valerie)

Mok-Kong Shen

unread,
Jan 6, 2010, 1:26:34 PM1/6/10
to
WTShaw wrote:

I think it would be fine to never "directly" use one's (master) key but
use it to derive keys for encrpting the individual messages through (1)
using it to encrypt time and message no. etc. with e.g. a block cipher
or (2) extending it with such data in case the cipher accepts keys of
variable length. One could also (hierachically) derive from a master
key sub-master keys for use in certain specific time periods (year,
month etc.) as a further measure to protect the master key. For a block
cipher, one could further use the message key in counter mode to
generate keys for actually encrypting the individual blocks to defeat
differential and algebraic analysis, as I recently suggested in another
thread.

M. K. Shen

David Eather

unread,
Jan 8, 2010, 11:29:27 AM1/8/10
to

It's not a hard question is it?

WTShaw

unread,
Jan 9, 2010, 5:57:27 PM1/9/10
to

Pardon me but the question is funny given that a lady named Valerie
was outed as a source for partisan reasons. The lesson is simple,
don't do the obvious that somebody else wants, especially nor for
really bad reasons like giving away the store. Some principles are
rather hefty in the importance sphere. I bet some folks got it first
time; Greetings.

Theo Markettos

unread,
Jan 15, 2010, 6:57:39 PM1/15/10
to
Mok-Kong Shen <mok-ko...@t-online.de> wrote:
> So it does mean: (1) if one has one's own algorithm, one should publish
> it (in order not to have the disadvantage of errors undetected), (2) if
> one takes an algorithm from others, one should only take one that is
> publicly-known. Taking both these together, it amount to the same as I
> wrote above in my humble view.

Look at it this way. A rough illustration:

Reverse engineering the cipher is an O(n) operation
Bruteforcing the cipher to determine the key is an O(x^n) operation

(Not necessarily the same 'n' in each case)

Once you've reverse engineered the cipher, that's valid for every instance
of that cipher. Once you've determined the key, that's valid for that
instance of the key only.

Pragmatically, publishing the cipher may not help you in detecting errors.
It only helps you if there are enough people listening who care enough to
cryptanalyse it and tell you the results. You might end up just helping
your adversary.

But if you intend to mass produce your cipher in any way, it will be reverse
engineered sooner or later. And you shouldn't just take a publically known
cipher, you should take one that has been well-analysed. Any fool can
publish a cipher, but it doesn't mean it's any good or any decent
cryptographer has looked at it. And if it hasn't been subjected to
plenty of scrutiny, it's sensible to assume that it's bad.

Theo

WTShaw

unread,
Jan 21, 2010, 12:25:32 AM1/21/10
to
On Jan 15, 5:57 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:

.
>
> But if you intend to mass produce your cipher in any way, it will be reverse
> engineered sooner or later.  And you shouldn't just take a publically known
> cipher, you should take one that has been well-analysed.  Any fool can
> publish a cipher, but it doesn't mean it's any good or any decent
> cryptographer has looked at it.  And if it hasn't been subjected to
> plenty of scrutiny, it's sensible to assume that it's bad.
>
> Theo

Good means well conceived, corrected until correct. It does not mean
that decent cryptographers are necessary, just good ones. Being
rather indecent is more fun, but we see lots of that here out of
contempt and/or boredom. The proof is in the pudding if it is not too
hasty. Frankly, describing a decent algorithm to an indecent model is
as effective as psychoanalysis in probing the mental content of the
subject if explained well to her and skillfully exposed in return.

Mass producing any cipher requires simple well placed proliferation
knowing that the ignorant masses can't tell the difference. Naughty
or nice, Sister Marie has explained before that goodness has nothing
to do with it...cryptic comments fore sure as you had to be there. To
be a good cryptographer means doing your best and not just guessing,
or guesting as the idiomatic case may be. Quoting and being quoted
are different stances be they not wide apart ones.

0 new messages