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

[markus reichelt]

* Ian G <[EMAIL PROTECTED]> wrote:

> >So, why not always sign messages to a list that permits
> >signatures?
> 
> It's hard to see the benefit, and it is easy to see the potential
> cost.  In a litiguous world, we are (slightly) better off not using
> messages that are going to haunt us in years to come.  As a
> principle, I'd never advise anyone to sign any message unless they
> could state what that meant.

Well, I for one value the spreading of cryptographic means higher
than what might happen due to some misguided lawyer. with all the
lost privacy due to so-called protection laws from all the
"evildoers" this has only strengthened my resolve. after all, the
lawyers are still there even if one doesn't use cryptographic means.

In my world there's just too much lobbyism involved not to take
action in the vital field of privacy. Most people using electronic
communications either believe that some occasional eavesdropping is
ok (for they have nothing to hide; an arguement solely given by the
state in some 1984 manner), or they don't grasp the extent of
eavesdropping possibilities, or they just don't bother. not bothering
is just equally bad as giving in to the state because if one remains
passive, it is not likely that one will change one's perception
easily switching to actively propagate one's ideals (because of a
certain receptiveness to state arguements). and nowadays it's hard
enough to change things even if one is actively involved.


> It could well be that this is a difference in view across the
> Atlantic.  It seems that many (continental) Europeans do not
> perceive a threat to themselves from things they write; whereas the
> English-centric world is more "NDA" obsessed.

I guess you mean Non-Disclosure Agreement by NDA. All those acronyms;
it's about time the A takes action.

I haven't really perceived it the way you describe, but I don't work
in an environment where such things could matter at all. I'm in the
scientific community (chemistry), and there limits of talk (if you
get the meaning) are described pretty well, and this only affects
some areas of competition.

Given that some individual or even organisation keeps track of its
employees' writings in/on public media, I barely see the benefits
apart from some cases where it comes to leaking info which is already
prohibited by some kind of Non-Disclosure Agreement. those exist here
too, but with all the transparency about it, one really has to be
utterly stupid to mess things up.

From what you write I get the impression that even the slightest hint
about even the slightest clue may cause one harm. In my opinion this
fuels fear, just like telling a teenager not to ever fall in love
because he'll only get hurt anyway. we have misguided lawyers here
too, far too many of them in fact, for about over 20 years, and they
need to get an income. all that increased sueing stuff can be traced
back to the growing numbers of lawyers hitting the open market. not
that it offers a solution but there's still the bottom of the ocean
or the moon, and mars may be an issue soon...


> >Quite frankly, I wouldn't have thought this topic would emerge the
> >way it has on a cryptography mailinglist. Maybe it's about time to
> >publish my article "Why Cryptography Is Important In Modern Life"
> >after all (don't hold your breath; with me being pretty busy it's
> >not due until after eastern).
> 
> Cryptography is a tool, not a religion, notwithstanding the desires
> of many to deify it.  It is the application that delivers benefits,
> and properly thought out apps generally use as little crypto as
> they can get away with.  Top-down applications thinking says "use
> the tool that does the job" whereas bottom-up, toolbox thinking
> says "use this tool because it's so cool!"

I guess you got me wrong, and I'm not sure I get your top-down,
bottom-up analogies. Anyway, I'm not propagating means of
cryptography because of a religious hype or something. to clarify
this, me and my friends are not amused by officials having the legal
means to listen in on email communications, phone conversations, etc.
both without prior suspicion and some kind of notification of the
person(s) being listened in to, let alone legal backup (it was
rendered redundant anyway). because of the terrorist-threat-hype such
processes are now accelerated to fit only the state's benefits, yet
they sold as a citizen's benefit altogether. we have a saying here (i
hope it carries over, i'm not a native english speaker): working at
such a hectic pace replaces an intellectual calm.

From what I wrote above I guess it can be boiled down to this. Means
of cryptography are valued because of the possibility to protect
one's privacy that the state obviously has deemed unnecessary, for
good citizens surely don't have something to hide. simply put, since
we all don't walk the street naked, the state always wins. such a
state is out of balance, and checks are most likely still in place
where they possibly can'

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

[Peter Saint-Andre]

Ian G wrote:
> Chris Palmer wrote:
>> Peter Saint-Andre writes:
>>
>>> http://www.saint-andre.com/blog/2006-02.html#2006-02-27T22:13
>>
>> 3. I see on your site you use and advertise for CACert. I hope CACert's
>> signing cert(s) are never trusted by my browser, because then my browser
>> would trust any cheap-ass random pseudonym in the world. 

IMHO trust is something you do, not something your browser does. Unless
you're going to delegate trust to the browser manufacturers...

>> Which brings us
>> to my next point...
> 
> You are probably talking about the Class 1 root
> that CAcert uses to issue pseudonymous certs.
> Yes, they can be acquired by any cheap-ass
> psuedonym (but not randomly, as I think there is
> a serial number in there which I was told was
> an unavoidable artifact of x.509).
> 
> Over on Peter's blog it seems to indicate he is
> an Assurer ... assuming that is correct [it isn't
> a cryptographically sound image :) ] then this
> means he is at least "assured" which is their
> term for his identity having been verified.

In CAcert, assurance is an action. You show me two government-issued
photo IDs (GIPIDs) and I compare them with your visage and physical
person; if I think they match, I "assure" you for some number of points
in the web of trust. If you get to a certain number of points, you can
use the Class 3 root. If you get even more points, you can become an
assurer (someone who does assurances). I happened to use the "trusted
third party" process for assurance (get copies of my GIPIDs witnessed
and notarized by two persons who are legally authorized in my
jurisdiction to witness and notarize documents), which results in more
points initially and the ability to become an assurer more quickly.

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Victor Duchovni]

On Fri, Mar 10, 2006 at 08:09:56AM +1000, James A. Donald wrote:

> These days you see
> little spam on most Usenet groups, and one of the primary uses of
> Usenet is ad hoc communication between strangers.

The federation mechanism in Usenet is explicit host peering. While the
posters may be strangers to the readers, they are not able to unicast
their content to arbitrary strangers. Joe Consumer does not use Usenet,
they use email and perhaps Yahoo groups. Moderators of groups and
server administrators can block or cancel spam posts. There is no useful
analogy here.

The federation mechanism for email is DNS MX records. Email is ubiquitous,
you don't need to peer with UUnet. When Jabber is ubiquitous (i.e. every
domain with Jabber users has a Jabber SRV record and peering is direct)
it will have more spam.

> SSL works fine, PKI has serious problems. Usenet for the most part
> works fine, Jabber works fine, email has serious problems

The problem with email is that it is more useful and more ubiquitous, and
therefore a more attractive target. Security protocols, authentication,
and so forth, should help to identify wanted email and perhaps make
tracing abuse easier, but the fundamental problem is that among the
billions of people from whom you potentially want to be able to receive
email, there are a few hundred sociopaths.

It is IMHO naive to claim that email would not have a serious spam problem
if only it were designed now rather than in a kinder, gentler past. It is
in the nature of an always on, universally addressable service that it is
open for abuse. The problem is compounded by the presence of millions of
unsecured broadband consumer-operated machines.

It is not just that deploying a more modern email infrastructure is
complex. I have not seen any designs for email (deployable or not)
that realistically curtail abuse.

> The federated structure of jabber, where random people connect to any
> one of a very large number of privileged servers is similar to the
> Usenet structure - and the Usenet structure works because for your
> server to retain your privileges, you need to control spam.

And correspondingly the utility and ubiquity of the service are limited.
Are you proposing a fendced-in network of privileged email servers?

> > I am willing to speculate that people will continue to unfairly
> > tarnish the competence of the email RFC writers, without regard to
> > the intrinsic properties of the medium.
> 
> It is not so much that they were incompetent, but that they were
> writing for a more trusting and trustworthy world.  Today, we have to
> do things differently.

Well, this is a popular viewpoint, but I suggest that it misses the
*intrinsic* difficulty of the problem.

-- 

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[James A. Donald]

--
Victor Duchovni wrote:
> My claim is that, while indeed it is easier to set the initial
> barriers higher when you design with greater hindsight, and some of
> the tractable, but not widely deployed email security measures will
> be there in IM systems from the start, never the less IM systems if
> they are to encroach on the ubiquity of email for ad-hoc
> communications between strangers (it is far easier to address
> strangers via email today) will encounter exactly the same intrinsic
> issues, and that technical measures will have equally partial
> efficacy.

Total perfect and complete solutions will never be possible, but
stopping the most flagrant and inconvenient abuses is perfectly
feasible, and not even remarkably difficult.  These days you see
little spam on most Usenet groups, and one of the primary uses of
Usenet is ad hoc communication between strangers.

SSL works fine, PKI has serious problems. Usenet for the most part
works fine, Jabber works fine, email has serious problems

The federated structure of jabber, where random people connect to any
one of a very large number of privileged servers is similar to the
Usenet structure - and the Usenet structure works because for your
server to retain your privileges, you need to control spam.

> I am willing to speculate that people will continue to unfairly
> tarnish the competence of the email RFC writers, without regard to
> the intrinsic properties of the medium.

It is not so much that they were incompetent, but that they were
writing for a more trusting and trustworthy world.  Today, we have to
do things differently.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 PRRq2Za8iG5qzD2wX3ug3xGXEWyekUqHQTZAspUQ
 4Mjw8nFOqtf9erylBgQZo+5aUTVPzgKVdij0TQUDs

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Chris Palmer]

Peter Saint-Andre writes:

> http://www.saint-andre.com/blog/2006-02.html#2006-02-27T22:13

1. Anonymity does matter. You might have heard of a little thing called
the First Amendment. ;) It's great that you're proud of what you say,
but no matter how proud you are, there could be bad, unfair consequences
if you say certain things and/or if you have a certain identity. A
little wisely-used anonymity can further an honest debate (such as
debating what should be in the Constitution!) and protect people from
low-power groups.

2. Email signing, alone, gives you only pseudonymity.

3. I see on your site you use and advertise for CACert. I hope CACert's
signing cert(s) are never trusted by my browser, because then my browser
would trust any cheap-ass random pseudonym in the world. Which brings us
to my next point...

4. Identity is not, and can never be, a substitute for a real judgement
about goodness. That I sign my messages doesn't make them any smarter;
many good and helpful comments come from such forgeable identities as
"Steven Bellovin" and "Ben Laurie". Even fake names that look
ridiculously fake, like "StealthMonger", sometimes send useful
information. When you "immediately discount what that person says", you
are doing yourself an unfavor.


-- 
https://www.eff.org/about/staff/#chris_palmer



pgp3QSxLKKGry.pgp
Description: PGP signature

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

[Victor Duchovni]

On Wed, Mar 08, 2006 at 01:55:16PM -0700, Peter Saint-Andre wrote:

> I never made the strong claim that the federated Jabber network is or
> always will remain spam free, only the weaker claim that its abuse and
> identity problems are and will remain less serious than those of the
> federated email network as it exists today.

Time will tell. All I expect from the ultimate (~3 years out) rollout
of email authentication is less backscatter, not less phishing or
spam.

> I do not dispute that if Jabber becomes popular enough, there
> will be rogue servers that don't enforce local authentication (although
> with server dialback and TLS they can't fake from addresses at other
> domains, see RFC 3920), and that those who deploy Jabber services will
> need to blacklist those domains.

