[prev in list] [next in list] [prev in thread] [next in thread] 

List:       secprog
Subject:    RE: PGP scripting...
From:       "Michael McKay" <mmckay () iscubed ! com>
Date:       2003-01-28 21:25:14
[Download RAW message or body]

I'm actually glad to see this question about keeping the "public" key
secret, because too many people make the bad assumption that it is not
that important just because it is called "public" (there are other
considerations to this concept, but I don't have time to write a book). 

The first [obvious] reason for keeping it secret, is that if the
"public" key does not need to be exposed to the public, why not keep it
secret?  That just adds a layer of protection.

The second set of reasons is that sometimes a cryptographic protocol
dictates keeping the "public" secret; not just as a good idea, but as a
solid requirement.  This statement begs for an example, but I don't have
the time to provide one right now (I've seen it come up most often
during the initialization stage, always the messiest part of any
cryptographic protocol).  

Instead, here are some of the reasons a protocol may have this
requirement.  Some cryptographic protocols are designed to favor one
"end" over another.  For example compare the level of trust between a $2
smartcard carried around by 20 million people, and a FIPS-140 level 4
rated TRSM installed in a protected data center.  It makes sense to
design a protocol that shifts sensitive operations from the smartcard to
the data center's TRSM.  

Another reason protocols might have the "secret" requirement is
dependant upon key types.  Strong cryptographic protocols only use keys
for a single purpose, and indeed I've dealt with systems that delineate
10+ key types for a set of related operations.  The best known PKI Key
type concept is to separate signing and encryption operations into two
different key-pairs, but real world may actually many more specific
types.  

Think of a key type like a variable declaration in the C language, and
you won't be too far off.  You may also think of "restricted keys" (such
as a PKCS #11 key that only has permission to "decrypt digital
envelope") as a method key typing.  Key typing gives the ability to
exercise strong control over the cryptographic operations performed by
the system, and it is a vital part of a multi-function TRSM.  Once keys
have been separated into narrow uses, you can see how the ability or
need to keep the "public" key secret could occur more often. 

To summarize: there are indeed difference between symmetric-key
protocols, and asymmetric-key protocols where the "public" key is kept
secret.  It won't typically happen with a general purpose software
crypto design (for example, Windows using the same key for S/MIME, SSL,
IPSEC, and hard-drive encryption recovery).  It is more likely to occur
in a special purpose cryptographic protocol, with hardware-end-to-end
encryption and a need to protect against insider-fraud threats. 

Michael McKay
iS3 Software Director
mmckay@iscubed.com

-----Original Message-----
From: Andre Mariën [mailto:andre.marien@ubizen.com] 
Sent: Thursday, January 23, 2003 11:05 PM
To: jasonc@science.org
Cc: Glynn Clements; Beatie, Breck (ISSMountain View);
secprog@securityfocus.com
Subject: Re: PGP scripting...

It may be just me, but I am getting confused.
If we keep both private and public key secret,
why not use plain old symmetric cryptography?
We are talking about confidentiality I thought.
If we take it to non-repudiation there still are some merrits.

One of the things about public/private keys is,
well, the public key can be public.

-- André




[prev in list] [next in list] [prev in thread] [next in thread]