Re: PGP signatures.


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

Relevant Pages

  • Re: Backup Security Black Hole
    ... If someone has physical access to the disk and the encryption keys are on the disk then they don't need to go through the indirect route of the backup files. ... If your data is sensitive enough that you need to encrypt it then you also have to think about things like physical security, security of backups, where the keys for encryption/decryption are stored, and probably more. ...
    (microsoft.public.windows.server.sbs)
  • Re: Best Practice for storing TripleDES key and vector?
    ... I might have a database record with many encrypted secrets (say HMACSHA1 keys). ... protecting access to the RSA private key credential .. ... It a security architect designer does not understand people, ... how to protect an encryption key ...
    (microsoft.public.dotnet.security)
  • Re: Secure WinNT based platforms from Knoppix
    ... clients to security awareness is the key. ... Windows 2000 / XP boot ... >Encryption is the only method I know of to defeat this. ... >As long as you back up your encryption keys, ...
    (microsoft.public.win2000.security)
  • Re: cannot access encrypted file, changing security ownership did
    ... Reading the remove encryption and backing up keys doesn't make sense ... How do I get these rotten keys and how do I use them if I should need them, ... I was worried that some hacker would get into my folder, ... norton security 2006 will not let me clean out my cookie ...
    (microsoft.public.windowsxp.security_admin)
  • RE: key storage
    ... finical, security, government or other high risk/high security ... for the encryption and decryption. ... If this is a window box (server) you can ... to protect your keys on disk and in memory. ...
    (Security-Basics)