Of course new domains are less than $4 each in bulk... How will you
lock out throw-away domains? The black-list problem for email is not
solved. The good lists are nowhere near 100% effective. Is the equivalent
of port 25 blocking tractable for Jabber? Is there a difference between
the user-to-server port/protocol and the server-to-server port/protocol
in Jabber?

> I do not dispute that there will be
> spam bots and that server admins or end users will need to block
> communication with those bots (e.g., using the privacy list protocol
> defined in RFC 3921). I do not dispute that there will be phishing
> attacks (e.g., using internationalized addresses that look like but are
> not identical to familiar addresses) and that client software will need
> to take appropriate measures to differentiate between legitimate and
> mimicked addresses (e.g., using petname systems as described in
> JEP-0165).

Yes petname systems are an important UI tool for preserving the integrity
of existing peer communications. If IM is to "replace" email as some
want to claim, it needs to support messages from a fair share of total
strangers (we have never met).

> All I'm saying is that we have a lot of the infrastructure in
> place (and are building more) to make abuse harder and identity stronger
> than it is on the existing email network. Is Jabber perfect? No. We're
> just trying to make it good enough that the bad guys will go elsewhere
> (which, so far, they have).

My claim is that, while indeed it is easier to set the initial barriers
higher when you design with greater hindsight, and some of the tractable,
but not widely deployed email security measures will be there in IM
systems from the start, never the less IM systems if they are to encroach
on the ubiquity of email for ad-hoc communications between strangers
(it is far easier to address strangers via email today) will encounter
exactly the same intrinsic issues, and that technical measures will have
equally partial efficacy.

I am willing to speculate that the more likely scenario is that IM will
not become the ubiquitous medium that email is, and will escape the
problem by avoiding scope creep.

I am willing to speculate that people will continue to unfairly tarnish
the competence of the email RFC writers, without regard to the intrinsic
properties of the medium.

-- 

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Peter Saint-Andre]

Victor Duchovni wrote:
> On Wed, Mar 08, 2006 at 12:53:16PM -0700, Peter Saint-Andre wrote:
> 
>>> These are closed systems that compete with each other, once
>>> they become federated, they can no longer compete on end-to-end
>>> security, because that is a property of the interoperability
>>> framework, not the individual product. Also with millions
>>> of account issuers, the abuse and identity problems become
>>> just as bad as for email. The problem is intrinsic, is not
>>> the result of lazy RFC writers.
>> Well, in the Jabber/XMPP world we require authentication, servers must
>> stamp the from addresses, and we use (at a minimum) reverse DNS lookups
>> to verify server identities (or use certs with TLS + SASL-EXTERNAL if
>> you want true server-to-server authentication). So I'd say the abuse and
>> identity problems are not as bad in IM (at least the IM technology I'm
>> familiar with) as in email. But you'd hope that we've learned a thing or
>> two since email was invented. ;-)
> 
> What is the value of such "authentication"? Which organizations will you
> trust? For example, most mail that passes SPF is spam... Authentication
> by the issuing organization is only useful, if you can keep bad issuers
> of the net... If federated Jabber becomes universal, the bad guys cannot
> be excised from the network. The botnets cannot be excised from the network,
> ...
> 
> The problem is technology neutral. Loosely along the lines of Goedel's
> incompleteness theorem, any universally deployed federated communications
> medium will exhibit spam.

I never made the strong claim that the federated Jabber network is or
always will remain spam free, only the weaker claim that its abuse and
identity problems are and will remain less serious than those of the
federated email network as it exists today. There is no magic bullet,
and a spam-free utopia is not an option if federated communications are
desired. I do not dispute that if Jabber becomes popular enough, there
will be rogue servers that don't enforce local authentication (although
with server dialback and TLS they can't fake from addresses at other
domains, see RFC 3920), and that those who deploy Jabber services will
need to blacklist those domains. I do not dispute that there will be
spam bots and that server admins or end users will need to block
communication with those bots (e.g., using the privacy list protocol
defined in RFC 3921). I do not dispute that there will be phishing
attacks (e.g., using internationalized addresses that look like but are
not identical to familiar addresses) and that client software will need
to take appropriate measures to differentiate between legitimate and
mimicked addresses (e.g., using petname systems as described in
JEP-0165). All I'm saying is that we have a lot of the infrastructure in
place (and are building more) to make abuse harder and identity stronger
than it is on the existing email network. Is Jabber perfect? No. We're
just trying to make it good enough that the bad guys will go elsewhere
(which, so far, they have).

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Victor Duchovni]

On Wed, Mar 08, 2006 at 12:53:16PM -0700, Peter Saint-Andre wrote:

> > These are closed systems that compete with each other, once
> > they become federated, they can no longer compete on end-to-end
> > security, because that is a property of the interoperability
> > framework, not the individual product. Also with millions
> > of account issuers, the abuse and identity problems become
> > just as bad as for email. The problem is intrinsic, is not
> > the result of lazy RFC writers.
> 
> Well, in the Jabber/XMPP world we require authentication, servers must
> stamp the from addresses, and we use (at a minimum) reverse DNS lookups
> to verify server identities (or use certs with TLS + SASL-EXTERNAL if
> you want true server-to-server authentication). So I'd say the abuse and
> identity problems are not as bad in IM (at least the IM technology I'm
> familiar with) as in email. But you'd hope that we've learned a thing or
> two since email was invented. ;-)

What is the value of such "authentication"? Which organizations will you
trust? For example, most mail that passes SPF is spam... Authentication
by the issuing organization is only useful, if you can keep bad issuers
of the net... If federated Jabber becomes universal, the bad guys cannot
be excised from the network. The botnets cannot be excised from the network,
...

The problem is technology neutral. Loosely along the lines of Goedel's
incompleteness theorem, any universally deployed federated communications
medium will exhibit spam.

Either it is not mature enough, or it has spam.

-- 

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Peter Saint-Andre]

Anton Stiglic wrote:
>> More strongly, if we've never met, and you are not in the habit of
>> routinely signing email, thereby tying a key to your e-persona, it
>> makes no sense to speak of *secure* communication to *you*. 
> 
> Regularly signing email is not necessarily a good idea.  I like to be able
> to repudiate most emails I send...

As previously mentioned, anonymity and repudiability aren't high on my
list of values -- not that anyone cares about my hierarchy of values ;-)

But as promised I did blog about it:

http://www.saint-andre.com/blog/2006-02.html#2006-02-27T22:13

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Peter Saint-Andre]

Victor Duchovni wrote:
> On Wed, Mar 01, 2006 at 06:15:36PM +0100, Ian G wrote:
> 
 Email is hard to get encrypted, but it didn't stop Skype from doing
 encryped IMs "easily."
>>>
>>> Likewise I have secured email communications with my wife via a single
>>> key exchange, so what? Skype has not "easily" created an interoperable
>>> federated system that secures all IM communications end-to-end, and
>>> many of the issues in doing that are non-technical.
>>
>> Right.  Nor did email create a single federated
>> system that crosses across to mobile phones.  There
>> is always a boundary where a system stops.
> 
> Federated accross millions of account issuing organizations, not
> technologies, and email did do that, and IM did not. IM is like email from
> a choice MCI, Sprint or AT&T, sure they can control the medium better,
> but this is a temporary state of affairs...

Monolithic consumer IM services (AIM, MSN, Yahoo, etc. are like that.
Existing federated IM standards (e.g., Jabber/XMPP) are not.

>> The point is that the non-technical issues we
>> are looking at here are *better* handled at the
>> level of competitive systems, because they have
>> incentives to solve them, whereas technical
>> committees writing RFCs do not.
> 
> These are closed systems that compete with each other, once
> they become federated, they can no longer compete on end-to-end
> security, because that is a property of the interoperability
> framework, not the individual product. Also with millions
> of account issuers, the abuse and identity problems become
> just as bad as for email. The problem is intrinsic, is not
> the result of lazy RFC writers.

Well, in the Jabber/XMPP world we require authentication, servers must
stamp the from addresses, and we use (at a minimum) reverse DNS lookups
to verify server identities (or use certs with TLS + SASL-EXTERNAL if
you want true server-to-server authentication). So I'd say the abuse and
identity problems are not as bad in IM (at least the IM technology I'm
familiar with) as in email. But you'd hope that we've learned a thing or
two since email was invented. ;-)

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Ben Laurie]

Alex Alten wrote:
> At 05:58 AM 3/3/2006 +, Ben Laurie wrote:
>> [EMAIL PROTECTED] wrote:
>> >> [EMAIL PROTECTED] wrote:
>>  Alex Alten wrote:
>> > At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
>> >> Alex Alten wrote:
>> >>> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
>>  Ed Gerck wrote: We have keyservers for this (my chosen
>>  technology was PGP). If you liken their use to looking up an
>>  address in an address book, this isn't hard for users to grasp.
>> 
>> >>> I used PGP (Enterprise edition?) to encrypt my work emails to
>> >>> a distributed set of members last year.  We all had each
>> >>> other's
>> >>> public keys (about a dozen or so).
>> >>>
>> >>> What I really hated about it was that when [EMAIL PROTECTED] sent
>> >>> me an email often I couldn't decrypt it.  Why?  Because his
>> >>> firm's email server decided to put in the FROM field
>> >>> "[EMAIL PROTECTED]". Since it didn't match the email name
>> >>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
>> >>> attachment. This also caused problems with replying to his email.
>> >>> It took us hours, with several experimental emails sent back and
>> >>> forth, to figure out the root of the problem.
>> >>>
>> >>> No wonder PKI has died commercially and encrypted email is on the
>> >>>  endangered species list.
>> >> I trust you don't think this is a problem with PKI, right? Since
>> >> clearly the issue is with the s/w you were using.
>> > I place the blame squarely on X.509 PKI.  The identity aspect of it
>> > is all screwed up. No software implementation can overcome such a
>> > fundamental architectural flaw.
>>  OK - I'll bite - why does the sender's identity have any impact
>> on the
>>  recipient's ability to decrypt?
>> 
>> >>> Because the software needs a unique ID/name to find the correct
>> >>> key to use. In practice (corporate) users can have multiple email
>> >>> names, see my reply to Peter Gutman.  This is not the fault of
>> >>> the email architecture, which has been working fine for 30-40
>> >>> years, but the fault
>> >>> of the X.509 architecture trying to piggyback on an address/name
>> >>> space that is not designed with security/cryptography
>> >>> considerations in mind.
>> >> I have to admit to not being familiar with S/MIME, but the usual
>> >> practice is to identify the signing key in the signature. Certainly
>> this
>> >> is what OpenPGP does. Its also kinda weird to refuse to decrypt just
>> >> because the signature can't be verified.
>> >>
>> >
>> > How does OpenPGP identify the signing key in the incoming email's
>> signature?
>>
>> Here's the output of one of the example programs in OpenPGP:SDK
>> (http://openpgp.nominet.org.uk/), showing the structure of an OpenPGP
>> signed file. I trust it is self-explanatory.
> 
> Assuming this file is attached to an incoming email message, how does the
> receiver's email software match the Signer ID (= 0x8337FE6485F4ED64) to
> a X.509 cert in his local cache that is associated with the email
> sender's name
> (= "[EMAIL PROTECTED]")?

It is _OpenPGP_ so it does not match it to an X.509 cert. It matches it
to an OpenPGP key.

-- 
http://www.links.org/

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Peter Gutmann]

