From: szabo@netcom.com (Nick Szabo)
To: cypherpunks@toad.com
Message Hash: 46f746f9bff0e9804d532b42ce357391b6b74921068d6229c12eb0ff19f59f23
Message ID: <199511170351.TAA26249@netcom5.netcom.com>
Reply To: N/A
UTC Datetime: 1995-11-17 04:51:37 UTC
Raw Date: Fri, 17 Nov 1995 12:51:37 +0800
From: szabo@netcom.com (Nick Szabo)
Date: Fri, 17 Nov 1995 12:51:37 +0800
To: cypherpunks@toad.com
Subject: Security via Sounding Impressive
Message-ID: <199511170351.TAA26249@netcom5.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain
I've notice an interesting pattern in how security mechanisms are named.
On the one hand, we have some security features with very impressive sounding
names:
Certification *Authority*
*Authorization*
*Trusted* Server
*Master* Key
etc.
These words fill most people (many on this list are exceptions)
with awe and good will towards the feature so named. They also
make good channel markers, pointing out the _insecure_ parts
of the system. The effect is to cover up the lack or inadequecy
of a mechanism with invocations that put your brain to sleep. This
is quite lucrative for marketing purposes, but it works on
many designers of security features as well!
On the other hand, when we isolate the actual mechanisms of a system
are in fact mathematically secure, we get names like:
Encryption
Blinding
Message Digest
Mix
Capability
These are just plain, boring words, with no connotation that we should
trust them like we trust our big brother. They just work.
Nick Szabo szabo@netcom.com
Internet Commerce & Security consulting -- e-mail for details
Return to November 1995
Return to “szabo@netcom.com (Nick Szabo)”
1995-11-17 (Fri, 17 Nov 1995 12:51:37 +0800) - Security via Sounding Impressive - szabo@netcom.com (Nick Szabo)