NPR : E-Mail Encryption Rare in Everyday Use

Ben Laurie wrote:
> I totally don't buy this distinction - in order to
write to you with
> postal mail, I first have to ask you for your address.

We all agree that having to use name and address are NOT the
problem,
for email or postal mail. Both can also deliver a letter
just with
the address ("CURRENT RESIDENT" junk mail, for
example).

The problem is that pesky public-key. A public-key such as

[2. application/pgp-keys]...


is N O T user-friendly.

Arguments that people give each other their cell phone
numbers, for example,
and even though there isn't a cell phone directory people
use cell phones
well, also forget the user's point of view when comparing a
phone number with
a public-key.

Finally, the properties of MY public-key will directly
affect the confidentiality
properties of YOUR envelope. For example, if (on purpose or
by force) my public-key
enables a covert channel (eg, weak key, key escrow, shared
private key), YOUR
envelope is compromised from the start and you have no way
of knowing it. This is
quite different from an address, which single purpose is to
route the communication.

That's I said the postal analogue of the public-key is the
envelope.

> Ed Gerck wrote:
>> My $0.02: If we want to make email encryption
viable (ie, user-level
>> viable)
>> then we should make sure that people who want to
read a secure
>> communication
>> should NOT have to do anything before receiving it.
Having to publish my
>> key
>> creates sender's hassle too ...to find the key.
> 
> So you think people can use the post to write to you
without you
> publishing your address?

I get junk mail all the time at two different postal
addresses, without ever
having published either of them. Again, addresses and names
are user friendly
(for better or for worse) while public-keys are not -- in
addition to their
different security roles (see above).

> Ed Gerck wrote:
>> BTW, users should NOT be trusted to handle keys,
much less to handle them
>> properly. This is what the users themselves are
saying and exemplifying in
>> 15 years of experiments.
> 
> I think users are perfectly capable of handling keys.
The problem they
> have is in choosing operating systems that are equal to
the task.

