[cryptography] real world illustrations of Kerckhoff's principle?

Marsh Ray marsh at extendedsubset.com
Thu Sep 9 13:37:27 EDT 2010

On 09/08/2010 06:35 PM, Ian G wrote:
> As a final footnote; why is K2 so misused? Why does everyone believe
> that Shannon's maxim means you must never use a secret algorithm?

I always figured there were a few reasons:

1. To ensure that the people designing, implementing, and operating the 
overall system have no excuse with which to rationalize poor practices 
in handling the key material.

Human nature and engineering pressures being what they are, it's highly 
probable that at some point in the design process an engineer will have 
in the back of his mind "it's just a minor issue and it's secret anyway 
so no one will figure it out". Or operations staff may think "we can 
just change the key, we needn't report its loss since the bad guys won't 
have the hardware to use it."

In theory it would seem like obscurity doesn't hurt security. In 
practice, it seems to be a negative pressure on quality.

2. It reflects reality. Either the system is too inconsequential to 
bother with or the reverse engineer wins in the end. Seriously, this 
kind of secrecy has failed pretty much every time it has been tried, 
even in hardware. E.g. the TPM chip:  http://extendedsubset.com/?p=19
"Tarnovsky’s examination process involved subtle use of hardware-based 
liquid chemical and gas technologies in a lab setting to probe with 
specialized needles to build tungsten bridges."

3. The security of the system components must depend only on those 
things which can be well-defined, or else the security of the overall 
system cannot be well-defined. The secrecy of an algorithm is 
notoriously difficult to characterize. So this principle is as much 
about compartmentalization as anything else, forcing a separation 
between the parts that can be formally reasoned about and those which 

It discourages the old "and then a miracle occurs"-type reasoning from 
being restated simply as "and the algorithm is secret".

I can think of four cases:

A. The secrecy of the algorithm is not a requirement for the secrecy of 
the system.

B. The algorithm is secret, then it must remain secret and be handled as 
a secret. Treating it as such is a lot of extra work. It's very 
difficult to keep a secret, particularly around networked computers. A 
requirement for algorithm secrecy greatly limits the possible 
applications. Good luck if you ever need to revoke it.

C. There are multiple defined areas of trust in the system and people 
trusted with the implementation are trusted differently than those with 
the messages. How the implementation exchanges messages with those who 
are trusted with them is a different problem, probably involving some 
other key and around we go. This obviously introduces a lot of 
complexity and probably isn't what is intended for most systems.

D. Security of the system isn't binary. Learning the algorithm is a 
security break, but only in some well-defined and limited way. For 
example, knowing the algorithm might let an attacker decrypt messages 
but not forge new valid ones. This decomposes into modeling two 
attackers, one who can know the algorithm and another who is presumed to 
not know it. Each sub-case now being one of A, B, C. (Or even D. Yes, 
why stop there? Perhaps you have an algorithm where the attacker may be 
expected to learn only some parts of it.)

So rather than stumbling into it, which of the above cases is 
appropriate for our design?

Let's rule out case D, that's just extra work. If you're prepared to 
show the system is only insecure in a limited way to an attacker who 
knows the algorithm, it's probably easier to just go ahead and deliver 
full security in all valid cases.

Case C simply isn't called for by most requirements, introducing it on 
its own would just be weird. Since it requires lots of extra 
interactions with other parts of the overall system to deploy securely, 
it won't be done properly if it's not a necessary part of the process.

In case B, anyone who has access to an implementation of the system can 
break the system. Knowledge of the algorithm is effectively a global 
master key. Why bother with a key at all then?

This typically leaves case A.

>> Can anyone help with pointers to particular cases?
> Skype: still secret today ...
"Reverse engineer extracts Skype crypto secret recipe - VoIP service 
mulls legal action"

> GSM: cracked in 1998, didn't worry it at all.
If what you're saying is that nobody cares about GSM security, it's not 
a relevant example.

> Netscape: 40 bit crypto crunched by a couple of bored students
> in 1997?, didn't slow down the web one iota.
The broken RNG thing? SSL depends on a source of good random numbers but 
it's a public algorithm.

> Suite A: so secret, we don't even know if it exists...
Perhaps it exists without anyone at all knowing.

> RC4: reverse engineered as ARC4, still in use,
> by Skype for example!

Like Skype, more evidence to support the idea that algorithms can be 
either secret or widely adopted, but not both.

> (*) Lucky Green extracted the algorithms from the GSM phone, took about
> 3 months of probing to extract all the bits out. Then, the same couple
> of bored students as in the Netscape hack, Dave Warner and Ian Goldberg,
> gave him a hand and cracked the algorithms "in a day" or so the media
> said at the time... Technically, not all of algorithms were cracked, but
> that's mostly irrelevant to the story.
> (&) The designated enemy for the GSM phone was twofold: papparazi
> listening to private calls (typically, secret affairs between notable
> people), and time-stealing by cloning the phone. Both of these
> disappeared completely with the GSM.

Last I saw, GSM security was defeatable with $1500 in hardware and an 
open source boot CD. Attacks against the negotiated ciphers meant that 
even transmissions intercepted in the past could be decrypted.

- Marsh

More information about the cryptography mailing list