> 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