On Fri, 2008-05-30 at 11:46 -0430, Patrick O'Callaghan wrote: > On Fri, 2008-05-30 at 13:04 +0930, Tim wrote: > > On Thu, 2008-05-29 at 15:23 -0500, Aaron Konstam wrote: > > > Let me share that to me the whole discussion of PGP signatures was > > > very unenlightening. I have no idea how to sign e-mail or validate a > > > pgp signed e-mail All the discussion seemed to me to be aimed at > > > people who knew all about this. > > > > Before you can make use of pgp in mail, you have to get pgp working. > > After you've made your own keys, the next thing you'll need is the other > > party's keys. You've got to be able to manage getting them in some way. > > > > *Then* you can move on to actually using them. Though there's probably > > a "understanding how the scheme works" process that you need to go > > through, first, judging by your comments. > > > > Start with the documentation, that's where most of the rest of us > > started, and you're less likely to get given a bum steer by it. > > It's a basic fact of life that crypto software is complicated for users, > and there appear to be fairly fundamental reasons why this is so (see > "Why Johnny Can't Encrypt", an interesting paper by a group of Stanford > researchers from a few years ago). You have to understand what a key is, > why it's not the same as a password, what it means to sign a message > etc. etc. Phil Zimmerman's book on PGP is a pretty good publication :-), > or just read one of the many online guides to get started. > > poc > There is no reason for crypto to be difficult. It is to the user a filter that requires a key. We tend to make it more difficult than it needs to be, where the truly difficult portion is understanding security. There are possible alternatives for that as well, but generally keys should only ever be handled by the folks dealing directly with the encrypted data, and the key used should be only known by those folks as well. That is the difficult part. But part of what makes the whole process obscure is the fact that everyone has differing views of what the proper handling of keys, and how and where to decrypt the data, and how to protect the machines doing the decryption. Moreover, it is the distribution of false beliefs that make otherwise secure systems insecure. Add to the issue is the problem of government monitoring of traffic, with the attendant need for them to be able to decrypt possible questionable transmissions. There are schemes that make encryption virtually unbreakable, but proving that is a bit difficult. There are also techniques that obscure the "real" data from bogus data, and systems that obscure senders and receivers, but these are indeed complex and probably beyond the scope of the simple encryption of email. Simply put, one could create a keylist, publish it someplace secure with limited access and limited time availability, communicate to the designated individual where and when, and the designated individual could use something like VPN to pick up the encrypted key list. The key to break that key list could be given over the phone. The result would certainly minimize exposure of the keys. Once the keys were installed in the designated machine, inline synchronous decryption of the keys and the communications could be virtually invisible to the user. The remaining issue would be machine security and how to handle output and input for security purposes. But those are somewhat separate questions of three types, one is physical security, one is emission security, and one is document handling. Each would need processes in place and understood by all users. The truly hard part of any secure system is the user understanding of how security applies to the actual information and the keys. And that is the most difficult part of all, but I wouldn't call it confusing, just really detail oriented. Regards, Les H -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
