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 mmckayat_private -----Original Message----- From: Andre Mariën [mailto:andre.marienat_private] Sent: Thursday, January 23, 2003 11:05 PM To: jasoncat_private Cc: Glynn Clements; Beatie, Breck (ISSMountain View); secprogat_private 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é
This archive was generated by hypermail 2b30 : Tue Jan 28 2003 - 14:20:57 PST