[santosha]

I see this line of argument very frequently - that if you are really secure, you should tell everyone how you do it, as some sort of gold standard for security. Kerchoff's principle suggests nothing of the sort - it is something of a thought experiment. When you design a system, you should ask yourself if it would still be secure if you told everyone how it worked. There is no real need to tell anyone, the obscurity adds an extra layer of defense.

Here's Steve Bellovin's thoughts on this:

'The subject of security through obscurity comes up frequently. I think a lot of the debate happens because people misunderstand the issue. It helps, I think, to go back to Kerckhoffs's second principle, translated as "The system must not require secrecy and can be stolen by the enemy without causing trouble," Kerckhoff said neither "publish everything" nor "keep everything secret"; rather, he said that the system should still be secure even if the enemy has a copy.

In other words – design your system assuming that your opponents know it in detail. (A former official at NSA's National Computer Security Center told me that the standard assumption there was that serial number 1 of any new device was delivered to the Kremlin.) After that, though, there's nothing wrong with trying to keep it secret – it's another hurdle factor the enemy has to overcome. (One obstacle the British ran into when attacking the German Enigma system was simple: they didn't know the unkeyed mapping between keyboard keys and the input to the rotor array.) But – don't rely on secrecy.'

[gabriel34]

You are right in this case. The only one who must be informed about how the system works is the client. In this case, the F1 team should know how is this security achieved, not the attackers or the general public.

On the other hand, if it is my information you are securing and if I don't have good reasons to trust you, I want to know how it is being done, even if that means attackers also know. If everyone is your client (for example, if you provide public services), then everyone must know, so they can independently audit the system.

Obscurity can be a layer of security in one system, made ,managed and audited by trusted entities, but, generally speaking, it is a weak layer for a attacker with a great enough motivation.

On the other hand, obscurity is detrimental to a collective of systems made, managed and audited (or not) by a great variety of entities. Sure, on the real world we place trust on companies to handle their security well, but that has ended badly in the past. The knee jerk reaction to security through obscurity we have is beneficial because it is a symptom of security issues in the system.

In conclusion, regarding obscurity, the beneficial effect of an extra security layer is only greater than the potential malefic effect of hiding security problems if the entities behind it, including the auditor, are competent and trustworthy. As a rule of thumb it should be avoided or have its bad side mitigated by independent security audits.

[FireBeyond]

Exactly. “Security through obscurity should be an _extra_ layer, not _the_ layer”.