Alex Alten <[EMAIL PROTECTED]> writes:
>At 03:13 AM 3/6/2006 +1300, Peter Gutmann wrote:
>> >Basically our customer required us to encrypt any team communications. So we
>> >used PGP with email.  I know the body of the email was encrypted, and I
>> >believe attachments were too.  The certs were used to "automate" the
>> >decryption.  Basically the PGP plugin would check the incoming mail's sender
>> >email name and try to find a local cert that had the same email name in it.
>>
>>Hmm, that sounds like broken software then, since the (probabilistically)
>>unique keyID to locate the appropriate decryption or signature verification
>>key is included in the message/signature - you never have to look at the From:
>>address, and indeed trying to use it for key lookups would be a recipe for
>>disaster because of the problems you pointed out.
>
>RFC 3280 states that an end entity's subject key id SHOULD be included. It is
>not a MANDATORY extension field, see section 4.2.1.2.  So the software is not
>technically broken.

Uhh, what does RFC 3280 have to do with PGP, which is what you said you were
using?  In any case if you are using X.509 certs, you match by subject DN (or
issuerAndSerialNumber for S/MIME), all of which serve the same function as the
PGP key ID.

>Since the key id is derived from the raw public key itself,  doesn't that
>defeat the purpose of automatically authenticating that the encrypted email
>is really from "[EMAIL PROTECTED]"?

You use the PGP keyID or X.509 issuerAndSerialNumber to look up the key or
certificate, then display as the signer the identity associated with the key
or certificate.  What's in the "From:" address never enters into it, although
your software may choose to warn if the From: address doesn't match the email
address associated with the key.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Alex Alten]

At 03:13 AM 3/6/2006 +1300, Peter Gutmann wrote:


>Basically our customer required us to encrypt any team communications. So we
>used PGP with email.  I know the body of the email was encrypted, and I
>believe attachments were too.  The certs were used to "automate" the
>decryption.  Basically the PGP plugin would check the incoming mail's sender
>email name and try to find a local cert that had the same email name in it.

Hmm, that sounds like broken software then, since the (probabilistically)
unique keyID to locate the appropriate decryption or signature verification
key is included in the message/signature - you never have to look at the From:
address, and indeed trying to use it for key lookups would be a recipe for
disaster because of the problems you pointed out.


RFC 3280 states that an end entity's subject key id SHOULD be included. It is
not a MANDATORY extension field, see section 4.2.1.2.  So the software is
not technically broken.

Since the key id is derived from the raw public key itself,  doesn't that 
defeat

the purpose of automatically authenticating that the encrypted email is really
from "[EMAIL PROTECTED]"?  I'm assuming a naive email user on the receiver
side that never manually maps the key id to "[EMAIL PROTECTED]".  Most
general users sort of understand the email name format, it's a bit much to 
force
them to map a cryptic looking key id to it too.  Especially considering the 
user
might have dozens or hundreds of people on their mailing list.  Mapping 
mistakes

would be common.

I won't mention the questions regarding certificate revocaton vs user email 
name.

:-)

- Alex


--

- Alex Alten


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Peter Gutmann]

Hi,

>Basically our customer required us to encrypt any team communications. So we
>used PGP with email.  I know the body of the email was encrypted, and I
>believe attachments were too.  The certs were used to "automate" the
>decryption.  Basically the PGP plugin would check the incoming mail's sender
>email name and try to find a local cert that had the same email name in it.

Hmm, that sounds like broken software then, since the (probabilistically)
unique keyID to locate the appropriate decryption or signature verification
key is included in the message/signature - you never have to look at the From:
address, and indeed trying to use it for key lookups would be a recipe for
disaster because of the problems you pointed out.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Alex Alten]

At 05:58 AM 3/3/2006 +, Ben Laurie wrote:

[EMAIL PROTECTED] wrote:
>> [EMAIL PROTECTED] wrote:
 Alex Alten wrote:
> At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
>> Alex Alten wrote:
>>> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
 Ed Gerck wrote: We have keyservers for this (my chosen
 technology was PGP). If you liken their use to looking up an
 address in an address book, this isn't hard for users to grasp.

>>> I used PGP (Enterprise edition?) to encrypt my work emails to
>>> a distributed set of members last year.  We all had each
>>> other's
>>> public keys (about a dozen or so).
>>>
>>> What I really hated about it was that when [EMAIL PROTECTED] sent
>>> me an email often I couldn't decrypt it.  Why?  Because his
>>> firm's email server decided to put in the FROM field
>>> "[EMAIL PROTECTED]". Since it didn't match the email name
>>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
>>> attachment. This also caused problems with replying to his email.
>>> It took us hours, with several experimental emails sent back and
>>> forth, to figure out the root of the problem.
>>>
>>> No wonder PKI has died commercially and encrypted email is on the
>>>  endangered species list.
>> I trust you don't think this is a problem with PKI, right? Since
>> clearly the issue is with the s/w you were using.
> I place the blame squarely on X.509 PKI.  The identity aspect of it
> is all screwed up. No software implementation can overcome such a
> fundamental architectural flaw.
 OK - I'll bite - why does the sender's identity have any impact on the
 recipient's ability to decrypt?

>>> Because the software needs a unique ID/name to find the correct
>>> key to use. In practice (corporate) users can have multiple email
>>> names, see my reply to Peter Gutman.  This is not the fault of
>>> the email architecture, which has been working fine for 30-40
>>> years, but the fault
>>> of the X.509 architecture trying to piggyback on an address/name
>>> space that is not designed with security/cryptography
>>> considerations in mind.
>> I have to admit to not being familiar with S/MIME, but the usual
>> practice is to identify the signing key in the signature. Certainly this
>> is what OpenPGP does. Its also kinda weird to refuse to decrypt just
>> because the signature can't be verified.
>>
>
> How does OpenPGP identify the signing key in the incoming email's 
signature?


Here's the output of one of the example programs in OpenPGP:SDK
(http://openpgp.nominet.org.uk/), showing the structure of an OpenPGP
signed file. I trust it is self-explanatory.


Assuming this file is attached to an incoming email message, how does the
receiver's email software match the Signer ID (= 0x8337FE6485F4ED64) to
a X.509 cert in his local cache that is associated with the email sender's name
(= "[EMAIL PROTECTED]")?


--

- Alex Alten


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Florian Weimer]

* Bill Stewart:

> Or you could try using the Google Keyserver -
>   just because there isn't one
> doesn't mean you can't type in "9E94 4513 3983 5F70"
> or 9383DE06   or   [EMAIL PROTECTED] "PGP Key"
> and see what's in Google's cache.

What a peculiar advice.  We know for sure that Google logs these
requests and stores them indefinitely. 8-(

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Anton Stiglic]

>More strongly, if we've never met, and you are not in the habit of
>routinely signing email, thereby tying a key to your e-persona, it
>makes no sense to speak of *secure* communication to *you*. 

Regularly signing email is not necessarily a good idea.  I like to be able
to repudiate most emails I send...

 --Anton

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 03/03/2006
 


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

[EMAIL PROTECTED] wrote:
>> - Original Message -
>> From: "Ben Laurie" <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use
>> Date: Thu, 02 Mar 2006 10:16:55 +
>>
>>
>> [EMAIL PROTECTED] wrote:
>>>> Alex Alten wrote:
>>>>> At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
>>>>>> Alex Alten wrote:
>>>>>>> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
>>>>>>>> Ed Gerck wrote: We have keyservers for this (my chosen
>>>>>>>> technology was PGP). If you liken their use to looking up an
>>>>>>>> address in an address book, this isn't hard for users to grasp.
>>>>>>>>
>>>>>>> I used PGP (Enterprise edition?) to encrypt my work emails to 
>>>>>>> a distributed set of members last year.  We all had each 
>>>>>>> other's
>>>>>>> public keys (about a dozen or so).
>>>>>>>
>>>>>>> What I really hated about it was that when [EMAIL PROTECTED] sent
>>>>>>> me an email often I couldn't decrypt it.  Why?  Because his
>>>>>>> firm's email server decided to put in the FROM field
>>>>>>> "[EMAIL PROTECTED]". Since it didn't match the email name
>>>>>>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
>>>>>>> attachment. This also caused problems with replying to his email.
>>>>>>> It took us hours, with several experimental emails sent back and
>>>>>>> forth, to figure out the root of the problem.
>>>>>>>
>>>>>>> No wonder PKI has died commercially and encrypted email is on the
>>>>>>>  endangered species list.
>>>>>> I trust you don't think this is a problem with PKI, right? Since
>>>>>> clearly the issue is with the s/w you were using.
>>>>> I place the blame squarely on X.509 PKI.  The identity aspect of it
>>>>> is all screwed up. No software implementation can overcome such a
>>>>> fundamental architectural flaw.
>>>> OK - I'll bite - why does the sender's identity have any impact on the
>>>> recipient's ability to decrypt?
>>>>
>>> Because the software needs a unique ID/name to find the correct 
>>> key to use. In practice (corporate) users can have multiple email 
>>> names, see my reply to Peter Gutman.  This is not the fault of 
>>> the email architecture, which has been working fine for 30-40 
>>> years, but the fault
>>> of the X.509 architecture trying to piggyback on an address/name 
>>> space that is not designed with security/cryptography 
>>> considerations in mind.
>> I have to admit to not being familiar with S/MIME, but the usual
>> practice is to identify the signing key in the signature. Certainly this
>> is what OpenPGP does. Its also kinda weird to refuse to decrypt just
>> because the signature can't be verified.
>>
> 
> How does OpenPGP identify the signing key in the incoming email's signature?