That's another notorious area where users can't be trusted
-- and that's why
companies lock down their OSes -- or, should a company
really allow each user
to choose their desired OS? Apart from compatibility issues,
which also do
not allow users to  freely choose even the OS in their homes
("Junior wants
to play his games too" scenario).

Cheers,
Ed Gerck

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

* Ed Gerck <edgercknma.com> [2006-02-25 13:11 -0800]:
> Finally, the properties of MY public-key will directly
affect the 
> confidentiality
> properties of YOUR envelope. For example, if (on
purpose or by force) my 
> public-key
> enables a covert channel (eg, weak key, key escrow,
shared private key), 
> YOUR
> envelope is compromised from the start and you have no
way of knowing it. 
> This is
> quite different from an address, which single purpose
is to route the 
> communication.
> 
> That's I said the postal analogue of the public-key is
the envelope.

I don't agree with that analogue. An paper envelope does
not prevent
anybody from opening it (you can open it without any tools
and with
nearly no effort). The encryption should make it impossible
for
anybody to see the contents.  The recipient might detect
that the
envelope was opened or replaced, but you must trust that he
will
detect this (you can't check it yourself).

Nicolas

-- 
http://www.rachinsky.
de/nicolas

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Ed Gerck wrote:
> Ben Laurie wrote:
> 
>> I totally don't buy this distinction - in order to
write to you with
>> postal mail, I first have to ask you for your
address.
> 
> 
> We all agree that having to use name and address are
NOT the problem,
> for email or postal mail. Both can also deliver a
letter just with
> the address ("CURRENT RESIDENT" junk mail,
for example).
> 
> The problem is that pesky public-key. A public-key such
as
> 
> [2. application/pgp-keys]...
> 
> 
> is N O T user-friendly.


True enough about public keys.  Not so true about key
fingerprints - a 
20-char fingerprint is probably not much harder to manage
than the usual 
sorts of contact info (email, postal, & IM addresses,
phone numbers, etc.).

Of course, a fingerprint won't let you encrypt an email
without 
supporting infrastructure for key lookups.  However, it
*will* let you 
authenticate a session (e.g., IM, VoIP, SSH) if your parter
presents his 
public key in the handshake.

Perhaps this is further support for Iang's contention that
we should 
expect newer, interactive protocols (IM, Skype, etc.) to
take the lead 
in communication security.  Email-style "message
encryption" may simply 
be a much harder problem.


Trevor

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

At 01:42 PM 2/26/2006, someone alleging to be Trevor Perrin
replied to some 
people
>>The problem is that pesky public-key. A public-key
such as
>>[2. application/pgp-keys]...
>>is N O T user-friendly.
>True enough about public keys.  Not so true about key
fingerprints - a 
>20-char fingerprint is probably not much harder to
manage than the usual 
>sorts of contact info (email, postal, & IM
addresses, phone numbers, etc.).

The short-fingerprint handle for long keys and the
troubles of fetching long keys conveniently and reliably are
a
major problem with PGP, S/MIME, and just about anything else
that uses RSA or El Gamal or other algorithms that require
long keys,
and therefore you need keyservers or other awkward
mechanisms
in addition to needing some validation technique for the
keys.

Elliptic Curve Crypto makes it possible to use keys that are
short enough to hand around like fingerprints -
print them on business cards, use them in email signature
lines, etc.
James Donald's Crypto Kong was an interesting experiment in
user interfaces for ECC crypto and in how users interact
with each other,
and while there were things I didn't like about it,
the encryption and signed-message formats were short and
sweet and unobtrusive,
and could be used just about as well for other user models.

The real question with ECC, other than patents, which don't
seem to
interfere too much right now and will gradually go away,
is how long the keys need to be, and how long they can be
trusted.
~~160-bit keys were short enough to be convenient.
256-bit is probably about the limit - I've seen some
discussion
of 512-bit keys, and at that point you're pushed into
message formats that make it inconvenient to exchange keys
again.
Is there a consensus view about what keylengths are
reliable?

                 Thanks; Bill Stewart


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On Sun, Feb 26, 2006 at 01:42:56PM -0800, Trevor Perrin
wrote:

> Perhaps this is further support for Iang's contention
that we should 
> expect newer, interactive protocols (IM, Skype, etc.)
to take the lead 
> in communication security.  Email-style "message
encryption" may simply 
> be a much harder problem.

This is neither surprising, nor relevant to email.

We are at this point reasonably good at encrypting unicast
traffic and
the associated key management problem is often viable.
Encrypting stored
data is a substantially more difficult problem.

We have increasingly common opportunistic TLS encryption of
email traffic,
with occasional fully verified secure-channels between some
pairs of
sites. We could conceivably some day (political barriers
primarily
at this point) have a secure DNS for secure MX record
lookups and key
distribution enabling secure channels between most sites.
This is viable,
traffic encryption is a tractable problem.

Encrypting email content, to be stored encrypted, and
decrypted when
read off-line, or read again later, ... is a problem that
the IM
and VoIP vendors don't have to solve. They also don't have
to solve
global federation of universally interoperable systems...

-- 

 /"\ ASCII RIBBON                  NOTICE: If
received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and
notify
  X AGAINST       IT Security,     sender. Sender does not
waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or
privilege,
                                   and use is prohibited.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

     --
Bill Stewart wrote:
 > The real question with ECC, other than patents, which
don't seem to
 > interfere too much right now and will gradually go
away, is how long
 > the keys need to be, and how long they can be trusted.
~~160-bit
 > keys were short enough to be convenient. 256-bit is
probably about
 > the limit - I've seen some discussion of 512-bit
keys, and at that
 > point you're pushed into message formats that make it
inconvenient
 > to exchange keys again. Is there a consensus view
about what
 > keylengths are reliable?

Except for special cases, breaking an n bit ECC system
involves
2^(n/2) EC operations, and EC operations are slow.

So 160 bits is sufficient, and 255 bits small enough to hand
the keys
around.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      p2QzZm1xG7xN9AVFcM1MUIw3KDIAp2MG0bf6c6UU
      4hqypUw7qHAIittFmiU/1gQOoNSxTS+vQdHdbb0nT

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com