RE: PGP scripting...

From: Michael McKay (mmckayat_private)
Date: Tue Jan 28 2003 - 13:25:14 PST

  • Next message: NESTING, DAVID M (SBCSI): "RE: Can System() of Perl be bypassed?"

    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