Here's the output of one of the example programs in OpenPGP:SDK
(http://openpgp.nominet.org.uk/), showing the structure of an OpenPGP
signed file. I trust it is self-explanatory.

 ptag new_format=0 content_tag=8 length_type=3 length=0x0 (0)
position=0x0 (0)
COMPRESSED packet
Compressed Data Type: 1

 ptag new_format=0 content_tag=4 length_type=0 length=0xd (13)
position=0x0 (0)
ONE PASS SIGNATURE packet
Version: 3
Signature Type: Signature of a binary document (0x0)
Hash Algorithm: SHA1 (0x2)
Public Key Algorithm: RSA (Encrypt or Sign) (0x1)
Signer ID: 0x8337FE6485F4ED64
Nested: 1

 ptag new_format=0 content_tag=11 length_type=0 length=0x22 (34)
position=0xf (15)
LITERAL DATA HEADER packet
  literal data header format=b filename='to-be-signed'
modification time=1141297085 (Thu Mar  2 10:58:05 2006)
LITERAL DATA BODY packet
  literal data body length=16
data=
To Be Signed.



 ptag new_format=0 content_tag=2 length_type=1 length=0x95 (149)
position=0x33 (51)
SIGNATURE packet
Signature Version: 3
Signature Creation Time: time=1141297085 (Thu Mar  2 10:58:05 2006)
Signature Type: Signature of a binary document (0x0)
Signer ID: 0x8337FE6485F4ED64
Public Key Algorithm: RSA (Encrypt or Sign) (0x1)
Hash Algorithm: SHA1 (0x2)
hash2: 0xBF33
sig=7344970C0DF62B089E79FFF024137E9D7D8919B6B1F1F29F3CCE8CD34625759EC181452C1A17858E418BA838FD3FED6AD013E7562F0B4E87BCA81D82D22B825A3ED6447E0F31F14DE0321554D558CEDCC339424ADA01B7C7374BBC59DE54E6BE4670D9D9E6FAC6412E927545DF1D2F0A373BFE6D058893CF675554F2DF8BE079

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

[EMAIL PROTECTED] wrote:
>> Alex Alten wrote:
>>> At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
 Alex Alten wrote:
> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
>> Ed Gerck wrote: We have keyservers for this (my chosen
>> technology was PGP). If you liken their use to looking up an
>> address in an address book, this isn't hard for users to grasp.
>>
> I used PGP (Enterprise edition?) to encrypt my work emails to a 
> distributed set of members last year.  We all had each other's
> public keys (about a dozen or so).
>
> What I really hated about it was that when [EMAIL PROTECTED] sent
> me an email often I couldn't decrypt it.  Why?  Because his
> firm's email server decided to put in the FROM field
> "[EMAIL PROTECTED]". Since it didn't match the email name
> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
> attachment. This also caused problems with replying to his email.
> It took us hours, with several experimental emails sent back and
> forth, to figure out the root of the problem.
>
> No wonder PKI has died commercially and encrypted email is on the
>  endangered species list.
 I trust you don't think this is a problem with PKI, right? Since
 clearly the issue is with the s/w you were using.
>>> I place the blame squarely on X.509 PKI.  The identity aspect of it
>>> is all screwed up. No software implementation can overcome such a
>>> fundamental architectural flaw.
>> OK - I'll bite - why does the sender's identity have any impact on the
>> recipient's ability to decrypt?
>>
> 
> Because the software needs a unique ID/name to find the correct key to 
> use. In practice (corporate) users can have multiple email names, see 
> my reply to Peter Gutman.  This is not the fault of the email 
> architecture, which has been working fine for 30-40 years, but the fault
> of the X.509 architecture trying to piggyback on an address/name space 
> that is not designed with security/cryptography considerations in mind.

I have to admit to not being familiar with S/MIME, but the usual
practice is to identify the signing key in the signature. Certainly this
is what OpenPGP does. Its also kinda weird to refuse to decrypt just
because the signature can't be verified.

Cheers,

Ben.


-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[alex]

> Alex Alten wrote:
> > At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
> >> Alex Alten wrote:
> >>> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
>  Ed Gerck wrote: We have keyservers for this (my chosen
>  technology was PGP). If you liken their use to looking up an
>  address in an address book, this isn't hard for users to grasp.
> 
> >>>
> >>> I used PGP (Enterprise edition?) to encrypt my work emails to a 
> >>> distributed set of members last year.  We all had each other's
> >>> public keys (about a dozen or so).
> >>>
> >>> What I really hated about it was that when [EMAIL PROTECTED] sent
> >>> me an email often I couldn't decrypt it.  Why?  Because his
> >>> firm's email server decided to put in the FROM field
> >>> "[EMAIL PROTECTED]". Since it didn't match the email name
> >>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
> >>> attachment. This also caused problems with replying to his email.
> >>> It took us hours, with several experimental emails sent back and
> >>> forth, to figure out the root of the problem.
> >>>
> >>> No wonder PKI has died commercially and encrypted email is on the
> >>>  endangered species list.
> >>
> >> I trust you don't think this is a problem with PKI, right? Since
> >> clearly the issue is with the s/w you were using.
> >
> > I place the blame squarely on X.509 PKI.  The identity aspect of it
> > is all screwed up. No software implementation can overcome such a
> > fundamental architectural flaw.
> 
> OK - I'll bite - why does the sender's identity have any impact on the
> recipient's ability to decrypt?
> 

Because the software needs a unique ID/name to find the correct key to 
use. In practice (corporate) users can have multiple email names, see 
my reply to Peter Gutman.  This is not the fault of the email 
architecture, which has been working fine for 30-40 years, but the fault
of the X.509 architecture trying to piggyback on an address/name space 
that is not designed with security/cryptography considerations in mind.

- Alex


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Peter Thoenen]

--- John W Noerenberg II <[EMAIL PROTECTED]> wrote:
> Oh really?  Then you should be able to send a note to my gmail
> address.

So I have been reading this thread for the last couple days and the
above comment gives me a chance to voice something that really needs to
be said.  Let's face it, a large chunk of emails (including work and
official emails) are sent from folks personal yahoo, google, hotmail,
AOL, etc etc accounts via web based interfaces.  Hell  even lots of
official work accounts are going webmail now days as anything to make
like better for the ignorant worker.  We keep talking about tools and
email client integration but everybody seems to be missing the obvious.
 Where are the inline integrated webmail authentication tools and don't
say copy / paste.

Until we solve this problem, I don't see mom and pop signing their
emails automatically and / or transparently.  


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[James A. Donald]

--
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 [EMAIL PROTECTED]

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

[Victor Duchovni]

On Wed, Mar 01, 2006 at 06:15:36PM +0100, Ian G wrote:

> >>Email is hard to get encrypted, but it didn't stop Skype from doing
> >>encryped IMs "easily."
> >
> >
> >Likewise I have secured email communications with my wife via a single
> >key exchange, so what? Skype has not "easily" created an interoperable
> >federated system that secures all IM communications end-to-end, and
> >many of the issues in doing that are non-technical.
> 
> 
> Right.  Nor did email create a single federated
> system that crosses across to mobile phones.  There
> is always a boundary where a system stops.

Federated accross millions of account issuing organizations, not
technologies, and email did do that, and IM did not. IM is like email from
a choice MCI, Sprint or AT&T, sure they can control the medium better,
but this is a temporary state of affairs...

> The point is that the non-technical issues we
> are looking at here are *better* handled at the
> level of competitive systems, because they have
> incentives to solve them, whereas technical
> committees writing RFCs do not.

These are closed systems that compete with each other, once
they become federated, they can no longer compete on end-to-end
security, because that is a property of the interoperability
framework, not the individual product. Also with millions
of account issuers, the abuse and identity problems become
just as bad as for email. The problem is intrinsic, is not
the result of lazy RFC writers.

-- 

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Bill Stewart]

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 [EMAIL PROTECTED]

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

[Bill Stewart]

Somebody, probably Florian, wrote:

> I couldn't find a PGP key server operator that committed itself to
> keeping logs confidential and deleting them in a timely manner (but I
> didn't look very hard, either).


Keyservers are a peripheral issue in PGP -
important for convenience and for quick distribution of revocation lists,
but they're very strongly just a tool for convenience.

Security through Inconvenience is one flipside of Security through 
Obscurity, I suppose...


If you've got a threat model that includes traffic analysis,
then either you and your unindicted co-conspirators
need to find other ways to exchange keys,
like printing them on business cards,
or find a keyserver that lets you suck down all the keys
so it's not obvious which key you're looking for,
or start using Tor to access the keyservers.

Or you could try using the Google Keyserver -
  just because there isn't one
doesn't mean you can't type in "9E94 4513 3983 5F70"
or 9383DE06   or   [EMAIL PROTECTED] "PGP Key"
and see what's in Google's cache.





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Udhay Shankar N]

At 04:52 PM 2/26/2006, Ben Laurie wrote:


Don't forget that the ability to decrypt is just as good as a signature
to prove association of the key.


All it needs is for one successful trojan that steals your private 
key/passphrase and "plausible deniability" is available again. :)


Does anybody know if there were followups to the Caligula virus, 
which was a proof-of-concept that stole PGP keyrings?


Udhay

--
((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com))


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[StealthMonger]

Ben Laurie <[EMAIL PROTECTED]> writes:

> Florian Weimer wrote:

> > I couldn't find a PGP key server operator that committed itself to
> > keeping logs confidential and deleting them in a timely manner (but I
> > didn't look very hard, either).  Of course, since PGP hasn't
> > progressed as faster as our computing resources, I'm nowadays in a
> > position to run my own key server, but this is hardly a solution to
> > that kind of problem.

> OK, I buy the problem, but until we do something about the totally
> non-anonymising properties of the 'net, revealing that I want the public
> key for some person seems to be quite minor - compared, for example, to
> revealing that I sent him email each time I do.

But you don't have to reveal that you sent him email.  You can use
stealthy communication.

Stealthy communication is communication wherein not only is the
content concealed from eavesdroppers by encryption, but information
about who is communicating with whom, when, or if at all, is
concealed, as well.

The Internet can be used for stealthy communication.  The basic idea
is that each potential participant has ongoing traffic to and from a
message pool which is propagated world-wide.  When the participant has
no live traffic to send, dummy traffic is sent instead.  The dummy
traffic is indistinguishable from the live traffic except by using
decryption keys which are chosen by correspondents.  The outbound
traffic continues autonomously without interruption for months and
years and is not correlated to the live traffic, so an observer
without the keys cannot determine when or how much live communication
is happening.  Inbound cover traffic consists of taking a full feed of
the message pool at all times without interruption.

A Debian Linux package exists which enables stealthy email.  It has
been in everyday use for years, although not widely.  Details on
request.  I am looking for someone to host it.  Any volunteers?

 -- StealthMonger

 <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ed Gerck]

John W Noerenberg II wrote:

At 5:58 PM -0800 2/24/06, Ed Gerck wrote:
A phone number is not an "envelope" -- it's routing information, just 
like

an email address. Publishing the email address is not in question and
there are alternative ways to find it out, such as search engines.


Oh really?  Then you should be able to send a note to my gmail address.


I did quite not get the irony/humor. All I'm saying about an email
address is that (1) it does not work as an envelope (hiding contents); and
(2) there's no big problem in using it. You publish your email address
every time you send an email from it, which may also make it searchable.


At 1:11 PM -0800 2/25/06, Ed Gerck wrote:
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.


And that distinction is?

To me a cell-phone number is a string of characters, and a public-key is 
- a string of characters.


The distinction should be obvious if you try to tell someone your public-key
over the phone, byte by byte for 1024 bits, versus telling her your
8-digit cell phone number.

Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[John W Noerenberg II]

At 5:58 PM -0800 2/24/06, Ed Gerck wrote:

A phone number is not an "envelope" -- it's routing information, just like
an email address. Publishing the email address is not in question and
there are alternative ways to find it out, such as search engines.


Oh really?  Then you should be able to send a note to my gmail address.

At 1:11 PM -0800 2/25/06, Ed Gerck wrote:

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.


And that distinction is?

To me a cell-phone number is a string of characters, and a public-key 
is - a string of characters.



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.


And if (on purpose or by force) your cell-phone number is being 
monitored by an eavesdropper, MY call is compromised from the start 
and I have no way of knowing it.


There is no difference.
--

john noerenberg
  --
  All actions are wrought by the qualities of nature only.
  The self, deluded by egoism, thinketh, "I am the doer."
  -- Bhagavad Gita
  --

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Victor Duchovni]

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 MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Jon Callas]

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






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[markus reichelt]

* Greg Black <[EMAIL PROTECTED]> wrote:

> On 2006-02-24, Peter Saint-Andre wrote:

