Usable encryption facilitates intuitive policy, rather than explicit per item encipher/decipher, sign/validate hassles

[coderman]

"I habitually send most of my email securely, but I don't think about
it. My robots take care of it for me. I tune policies, I don't encrypt
messages." - Jon

if you have to wrap the major key formats and uses into a single
bundle, so that a pre-generated user identity which contained keys in
formats applicable to any application the user might employ, what
would this bundle/list look like?

[let's avoid trust models and specifics of key utilization for a
higher level OS/application discussion.  for now i want to focus on
just what set of common types would serve the usual OS/application
needs in some form so that a single user/resource identity can be
created for use with lots of different "robots" further down the line
/ as needed. note that in many cases some of these keys would never be
used depending on the trust model employed and the applications
utilized.]

currently i'm aware of the following covering most bases but i know
i'm missing some:

- nonce/guid -> 512 bits of entropy from /dev/random (NOTE: when is
BSD going to turn /dev/random back into a true entropy source rather
than the deceptive alias for /dev/urandom?)

- gpg key pair ->  DSA and Elgamal, gpg --gen-key ...

- gpg key -> RSA sign only, gpg --gen-key ...

- shared encryption secret -> 256 bits of entropy from /dev/random

- shared auth secret -> 256 bits of entropy from /dev/random

- openssl root CA key -> openssl req -x509 -new -keyout ca.key -out ca.crt ...

- openssl dh parameters -> openssl dhparam ...

- openssl entity key (signed by root CA) -> openssl req ... && openssl ca ...

- ssh rsa key: ssh-keygen -t rsa ...

- ssh dsa key: ssh-keygen -t dsa ...

- ssh moduli: ssh-keygen -G ... && ssh-keygen -T ...

- off the record user state: otrl_userstate_create();


what else would you add to this list?



---cut---
http://www.mail-archive.com/cryptography@metzdowd.com/msg05822.html

Re: NPR : E-Mail Encryption Rare in Everyday Use

Jon Callas
Tue, 28 Feb 2006 11:45:54 -0800
I have to chime in on a number of points. I'll try to keep commercial
plugs to a minimum.

* An awful lot of this discussion is some combination of outdated and
true but irrelevant. For example, it is true that usability of all
computers is not what it could be. But a lot of what has cruised by
here is similar to someone saying, "Yes, usability is atrocious --
here, look at this screenshot of Windows 3.1." Someone else pipes up,
"You think that's bad, let me show you this example from the Xerox
Alto. What*ever* were they thinking?" And then someone else says,
"Yeah, and if you think that's bad, look at what 'ls' did in Unix V6!"
Then when someone else says, "Y'know, I'm using the latest version of
Firefox, and it's actually pretty good" the next message says, "But
what about the Y2K issues, and what happens when in 2038?" I swear,
guys, this thread is the crypto version of the Monty Python "Luxury"
sketch.

* Whitten and Tygar is a great paper, but it was written ages ago on
software that was released in 1997. Things aren't perfect now, but
let's talk about what's out there now. Even at the time, one of
Whitten's main points is how hard it is to apply usability to
security, because of how odd it is. As a very quick example, in most
forms of user design, you let exploration take a prominent place. But
it doesn't work in security because you can't click undo when you do
something you didn't intend.

* There are new generations of crypto software out there. I produce
the PGP products, and PGP Desktop and PGP Universal are automatic
systems that look up certs use them, automatically encrypt, and even
does both OpenPGP and S/MIME.

They're not perfect, and lead to other amusing issues. For example, an
hour ago, I was coordinating with someone that I'm meeting at a
conference. I got a reply saying, "I'm at the airport and can't
decrypt your message from my phone." I hadn't realized that I *had*
encrypted my message, because my system and my colleague's system had
been doing things for us.

I habitually send most of my email securely, but I don't think about
it. My robots take care of it for me. I tune policies, I don't encrypt
messages.

If you don't want to use my products, as Ben Laurie pointed out,
there's a very nice plugin for Thunderbird called Enigmail that makes
doing crypto painless.

* There are also new generations of keyservers out there that work on
the issues of the old servers to trim defunct keys, and manage other
issues. I have out there the PGP Global Directory. Think of it as a
mash-up of a keyserver along with Robot CA concepts and user
management goodness adapted from modern mailing list servers like
Mailman.

* A number of us are also re-thinking other concepts such as using
short-lived certificates based on the "freshness" model to constrain
lifecycle management issues.

* There are many challenges remaining. Heck, the fact that people here
apparently have not updated their knowledge any time this century is
part of the problem. But let me tell you that email encryption is
growing, and growing strongly. However, most of the successes are not
happening where you see them. They're happening in business, where
communities of partners decide they need to do secure email, and then
they do. This is another place where things have changed radically. A
decade ago, we thought that security would be a grass-roots phenomenon
where end-users and consumers would push security into those stodgy
businesses. What's happening now is the exact opposite -- savvy
businesses are putting together sophisticated security systems, and
that's slowly starting to get end-users to wake up.

I'd be happy to discuss at length where things are getting better,
where they aren't, and where some issues have been shuffled around.
But we do need to talk about what's going on now, not ten years ago.

        Jon
---end-cut---