1995-11-17 - Security via Sounding Impressive

Header Data

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

Raw message

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





Thread