> > Personally I doubt that anything other than a small percentage of
> > email will ever be signed, let alone encrypted (heck, most people
> > on this list don't even sign their mail).

My personal experience differs. The people that have set up some kind
of encryption to protect their privacy will use it at best and
advertise such a possibility at the very least. Be it via kludges,
email headers, footers, inline signatures, word of mouth (websites).
The important fact is they do something.

I did a little research on my email of the past month, both public
mailinglists and private mail. The vast majority of private email was
signed (and encrypted with both sender and recipient being part of
the WoT), with public mailings showing a slightly increasing number
of signed mailings. I realize that's far from being representative,
but that's really the way it should be.


> That's at least partly because too many mailing lists either reject
> signed messages out of hand or, worse, have subscribers who use
> providers that reject signed messages and then spam you with their
> idiotic bounce messages.

That's too true. Emails with signatures as attachements are often
blocked (or with attachements removed altogether) because of the
omnipresent virus-hype; I strongly believe that coping with possible
virus threats is definitely not the job of a mailinglist software.
But there's still the possibility of inline signatures.

As to the ISP issue, it would make perfect sense to me to switch ISPs
because of such bounce messages. However, I personally know of some
that are better not mentioned by name, and sadly don't regret their
practice. Net-neutrality has to be existent!

Back to topic; e.e. both mutt, and its recent offspring mutt-ng,
easily allow to adapt, as do other mail user agents out there. I
strongly recommend to use such features if present. In the past I've
seen forged signatures added to SPAM mails, so it's about time to
sharpen the public's view on the matter.

On a sidenote: From what I've heard, most banks don't bother much
with encryption and solely focus on message integrity. Well, even if
one shares the rather naive viewpoint of having nothing to hide (but
still doesn't run naked; I wonder why...) it just can't hurt of
having integrity added to ones own messages.

I'm going to repeat soon: It doesn't have to be the full package
right from the start. And with phishing attacks becoming more and more
sophisticated it's only a matter of time until the public has to
deal with the whole issue of integrity.


> Keeping track of which lists allow signed email and which don't is
> impractical if you subscribe to hundreds of lists, so the simple
> thing is to tick the "don't sign" box on list messages.

Sad but true. However, IMHO, that's also equal to "I give up "
and clearly the wrong path one could possibly choose. Nonetheless, I
guess it's safe to assume the ordinary user to have only a handful of
mailinglists subscribed; granted, some people receive tens of
mailinglists, but hundreds? Let's don't forget the time involved. I
subscribed to 30 mailinglists, and to my licking there is not a
single one lacking the more or less occasional signed mailings.

One could argue with the list admins to allow signatures; that's
usually an up-hill battle that still can be won by inline signatures.
Of course, it's a hassle in terms of getting a working setup but it
is far worse to leave the battlefield to the enemy. By doing so one
gives the masses a wrong impression of the actual ease, once locally
implemented, of being able to add integrity to one's messages. And
that's only one step short of the actual much needed privacy, imho.

Veryfing the integrity of a message lies at the receiving end, after
all. That's where one has to start. It doesn't have to be the whole
thing about encryption, message signing, WoT, etc. right from the
start, curiosity will do the rest.

In essence: A barbeque about such a topic will suffice. In my
experience I can proudly point to some bowling/poker events that did
the trick for some people. "It's not wrong, it's a start..."


> In this case, since Peter's message was signed, I know this list
> allows signatures.  So I'll sign this message.

Add me to the list (and forgive the pun please). Even if this list
would not, with the sig added as attachement, I would do so via
inline signature.

So, why not always sign messages to a list that permits signatures? 


> But the signature will be of limited utility, as not one of the
> several email addresses on my signature is a match for the email
> address I am sending this from.  Again, lists being what they are,
> I use a different address for most lists and my PGP key would
> become absurd if I added several hundred addresses to it.

That's why I use a sole key for mailinglists and related encrypted
mailings, additionally to my private and work keys. Works like a

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

[Peter Saint-Andre]

bear wrote:
> 
> On Fri, 24 Feb 2006, Peter Saint-Andre wrote:
> 
> 
>> Personally I doubt that anything other than a small percentage of email
>> will ever be signed, let alone encrypted (heck, most people on this list
>> don't even sign their mail).
>>
> 
> I don't think I've said anything here that I will later want to be
> able to prove incontrovertibly was said by me.
> 
> In general, signing your mail has a downside in this age of litigous
> potential mail recipients, and except when your mail regards the
> disposition of assets, no upside.
> 
> In the long run, I think the population of people who want to sign
> their mail is about the same as the population of people who want to
> post on usenet with their real name and put their street address
> and phone number at the bottom of every post.
> 
> Why give the anonymous cowards who are collecting information with
> robotic trawlers, whether for spam lists or any other reason, proof
> of exactly who you are?

The short answer to your unstated question is: anonymity is not high in
my scale of values. The long answer will require some reflection on my
part, which I won't post here but at my blog when I have the time.

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Victor Duchovni]

On Sat, Feb 25, 2006 at 07:33:38PM +0100, Ian G wrote:

> Hence, IM/chat, Skype, TLS experiments at Jabber, as
> well as the OpenPGP attempts.
> 
> There are important lessons to be learnt in the rise of
> IM over email.

Likewise the rise of the telephone over paper mail, but the phone does
not obviate the need for paper mail.

> Email is held back by its standardisation, chat seems to overcome
spam quite nicely.

Where's Gaddi Evron when you need him? This is just not true, the spam
volume is rising for both blogs and IM.

> Email is hard to get encrypted, but it didn't stop Skype from doing
> encryped IMs "easily."

Likewise I have secured email communications with my wife via a single
key exchange, so what? Skype has not "easily" created an interoperable
federated system that secures all IM communications end-to-end, and
many of the issues in doing that are non-technical.

> The competition between the IM systems is what is driving
> the security forward.  As there is no competition in the
> email world, at least at the level of the basic protocol
> and standard, there is no way for the security to move
> forward.
> 

IM is "islands of automation", luckily email works globally.

> Phishing is possible over chat,
> but has also been relatively easy to address - because
> the system owners have incentives and can adjust.

This is naive, IM will become federated and decentralized and abuse
issues will be the same as for email. You can't fence the bad guys
out of the network.

-- 

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Alex Alten wrote:
> At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
>> Alex Alten wrote:
>>> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
 Ed Gerck wrote: We have keyservers for this (my chosen
 technology was PGP). If you liken their use to looking up an
 address in an address book, this isn't hard for users to grasp.
 
>>> 
>>> I used PGP (Enterprise edition?) to encrypt my work emails to a 
>>> distributed set of members last year.  We all had each other's
>>> public keys (about a dozen or so).
>>> 
>>> What I really hated about it was that when [EMAIL PROTECTED] sent
>>> me an email often I couldn't decrypt it.  Why?  Because his
>>> firm's email server decided to put in the FROM field
>>> "[EMAIL PROTECTED]". Since it didn't match the email name
>>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
>>> attachment. This also caused problems with replying to his email.
>>> It took us hours, with several experimental emails sent back and
>>> forth, to figure out the root of the problem.
>>> 
>>> No wonder PKI has died commercially and encrypted email is on the
>>>  endangered species list.
>> 
>> I trust you don't think this is a problem with PKI, right? Since
>> clearly the issue is with the s/w you were using.
> 
> I place the blame squarely on X.509 PKI.  The identity aspect of it
> is all screwed up. No software implementation can overcome such a
> fundamental architectural flaw.

OK - I'll bite - why does the sender's identity have any impact on the
recipient's ability to decrypt?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Florian Weimer wrote:
> * Ben Laurie:
> 
>> I don't use PGP - for email encryption I use enigmail, and getting
>> missing keys is as hard as pressing the "get missing keys" button.
> 
> A step which has really profound privacy implications.
> 
> I couldn't find a PGP key server operator that committed itself to
> keeping logs confidential and deleting them in a timely manner (but I
> didn't look very hard, either).  Of course, since PGP hasn't
> progressed as faster as our computing resources, I'm nowadays in a
> position to run my own key server, but this is hardly a solution to
> that kind of problem.

OK, I buy the problem, but until we do something about the totally
non-anonymising properties of the 'net, revealing that I want the public
key for some person seems to be quite minor - compared, for example, to
revealing that I sent him email each time I do.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Peter Gutmann]

Alex Alten <[EMAIL PROTECTED]> writes:

>What I really hated about it was that when [EMAIL PROTECTED] sent me an email
>often I couldn't decrypt it.  Why?  Because his firm's email server decided
>to put in the FROM field "[EMAIL PROTECTED]".  Since it didn't match
>the email name in his X.509 certificate's DN it wouldn't decrypt the S/MIME
>attachment. This also caused problems with replying to his email.  It took us
>hours, with several experimental emails sent back and forth, to figure out
>the root of the problem.

Something's getting lost in this description.  What does the value in the
"From" field have to do with you decrypting a message?  OTOH the mention of an
"attachment" indicates a detached S/MIME signature, which doesn't have
anything to do with encryption.  If it is a signature, then the software
should verify it with the included cert and display that as the signer.

Please correct and resubmit.

Peter.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Alex Alten]

At 05:12 PM 2/26/2006 +, Ben Laurie wrote:

Alex Alten wrote:
> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
>> Ed Gerck wrote: We have keyservers for this (my chosen technology
>> was PGP). If you liken their use to looking up an address in an
>> address book, this isn't hard for users to grasp.
>
> I used PGP (Enterprise edition?) to encrypt my work emails to a
> distributed set of members last year.  We all had each other's public
> keys (about a dozen or so).
>
> What I really hated about it was that when [EMAIL PROTECTED] sent me
> an email often I couldn't decrypt it.  Why?  Because his firm's email
> server decided to put in the FROM field "[EMAIL PROTECTED]".
> Since it didn't match the email name in his X.509 certificate's DN it
> wouldn't decrypt the S/MIME attachment. This also caused problems
> with replying to his email.  It took us hours, with several
> experimental emails sent back and forth, to figure out the root of
> the problem.
>
> No wonder PKI has died commercially and encrypted email is on the
> endangered species list.

I trust you don't think this is a problem with PKI, right? Since clearly
the issue is with the s/w you were using.


I place the blame squarely on X.509 PKI.  The identity aspect of it is all 
screwed up.

No software implementation can overcome such a fundamental architectural flaw.

- Alex


--

- Alex Alten


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Trevor Perrin]

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 [EMAIL PROTECTED]

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

[Paul Hoffman]

At 5:59 PM -0500 2/24/06, John Kelsey wrote:

What we ultimately need is encryption and
authentication that are:

a.  Automatic and transparent.

b.  Add some value or are bundled with something that does.

c.  Don't try to tie into the whole horrible set of PKI standards in
terms of uniquely identifying each human and bit in the universe, and
getting them to sign legally binding messages whose full
interpretation requires reading and understanding a 30-page CPS.


We have the preamble and (a) already; the problem is that the 
preamble is insufficient. What we ultimately need is encryption and 
authentication *and validation of the authentication* that match at 
least (a).


Currently, it is the validation of the authentication that makes most 
users uninterested. When you get a message from Bob that comes with a 
warning that says "I cannot tell whether or not Bob really sent 
this", but you are sure that Bob actually sent that (due to some 
out-of-band knowledge), you lose faith in the system. When Bob has 
the same problem with your messages, you give up.


For signed personal mail, (b) and (c) may be mutually exclusive. Why 
sign your messages if you don't want to be held liable for their 
contents? How can you get the reward of integrity without the cost of 
responsibility?


Given those two hurdles, my hopes for authenticated mail near zero. I 
have some hopes for authenticated syndicated messages through Atom or 
RSS, but not this year. The hardest part there will be (c), but there 
are many environments where signing one-way mail is quite 
appropriate, particularly in replacing paper messages.


The demand for encryption of personal email is perpetually low. 
Without a legal requirement, it will probably always be a small niche 
market.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Florian Weimer]

* Ben Laurie:

> I don't use PGP - for email encryption I use enigmail, and getting
> missing keys is as hard as pressing the "get missing keys" button.

