Re: PGP scripting...

From: lsi (stuartat_private)
Date: Wed Jan 08 2003 - 05:12:46 PST

  • Next message: Valdis.Kletnieksat_private: "Re: PGP scripting..."

    > Assuming a PGP encryption to itself is performed, then I agree. But
    > shouldn't it be possible to encrypt to a key which does not reside on
    > the encrypting computer? Once could leave only the recipients public key
    > and the batch process' private on this system and encrypt to the
    > recipient, then move the data out. At this point the data can not be
    > decrypted since we don't have the recipients secret key. Not having the
    > process' public key will prevent the encryption-to-self issue.
    > 
    > The data at its other location can then be decrypted with the recipients
    > secret keys and the encrypting process' public key.
    
    This may cover some bases at one end of the pipe.  However at the other end, the recipient must decrypt 
    using a secret key.  If this too is a batch process, then this secret key must be available programattically.
    
    Which is where the weakness is.  In a public-key system, the attacker would not attack the encrypting 
    computer, they would attack the decrypting computer.  In a private-key system either machine could be 
    attacked, suggesting that a public-key approach is less risky.
    
    > So once the data has been encrypted on that box, the statement "If the
    > system is compromised, they have all the data they
    > > need to get all the data." is not true since all they can get is the encrypted data.
    
    Yes - but only if they attacked the wrong machine.
    
    All of this depends on exactly what you're attempting to achieve.  Some applications might make it 
    infeasible to re-enter passwords on the receiving system (eg. if the decryption takes place many times a 
    minute, or at odd hours or inaccessible locations).  For these environments the private key and 
    passphrase must be available programattically.
    
    Other applications might allow encrypted files to accumulate on the receiving system, awaiting manual 
    passphrase entry and batch processing (if all files had same pw, pw only gets entered once).  This setup 
    would store the private key locally but the passphrase would be entered by a human.
    
    The matrix:
    
    ___________manual____batch__
    public-key  |   HIGH   |     MEDIUM
    private-key  |  MEDIUM  |     LOW
    
    high=high security, etc
    
    Conclusions: 
    
    In an automated private-key environment, security is low as each end stores keys and/or passphrases 
    locally.
    
    In an automated public-key environment, security is medium as one end stores keys and/or passphrases 
    locally.
    
    In semi-automated private-key environment, security is medium as each end stores keys locally and 
    passphrases are entered manually.  However if one end automates, security is medium-low.
    
    In semi-automated public-key environment, security is high as one end stores keys locally and 
    passphrases are entered manually.  The sender may automate and security remains high, however if the 
    receiver automates, security is medium.
    
    The bottom line:
    
    It is impossible to securely automate crypto.  Using specialised tamper-resistant hardware minimises risk, 
    but that pesky passphrase is still stored programmatically - it's just inside a black box with semi-
    proprietary I/O, hardware and algorithms.  If using a standard computer to decrypt, it must be protected via 
    additional mechanisms to minimise risk.  Semi-automated crypto is more secure - but then someone 
    needs to type a password somewhere.  Automated private-key approaches should not be used.
    
    Comments?
    
    Stuart
    -- 
    Stuart Udall
    stuartat_private - http://www.cyberdelix.net/
    ..revolution through evolution
    
    want to make some cash? check out http://cyberdelix.net/affiliates.htm
    



    This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 10:00:18 PST