A step which has really profound privacy implications.

I couldn't find a PGP key server operator that committed itself to
keeping logs confidential and deleting them in a timely manner (but I
didn't look very hard, either).  Of course, since PGP hasn't
progressed as faster as our computing resources, I'm nowadays in a
position to run my own key server, but this is hardly a solution to
that kind of problem.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Alex Alten wrote:
> At 02:59 PM 2/24/2006 +, Ben Laurie wrote:
>> Ed Gerck wrote: We have keyservers for this (my chosen technology
>> was PGP). If you liken their use to looking up an address in an
>> address book, this isn't hard for users to grasp.
> 
> I used PGP (Enterprise edition?) to encrypt my work emails to a 
> distributed set of members last year.  We all had each other's public
> keys (about a dozen or so).
> 
> What I really hated about it was that when [EMAIL PROTECTED] sent me
> an email often I couldn't decrypt it.  Why?  Because his firm's email
> server decided to put in the FROM field "[EMAIL PROTECTED]".
> Since it didn't match the email name in his X.509 certificate's DN it
> wouldn't decrypt the S/MIME attachment. This also caused problems
> with replying to his email.  It took us hours, with several
> experimental emails sent back and forth, to figure out the root of
> the problem.
> 
> No wonder PKI has died commercially and encrypted email is on the 
> endangered species list.

I trust you don't think this is a problem with PKI, right? Since clearly
the issue is with the s/w you were using.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Matthew Byng-Maddick]

On Sat, Feb 25, 2006 at 07:33:38PM +0100, Ian G wrote:
> areas.  The fact is that SSH came in with a solution
> and beat the other guy - Telnet secured over SSL.  It
> wasn't the crypto that did this, it was the key management,
> plain and simple.

Very few people I knew at the time moved to SSH because it was "more
secure" and because "passwords weren't in plaintext". Most of the
people moved because of the things you could do with SSH above and
beyond telnet (port forwarding, X11 forwarding etc). In fact, the
latter is the main reason I moved - it dated before i started taking
an interest in security. Not to say that there weren't *any* who had
the security reasons for moving, but then kerberized telnet existed
too at that point in time.

Cheers,

MBM

-- 
Matthew Byng-Maddick  <[EMAIL PROTECTED]>   http://colondot.net/
  (Please use this address to reply)

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Nicolas Rachinsky]

* Ed Gerck <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]

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

[Ben Laurie]

Victor Duchovni wrote:
> On Fri, Feb 24, 2006 at 01:44:14PM +, Ben Laurie wrote:
> 
>> Ed Gerck wrote:
>>> Paul,
>>>
>>> Usability should by now be recognized as the key issue for security -
>>> namely, if users can't use it, it doesn't actually work.
>>>
>>> And what I heard in the story is that even savvy users such as Phil Z
>>> (who'd have no problem with key management) don't use it often.
>>>
>>> BTW, just to show that usability is king, could you please send me an
>>> encrypted email -- I even let you choose any secure method that you want.
>> Sure I can, but if you want it to be encrypted to you, then you need to
>> publish a key.
> 
> More strongly, if we've never met, and you are not in the habit of
> routinely signing email, thereby tying a key to your e-persona, it
> makes no sense to speak of *secure* communication to *you*. Which "you"
> would that be, the one who sent me all those exciting zip files of W32
> executables, or the one I think is posting to this list?
> 
> The only identity you (who hypothetically do not garnish each message
> with a signature) have is your mailbox. I can bootstrap that (with
> questionable initial security) to a key via a "private" unencrypted
> email message, and over a time as the key is consistently used grow to
> associate the key with an on-line persona.

Don't forget that the ability to decrypt is just as good as a signature
to prove association of the key.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ed Gerck]

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 [EMAIL PROTECTED]

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

[Ian G]

Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ian G wrote:



To get people to do something they will say "no"
to, we have to give them a freebie, and tie it
to the unpleasantry.  E.g., in SSH, we get a better
telnet, and there is only the encrypted version.



We could just as well say that "encryption of remote server sessions is
rare in everyday use". It's just that only geeks even do remote server
sessions, so they use SSH instead of telnet.

The thing is that email is in wide use (unlike remote server sessions).


Well!  Within the context of any given application,
we can learn lessons.  Just because SSH is only used
by geeks is meaningless, really, we need to ground
that criticism in something that relates it to other
areas.  The fact is that SSH came in with a solution
and beat the other guy - Telnet secured over SSL.  It
wasn't the crypto that did this, it was the key management,
plain and simple.

Telnet was in widespread use - but was incapable of
making the jump to secure.  Just like email.  So if
the SSH example were illuminating, we would predict
that some completely different *non-compatible* app
would replace email.

Hence, IM/chat, Skype, TLS experiments at Jabber, as
well as the OpenPGP attempts.

There are important lessons to be learnt in the rise of
IM over email.  Email is held back by its standardisation,
chat seems to overcome spam quite nicely.  Email is hard
to get encrypted, but it didn't stop Skype from doing
encryped IMs "easily."  Phishing is possible over chat,
but has also been relatively easy to address - because
the system owners have incentives and can adjust.

The competition between the IM systems is what is driving
the security forward.  As there is no competition in the
email world, at least at the level of the basic protocol
and standard, there is no way for the security to move
forward.

iang

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Ed Gerck wrote:
> Ben Laurie wrote:
>> Really? I just write "Ed Gerck" on an envelope and it gets to you? I
>> doubt it. Presumably I have to do all sorts of hard and user-unfriendly
>> things to find out and verify your address.
> 
> Perhaps I wasn't clear -- with postal mail you just write my name and
> address
> in YOUR envelope and it gets to me. With PGP and PKI you have to ask for MY
> "envelope" first; further, MY public-key creates the secure envelope
> that you
> now need to trust with YOUR secret...

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.

Apart from content of the blob handed over, the two transactions are
identical.

>> If you handled your keys properly I would not need to ask you for
>> anything. 
> 
> 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?

> 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.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Peter Saint-Andre wrote:
> Ian G wrote:
> 
>> To get people to do something they will say "no"
>> to, we have to give them a freebie, and tie it
>> to the unpleasantry.  E.g., in SSH, we get a better
>> telnet, and there is only the encrypted version.
> 
> We could just as well say that "encryption of remote server sessions is
> rare in everyday use". It's just that only geeks even do remote server
> sessions, so they use SSH instead of telnet.
> 
> The thing is that email is in wide use (unlike remote server sessions).
> Personally I doubt that anything other than a small percentage of email
> will ever be signed, let alone encrypted (heck, most people on this list
> don't even sign their mail).

I don't sign mail not because I can't be bothered, but because it is my
policy to not sign mail.

If I signed it, it would be substantially harder to deny I wrote it.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[James A. Donald]

--
Ben Laurie wrote:
> > but if you want it to be encrypted to you, then you need to
> > publish a key.

Ed Gerck wrote:
> This IS one of the sticky points ;-) If postal mail would work this
> way, you'd have to ask me to send you an envelope before you can
> send me mail. This is counter-intuitive to users.

Public key should be part of signature.

> Your next questions could well be how do you know my key is really
> mine...

If key is part of signature, you know it really belongs to the person
who posted the item to which you are replying - and sometimes that is
the thing that you really want to know.

Of course you do not know that the person to which you are replying is
really the person he represents himself as being - is he really the
fraud control officer for your bank?  But presumably you are
interacting with the bank through its website, so you, or rather your
software, should damn well know the bank's public key, and the fraud
control officer's signature should have a certificate by the bank
attesting his relationship to the bank.

> how do you know it was not revoked

It should be checked every time you logon to the bank, and every time
you logon, instead of telling the site your password, you proceed with
a zero knowledge proof where both parties prove knowledge of the
password without revealing the password.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 L4p0k6+mzp2x2QNOdALduMQfwAIXYrsJ3cVYYK4Q
 4iEeX76ichaV+J6eVImNtWEoGzvMmAHKNHHix+chD

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Alex Alten]

At 06:09 PM 2/24/2006 +0100, Ian G wrote:

Steven M. Bellovin wrote:

Certainly, usability is an issue.  It hasn't been solved because there's 
no market for it here; far too few people care about email encryption.


Usability is the issue.  If I look over onto
my skype window, it says there are 5 million
or so users right now.  It did that without
any of the hullabaloo of the other systems,
and still manages to encrypt my comms.  By
some measures it is the most successful crypto
system ever.


Actually the usability issue has been solved elsewhere too.  We did it over 
at TriStrata
before the firm crashed in 1998.  We allowed the system security officer to 
select the
default cipher to use in sending emails (DES, 3DES, Blowfish, RC4, etc.). 
The receiver
could use any cipher for decrypting incoming email. A sys admin installed 
some filter
software into the email client, and except for an initial login dialog (and 
we even simplified
that by hooking the OS login dialog), the user never had to do anything 
further.  The local
auth keys that he received during enrollment were encrypted with his 
password on a small

floppy disk, or could be installed on the hard drive automatically.

Last I heard (early 2005) one system was operational over in the nuclear 
engineering
department at Ohio State (for DOE work?).  Of course one old system rack in 
the

dusty corner of a school building does not a market make.

- Alex

--

- Alex Alten


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Alex Alten]

At 02:59 PM 2/24/2006 +, Ben Laurie wrote:

Ed Gerck wrote:
We have keyservers for this (my chosen technology was PGP). If you liken
their use to looking up an address in an address book, this isn't hard
for users to grasp.


I used PGP (Enterprise edition?) to encrypt my work emails to a distributed 
set of

members last year.  We all had each other's public keys (about a dozen or so).

What I really hated about it was that when [EMAIL PROTECTED] sent me an email
often I couldn't decrypt it.  Why?  Because his firm's email server decided 
to put

in the FROM field "[EMAIL PROTECTED]".  Since it didn't match the email
name in his X.509 certificate's DN it wouldn't decrypt the S/MIME attachment.
This also caused problems with replying to his email.  It took us hours, with
several experimental emails sent back and forth, to figure out the root of 
the problem.


No wonder PKI has died commercially and encrypted email is on the endangered
species list.

- Alex
--

- Alex Alten


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[John W Noerenberg II]

While there is merit in arguing how to simplify the mechanics of 
using public key encryption for sending and receiving email, I cannot 
agree with this assertion:


At 10:44 AM -0800 2/24/06, 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.


If an individual wants to receive telephone calls, he has to agree to 
publish his phone number.  For many years, we tacitly agreed that our 
phone numbers would be published.  That a phone number was public 
information wasn't perceived as a problem.  But as the number of junk 
calls increases, the number of people who opt out of phone 
directories increases.  Today, more individuals decide that having a 
public phone number is a problem.


In this regard, public keys are just like cell phone numbers.  How 
many people know your cell phone number?  How did they get it?  You 
can't get a cell phone number from directory assistance.  So if you 
want someone to be able to call you on your cell phone, you have to 
give them the "key" to your cell phone.  If you want someone to send 
you encrypted email, you have to give them your public key.   It's 
the same thing.


Yet cell phones seem to be viable.

--

john noerenberg
  --
   It took long enough in all conscience for realization to come that
   the externals of civilization - technology, industry, commerce, and
   so on - also require a common basis of intellectual honesty and morality.
  -- Herman Hesse, The Glass Bead Game, 1943
  --

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[John Kelsey]

>From: Peter Saint-Andre <[EMAIL PROTECTED]>
>Sent: Feb 24, 2006 3:18 PM
>Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use

...
>We could just as well say that "encryption of remote server sessions is
>rare in everyday use". It's just that only geeks even do remote server
>sessions, so they use SSH instead of telnet.

>The thing is that email is in wide use (unlike remote server sessions).
>Personally I doubt that anything other than a small percentage of email
>will ever be signed, let alone encrypted (heck, most people on this list
>don't even sign their mail).

I'm certain that only a small percentage of e-mail will ever be
signed, so long as the tools to do that are so hard to use, and the
value added so small.  I find it useful to use encryption all the time
on my private data, but virtually never use it for communications,
because even among cryptographers the setup hassles are too great, and
the value added too small.  What we ultimately need is encryption and
authentication that are:

a.  Automatic and transparent.

b.  Add some value or are bundled with something that does.

c.  Don't try to tie into the whole horrible set of PKI standards in
terms of uniquely identifying each human and bit in the universe, and
getting them to sign legally binding messages whose full
interpretation requires reading and understanding a 30-page CPS.  

If email encryption became as transparent as SSL, most e-mail would be
encrypted.  This would still leave various phishing issues, etc., but
eavesdropping and a lot of impersonation and spam and phishing would
get much harder.  

>Peter

--John Kelsey


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Greg Black]

On 2006-02-24, Peter Saint-Andre wrote:

> Personally I doubt that anything other than a small percentage of email
> will ever be signed, let alone encrypted (heck, most people on this list
> don't even sign their mail).

That's at least partly because too many mailing lists either
reject signed messages out of hand or, worse, have subscribers
who use providers that reject signed messages and then spam you
with their idiotic bounce messages.  Keeping track of which
lists allow signed email and which don't is impractical if you
subscribe to hundreds of lists, so the simple thing is to tick
the "don't sign" box on list messages.

In this case, since Peter's message was signed, I know this list
allows signatures.  So I'll sign this message.

But the signature will be of limited utility, as not one of the
several email addresses on my signature is a match for the email
address I am sending this from.  Again, lists being what they
are, I use a different address for most lists and my PGP key
would become absurd if I added several hundred addresses to it.

I personally would prefer to sign every email I send.  I'd also
prefer to encrypt all non-public messages.  I am fully competent
in the use of the current technology, but it turns out to be not
practical to use.

Greg


pgp3qLCcQF5wT.pgp
Description: PGP signature

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

[Peter Saint-Andre]

Ian G wrote:

> To get people to do something they will say "no"
> to, we have to give them a freebie, and tie it
> to the unpleasantry.  E.g., in SSH, we get a better
> telnet, and there is only the encrypted version.

We could just as well say that "encryption of remote server sessions is
rare in everyday use". It's just that only geeks even do remote server
sessions, so they use SSH instead of telnet.

The thing is that email is in wide use (unlike remote server sessions).
Personally I doubt that anything other than a small percentage of email
will ever be signed, let alone encrypted (heck, most people on this list
don't even sign their mail).

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Ed Gerck]

Paul Hoffman wrote:
This is my original disagreement with Ed's message. It can be done, and 
when you do it it works, but it is too difficult for most people to 
bother with. I think we all agree on those three facts, just not on what 
to label the last one.


Actually, when I wrote "it does not actually work" I meant all three things:

1. It can't be done as a user would like to do it; note also that even experts
do it incorrectly (it's just too many detail devils).

2. When a user does it, the user does not really know if it was done right.

3. It is too difficult for users to use and (worse) most users who use it
do it incorrectly.

We have some choices. We can continue to say that it works and just wait
for users to get educated someday. Or, we can say that there is no x (x = 
market,
need, risk, point) -- and that's why no user bothers with it. Or, we can try
to understand what's it that users reject and work around it. My opinion I
already out upfront: users reject the whole model; it's not "natural" to
ask me for my envelope before you can send me a letter.

(btw, name and mail address are not the envelope -- they are routing
information. My public-key is the envelope analogue.)

Cheers,
Ed Gerck


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ed Gerck]

Ben Laurie wrote:

I don't use PGP - for email encryption I use enigmail, and getting
missing keys is as hard as pressing the "get missing keys" button.


Missing keys that do not exist or do not work (user forgot passphrase or
revoked) are still missing keys, no? Considering how few users use PGP,
we must assume that nearly all users have no keys.


Most of my encryption is done simply because its a good thing to do. If
the wrong guy is reading it I'll find out in the end. For the few where
I really care I'm prepared to go through that hassle.


After 15 years of PGP and PKI evolution, users still say it's just not working.
The problem seems to be the methods, not the implementations. Notwithstanding
people that do "the good thing".


Really? I just write "Ed Gerck" on an envelope and it gets to you? I
doubt it. Presumably I have to do all sorts of hard and user-unfriendly
things to find out and verify your address.


Perhaps I wasn't clear -- with postal mail you just write my name and address
in YOUR envelope and it gets to me. With PGP and PKI you have to ask for MY
"envelope" first; further, MY public-key creates the secure envelope that you
now need to trust with YOUR secret...

If you handled your keys properly I would not need to ask you for anything. 


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.

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.

Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ian G]

Steven M. Bellovin wrote:

Certainly, usability is an issue.  It hasn't been solved because 
there's no market for it here; far too few people care about email 
encryption.


Usability is the issue.  If I look over onto
my skype window, it says there are 5 million
or so users right now.  It did that without
any of the hullabaloo of the other systems,
and still manages to encrypt my comms.  By
some measures it is the most successful crypto
system ever.

Over on Ping's site there is this little essay
about something or other:

http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/

Which starts out:

  "So, right up front, here is the key property of this proposal:
   _using it is more convenient than not using it_. "

Which relates back to Kerchoffs' 6th principle.

To add to that:

To get people to do something they will say "no"
to, we have to give them a freebie, and tie it
to the unpleasantry.  E.g., in SSH, we get a better
telnet, and there is only the encrypted version.
In skype we get a cheaper phone call, and there
is only the encrypted version.

The problem with PGP is that there is no loss
leader in it, and it is possible to turn it off.
Same with SSL.  So that's what people do - they
say no.



iang

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Victor Duchovni]

On Fri, Feb 24, 2006 at 08:30:16AM -0800, Paul Hoffman wrote:

> >So PGP obviously has a usability and scalability problem.
> 
> Fully agree, and I would certainly extend that to S/MIME as well.
> 

One of the issues with S/MIME is that most mail clients have no useful
support for self-signed keys. I want to be able to generate a self-signed
key (ala PGP) and have my friends bind it mo my identity. Nothing in the
message format prevents me from doing that, but the products insist on
only trusting CAs, not keys. To generate keys for email to/from my wife I
configured my and her Thunderbird to treat each of us as a trusted CA :-(

-- 

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Travis H.]

On 2/23/06, Ed Gerck <[EMAIL PROTECTED]> wrote:
> Usability should by now be recognized as the key issue for security -
> namely, if users can't use it, it doesn't actually work.

There was an informative study on the usability of PGP, here if you
haven't seen it:
http://www.gaudior.net/alma/johnny.pdf

I think the integration with mailers like the one I saw (either
outlook or evolution) and graphical key managers like kgpg are almost
sufficiently easy to use, especially if one merely fetches a key from
a keyserver or webpage and trusts it is correct.

To do it properly, one would have to find a chain of keys from oneself
to the recipient.  There were a few attempts to do this in an
automated fashion (e.g. pathserver), and I have been intending to
write one that can deal with the myriad of key types, but have not yet
found time to do so.  In many cases, such a path may not exist.

I think the real issue here is that the perceived threat is low enough
that it doesn't justify the effort required to learn the concepts and
tools.  I tried to host a key-signing party here, and many people just
couldn't see the utility in attending.  I tried to explain the
benefits, but ultimately they decide if the benefits are worth the
effort, and I am not inclined to force my evaluations of utility onto
them, were it even possible.  Personally, I guess I enjoy the
challenge of doing things securely.

There's a maxim somewhere that security has to be done invisibly in
order to be successful.  I'm not sure, many people still have to
present passwords to log in, but it could be argued that they are in
large part not fully effective, due to various reasons.  I suppose it
depends on how you define "successful".

> And what I heard in the story is that even savvy users such as Phil Z
> (who'd have no problem with key management) don't use it often.

A friend once PGP-emailed Garfinkel, who literally wrote the book on
PGP (O'Reilly), and he asked him to re-send it without encryption.

One time I PGP-emailed somebody well-known in the security world, and
they said it was the first time they received an unsolicited
PGP-encrypted email.

Someone else wrote:
> Sure I can, but if you want it to be encrypted to you, then you need to
> publish a key.

Interestingly, IBE (identity-based encryption) does not have this
requirement.  Email addresses are valid public keys.  Obviously you
must trust the server, which is presumably hosted at your corporation
or ISP.

http://crypto.stanford.edu/ibe/

I'm not sure how much it really buys you; you basically have delegated
key generation to the server.  Does it avoid the need to get a "path"
to the recipient or their server?
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Victor Duchovni]

On Fri, Feb 24, 2006 at 01:44:14PM +, Ben Laurie wrote:

> Ed Gerck wrote:
> > Paul,
> > 
> > Usability should by now be recognized as the key issue for security -
> > namely, if users can't use it, it doesn't actually work.
> > 
> > And what I heard in the story is that even savvy users such as Phil Z
> > (who'd have no problem with key management) don't use it often.
> > 
> > BTW, just to show that usability is king, could you please send me an
> > encrypted email -- I even let you choose any secure method that you want.
> 
> Sure I can, but if you want it to be encrypted to you, then you need to
> publish a key.

More strongly, if we've never met, and you are not in the habit of
routinely signing email, thereby tying a key to your e-persona, it
makes no sense to speak of *secure* communication to *you*. Which "you"
would that be, the one who sent me all those exciting zip files of W32
executables, or the one I think is posting to this list?

The only identity you (who hypothetically do not garnish each message
with a signature) have is your mailbox. I can bootstrap that (with
questionable initial security) to a key via a "private" unencrypted
email message, and over a time as the key is consistently used grow to
associate the key with an on-line persona.

Is such a virtual persona what most people look for in "secure" email? I
think not, rather I think they are looking for secure email for the
eyes of real-world people, and so, in a strong sense ubiquitous secure
mail for the digital world in unattainable, because the underlying human
relationships do not exist. The world of digital relationships is much
broader than the world of personal real-world relationships...

I think that key management (while quite difficult) is not even the real
problem, the more intractable problem appears to be trust management:
how to distinguish a con from the real-thing... This problem is also
applicable to the real-world, but the digital manifestation is more
severe.

-- 

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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Paul Hoffman]

At 3:29 PM +0100 2/24/06, Philipp Gühring wrote:

 > Phil *does* have a problem with key management. He knows how to do

 it, but his communications partners are not as good as he is.


Phil Z doesn´t know how to do it himself, at least with PGP.
He told me that he doesn´t sign people´s keys who ask for it, simply because
it would pollute his keyring on his computer, and he couldn´t work with a
keyring with thousands of people on it anymore.


It is a bit harsh to equate "doesn't want to do it because of the 
hassle" with "doesn't know how to do it".


This is my original disagreement with Ed's message. It can be done, 
and when you do it it works, but it is too difficult for most people 
to bother with. I think we all agree on those three facts, just not 
on what to label the last one.



So PGP obviously has a usability and scalability problem.


Fully agree, and I would certainly extend that to S/MIME as well.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Ed Gerck wrote:
> Ben Laurie wrote:
>> Ed Gerck wrote:
>>> This IS one of the sticky points ;-) If postal mail would work this way,
>>> you'd have to ask me to send you an envelope before you can send me
>>> mail.
>>> This is counter-intuitive to users.
>>
>> We have keyservers for this (my chosen technology was PGP). If you liken
>> their use to looking up an address in an address book, this isn't hard
>> for users to grasp.
> 
> Well, the observation (as I hear the NPR piece) is that it HAS been hard
> to grasp.
> 
> Further, the comparison with "looking up an address in an address book" is
> also not even close to the level of hassle that users need to go through
> with
> PGP (and PKI). Please google "Why Johnny Can't Encrypt: A Usability
> Evaluation
> of PGP 5.0" and comments in the Usability section of
> 

I don't use PGP - for email encryption I use enigmail, and getting
missing keys is as hard as pressing the "get missing keys" button.

>>> Your next questions could well be how do you know my key is really
>>> mine...
>>> how do you know it was not revoked ...all of which are additional sticky
>>> points.
>>
>> For revocation, keyservers again. 
> 
> Last time I looked, a lot of PGP keys in keyservers are useless because
> users
> (most often) simply forgot their passphrase...

I guess I don't send people like that much encrypted email.

>> If I cared whether it was really yours
>> (I don't), then I'd check the signatures, or verify the fingerprint
>> out-of-band.
> 
> Out-of-band is good. But, again, the hassle factor...

Most of my encryption is done simply because its a good thing to do. If
the wrong guy is reading it I'll find out in the end. For the few where
I really care I'm prepared to go through that hassle.

>>> In the postal mail world, how'd you know the envelope is really from
>>> me or
>>> that it is secure?
>>
>> I don't.
> 
> Yes, but since you don't need to ask for one... no problem. You just use
> your
> own envelope to send postal mail to me.

Really? I just write "Ed Gerck" on an envelope and it gets to you? I
doubt it. Presumably I have to do all sorts of hard and user-unfriendly
things to find out and verify your address.

> The PKI problem is that it runs
> backwards
> to normal mail flow -- you need to ask me for my envelope before you can
> send me a
> secure message. IBE doesn't have this problem, even though it has key
> escrow.

If you handled your keys properly I would not need to ask you for anything.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ed Gerck]

Ben Laurie wrote:

Ed Gerck wrote:

This IS one of the sticky points ;-) If postal mail would work this way,
you'd have to ask me to send you an envelope before you can send me mail.
This is counter-intuitive to users.


We have keyservers for this (my chosen technology was PGP). If you liken
their use to looking up an address in an address book, this isn't hard
for users to grasp.


Well, the observation (as I hear the NPR piece) is that it HAS been hard
to grasp.

Further, the comparison with "looking up an address in an address book" is
also not even close to the level of hassle that users need to go through with
PGP (and PKI). Please google "Why Johnny Can't Encrypt: A Usability Evaluation
of PGP 5.0" and comments in the Usability section of





Your next questions could well be how do you know my key is really mine...
how do you know it was not revoked ...all of which are additional sticky
points.


For revocation, keyservers again. 


Last time I looked, a lot of PGP keys in keyservers are useless because users
(most often) simply forgot their passphrase...


If I cared whether it was really yours
(I don't), then I'd check the signatures, or verify the fingerprint
out-of-band.


Out-of-band is good. But, again, the hassle factor...


In the postal mail world, how'd you know the envelope is really from me or
that it is secure?


I don't.


Yes, but since you don't need to ask for one... no problem. You just use your
own envelope to send postal mail to me. The PKI problem is that it runs 
backwards
to normal mail flow -- you need to ask me for my envelope before you can send 
me a
secure message. IBE doesn't have this problem, even though it has key escrow.

Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[dan]

 > >> Usability should by now be recognized as the key issue for security -
 > >> namely, if users can't use it, it doesn't actually work.


% man gpg | wc -l
1705

% man gpg | grep dry
-n, --dry-run   Don't make any changes (this is not completely implemented).


I rest my case.

--dan


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Ed Gerck writes:

>This IS one of the sticky points ;-) If postal mail would work this way,
>you'd have to ask me to send you an envelope before you can send me mail.
>This is counter-intuitive to users.

I assumed that that was your point, which is why I figured you were 
trolling.  But of course, your analogy is precisely wrong -- I can look 
people's addresses, physical and electronic.  People who want to engage 
in secure communication publish their keys.  I haven't checked Paul's 
home page; Ben and I both have links to our PGP keys from our web pages.
You don't.
>
>Your next questions could well be how do you know my key is really mine...
>how do you know it was not revoked ...all of which are additional sticky point
>s.
>In the postal mail world, how'd you know the envelope is really from me or
>that it is secure?

Of course, you know even less about such things in the physical world.  
But you know that, too.  So what is your point?

Certainly, usability is an issue.  It hasn't been solved because 
there's no market for it here; far too few people care about email 
encryption.  And they're right -- their email is insecure, but given 
the environment of the typical desktop system would crypto do any good? 
We've already seen tailored worms stealing corporate information; we've 
also seen keystroke loggers and e-theft programs that watch for a login 
successful screen from your financial provider.  How would encrypting 
email help a businessman in an environment like that?  (I know -- have 
a separate machine used only for encrypting and decrypting files, and 
use a flash drive to carry ciphertext back and forth.  Talk about 
usability problems)

Yes, I can and do send encrypted email.  Statistically, I don't do it 
very often.  In all of last year, I sent four such messages, comprising 
exactly one conversation.  My effective security is locked-down hosts,
in particular the machine where sensitive inbound mail sits until I 
pull it down to my laptop.  This way, I don't have to trust my 
employer, my ISP, etc.  And I use SSL or SSH -- with checking of the 
far-side certificates -- for transport.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Stefan Kelm]

> I wonder now, why he didn´t tried to solve that usability/scalability problem 
> himself yet, but gave up instead.

Because it simply didn't cause too much pain to have
things changed. It's the same with those jolly ol'
PGP keyservers. They really, really are a mess but
they are more or less working so even after 15 years
or so they are still around, basically unchanged.

Cheers,

Stefan.

---
Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Ettlinger Strasse 12-14, D-76137 Karlsruhe

Tel. +49 721 255171-304, Fax +49 721 255171-100
[EMAIL PROTECTED], http://www.secorvo.de/
---
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Ed Gerck wrote:
> Ben Laurie wrote:
>> Ed Gerck wrote:
>>> Paul,
>>>
>>> Usability should by now be recognized as the key issue for security -
>>> namely, if users can't use it, it doesn't actually work.
>>>
>>> And what I heard in the story is that even savvy users such as Phil Z
>>> (who'd have no problem with key management) don't use it often.
>>>
>>> BTW, just to show that usability is king, could you please send me an
>>> encrypted email -- I even let you choose any secure method that you
>>> want.
>>
>> Sure I can, but if you want it to be encrypted to you, then you need to
>> publish a key.
> 
> This IS one of the sticky points ;-) If postal mail would work this way,
> you'd have to ask me to send you an envelope before you can send me mail.
> This is counter-intuitive to users.

We have keyservers for this (my chosen technology was PGP). If you liken
their use to looking up an address in an address book, this isn't hard
for users to grasp.

> Your next questions could well be how do you know my key is really mine...
> how do you know it was not revoked ...all of which are additional sticky
> points.

For revocation, keyservers again. If I cared whether it was really yours
(I don't), then I'd check the signatures, or verify the fingerprint
out-of-band.

> In the postal mail world, how'd you know the envelope is really from me or
> that it is secure?

I don't.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ed Gerck]

Ben Laurie wrote:

Ed Gerck wrote:

Paul,

Usability should by now be recognized as the key issue for security -
namely, if users can't use it, it doesn't actually work.

And what I heard in the story is that even savvy users such as Phil Z
(who'd have no problem with key management) don't use it often.

BTW, just to show that usability is king, could you please send me an
encrypted email -- I even let you choose any secure method that you want.


Sure I can, but if you want it to be encrypted to you, then you need to
publish a key.


This IS one of the sticky points ;-) If postal mail would work this way,
you'd have to ask me to send you an envelope before you can send me mail.
This is counter-intuitive to users.

Your next questions could well be how do you know my key is really mine...
how do you know it was not revoked ...all of which are additional sticky points.
In the postal mail world, how'd you know the envelope is really from me or
that it is secure?

Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Philipp Gühring]

Hi,

> >And what I heard in the story is that even savvy users such as Phil Z
> >(who'd have no problem with key management) don't use it often.

> Phil *does* have a problem with key management. He knows how to do
> it, but his communications partners are not as good as he is.

Phil Z doesn´t know how to do it himself, at least with PGP. 
He told me that he doesn´t sign people´s keys who ask for it, simply because 
it would pollute his keyring on his computer, and he couldn´t work with a 
keyring with thousands of people on it anymore. 
So PGP obviously has a usability and scalability problem.
So he only signs the keys of his friends because of that.
I wonder now, why he didn´t tried to solve that usability/scalability problem 
himself yet, but gave up instead.

Best regards,
Philipp Gühring


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ben Laurie]

Ed Gerck wrote:
> Paul,
> 
> Usability should by now be recognized as the key issue for security -
> namely, if users can't use it, it doesn't actually work.
> 
> And what I heard in the story is that even savvy users such as Phil Z
> (who'd have no problem with key management) don't use it often.
> 
> BTW, just to show that usability is king, could you please send me an
> encrypted email -- I even let you choose any secure method that you want.

Sure I can, but if you want it to be encrypted to you, then you need to
publish a key.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Paul Hoffman]

At 4:31 PM -0800 2/23/06, Ed Gerck wrote:

Usability should by now be recognized as the key issue for security -


Fully agree.


namely, if users can't use it, it doesn't actually work.


We disagree on the meaning of the phrase "actually work".


And what I heard in the story is that even savvy users such as Phil Z
(who'd have no problem with key management) don't use it often.


Phil *does* have a problem with key management. He knows how to do 
it, but his communications partners are not as good as he is.



BTW, just to show that usability is king, could you please send me an
encrypted email -- I even let you choose any secure method that you want.


Yes, I could. But I won't bother. :-)

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Ed Gerck]

Paul,

Usability should by now be recognized as the key issue for security -
namely, if users can't use it, it doesn't actually work.

And what I heard in the story is that even savvy users such as Phil Z
(who'd have no problem with key management) don't use it often.

BTW, just to show that usability is king, could you please send me an
encrypted email -- I even let you choose any secure method that you want.

Cheers,
Ed Gerck

Paul Hoffman wrote:

At 1:56 PM -0800 2/23/06, Ed Gerck wrote:
This story (in addition to the daily headlines) seems to make the case 
that
the available techniques for secure email (hushmail, outlook/pki and 
pgp) do

NOT actually work.


That's an incorrect assessment of the short piece. The story says that 
it does actually work but no one uses it. They briefly say why: key 
management. Not being easy enough to use is quite different than "NOT 
actually working".


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

[Paul Hoffman]

At 1:56 PM -0800 2/23/06, Ed Gerck wrote:

This story (in addition to the daily headlines) seems to make the case that
the available techniques for secure email (hushmail, outlook/pki and pgp) do
NOT actually work.


That's an incorrect assessment of the short piece. The story says 
that it does actually work but no one uses it. They briefly say why: 
key management. Not being easy enough to use is quite different than 
"NOT actually working".


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]