RE: HSM outage causes root CA key loss

2009-07-15 Thread Weger, B.M.M. de
Hi,

Our current Server CA certificate will expire in 2026 (when hopefully it
won't be my problem!).

Thus the universal CA root cert lifetime policy, the lifetime of a CA root
certificate is the time till retirement of the person in charge at its
creation, plus five years :-).

This neglects the not entirely unlikely possibility that long before your 
retirement
some clever person will have broken your cryptographic hash function or 
signature scheme.

I once saw a document refering to a PKI with a proposed certificate lifetime 
of 100 years. Those people really care about their grandchildren.

Grtz,
Benne
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: HSM outage causes root CA key loss

2009-07-14 Thread Weger, B.M.M. de
Hi,

 reports that the PKI for their electronic health card has 
 just run into
 trouble: they were storing the root CA key in an HSM, which 
 failed.  They now have a PKI with no CA key for signing new 
 certs or revoking existing ones.

Suppose this happens in a production environment of some CA
(root or not), how big a problem is this? I can see two issues:
- they have to build a new CA and distribute its certificate
  to all users, which is annoying and maybe costly but not a 
  security problem,
- if they rely on the CA for signing CRLs (or whatever 
  revocation mechanism they're using) then they have to find 
  some other way to revoke existing certificates.
No need to revoke any certificate.
Any other problems? Maybe something with key rollover or 
interoperability?

Seems to me that for signing CRLs it's better to have a separate 
Revocation Authority (whose certificate should be issued by 
the CA it is revoking for); then revoking can continue when the 
CA loses its private key. The CA still may have revoking 
authority as well, at least to revoke the Revocation Authority's 
certificate...

Grtz,
Benne de Weger

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: Property RIghts in Keys

2009-02-13 Thread Weger, B.M.M. de
Hi all,

 Say I have discovered a marvelous method of easily factoring 
 RSA keys, which unfortunately the margin of this emacs buffer 
 is too small to contain, and I then go out, factor GeoTrust's 
 CA key and issue a new certificate.
 
 Questions:
 
 Am I now infringing on GeoTrust's IP rights? Or have, rather, 
 I made myself a co-owner in said rights on this particular key?
 
 Have I broken any law? If not, should what I have done be illegal?

Here's a variant that I find interesting ;-). It's not about the 
public key but about the signature, another cryptograhic field
in a certificate that shares many properties with keys.

Say somebody has discovered a marvelous method of finding collisions
for a hash function. Then he creates two certificates, of which the
to-be-signed parts form a hash collision. Then he lets a CA sign 
one of them, and copies the signature into the other one, making
that a certificate that is indistinguishable from a valid one
issued by the CA. Has he broken any copyright law?

I admit this is a purely hypothetical case. Or... maybe it isn't?

Grtz,
Benne de Weger
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-11 Thread Weger, B.M.M. de
Hi Victor,

 Bottom line, anyone fielding a SHA-2 cert today is not going 
 to be happy with their costly pile of bits.

Will this situation have changed by the end of 2010 (that's
next year, by the way), when everybody who takes NIST seriously 
will have to switch to SHA-2? The first weakness shown in MD5
was not in 2004 but in 1995. Apparently it takes a very long
time before the awareness about the implications of using
weakened or broken crypto has reached a sufficient level. Though
I understand the practical issues you're talking about, Victor,
my bottom line is different.

In my view, the main lesson that the information security community, 
and in particular its intersection with the application building 
community, has to learn from the recent MD5 and SHA-1 history,
is that strategies for dealing with broken crypto need rethinking.

[[Maybe in the previous sentence the word intersection should be 
replaced by union.]]

Grtz,
Benne de Weger

PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) 
offering the video and audio files of the 25c3 presentation MD5 
considered harmful today, provide for integrity checking of those 
files their, uhm, MD5 hashes.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Short announcement: MD5 considered harmful today - Creating a rogue CA certificate

2008-12-30 Thread Weger, B.M.M. de
Hi all,

Today, 30 December 2008, at the 25th Annual Chaos Communication Congress in 
Berlin,
we announced that we are currently in possession of a rogue Certification
Authority certificate. This certificate will be accepted as valid and trusted 
by 
all common browsers, because it appears to be signed by one of the commercial 
root 
CAs that browsers trust by default. We were able to do so by constructing a 
collision for the MD5 hash function, obtaining a valid CA signature in a 
website 
certificate legitimately purchased from the commercial CA, and copying this 
signature into a CA certificate constructed by us such that the signature 
remains 
valid. 

For more information about this project, see 
http://www.win.tue.nl/hashclash/rogue-ca/.

The team consists of: 

Alexander Sotirov (independent security researcher, New York, USA), 
Marc Stevens (CWI, Amsterdam, NL), 
Jacob Appelbaum (Noisebridge, The Tor Project, San Francisco, USA), 
Arjen Lenstra (EPFL, Lausanne, CH), 
David Molnar(UCB, Berkeley, USA), 
Dag Arne Osvik (EPFL, Lausanne, CH), 
Benne de Weger (TU/e, Eindhoven, NL).

For press and general inquiries, please email md5-collisi...@phreedom.org.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RSA modulus record

2008-09-16 Thread Weger, B.M.M. de
Hi,

There's a new biggest known RSA modulus.
It is (in hexadecimal notation):

FF...(total of 9289166 F's)...FFDFF...(total of 1488985
F's)...FF800...(total of 9289165 0's)...001

It is guaranteed to be the product of two different large primes, 
and it has more than 80 million bits. Impressive security...

Grtz,
Benne de Weger

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


RE: PlayStation 3 predicts next US president

2007-12-02 Thread Weger, B.M.M. de
Hi William,

  ... We say so on
  the website. We did show this hiding of collisions for other data 
  formats, such as X.509 certificates
 
 More interesting.  Where on your web site?  I've long abhorred the
 X.509 format, and was a supporter of a more clean alternative.

See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/

  Our real work is chosen-prefix collisions combined with 
  multi-collisions. This is crypto, it has not been done before,
 
 Certainly it was done before! 

I was referring to MD5. Apart from that, I'd be interested in
seeing references to older work on chosen-prefix multicollisions.

 What *would* be crypto is the quantification of where MDx 
 currently falls on the computational spectrum.

Our first chosen-prefix collision attack has complexity of about
2^50, as described in our EuroCrypt 2007 paper. This has been 
considerably improved since then. In the full paper that is in
preparation we'll give details of those improvements.

Grtz,
Benne

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


RE: [Cfrg] Applications of target collisions: Pre or post-dating MD5-based RFC 3161 time-stamp tokens

2006-10-26 Thread Weger, B.M.M. de
Hi Steven,

 So how close are we getting to first or second preimage attacks?

As far as we know, not one bit closer. 
Best known attack on MD5 preimage resistance still is brute force. 

You may interpret our result as enlarging the applicability of 
collision attacks. In that sense the gap to preimage attacks has 
diminished. But we have no measure available to tell by how much.

Grtz,
Benne de Weger

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


SHA1 coll

2006-04-01 Thread Weger, B.M.M. de
Hi All,

The following two byte-strings (differing in a few bits only):
59 6F 75 20 61 72 65 20 41 70 72 69 6C 20 46 6F 6F 6C 20 6E 6F 2E 20 30
30 36 39 30 30 32 35 31 33 31 00
and
59 6F 75 20 61 72 65 20 41 70 72 69 6C 20 46 6F 6F 6C 20 6E 6F 2E 20 31
37 38 36 37 33 32 39 32 31 39 00
both have SHA-1 
20060401

For more explanation, visit
http://deweger.xs4all.nl/20060401.html

Grtz,
Benne de Weger

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


MD5 collisions in one minute

2006-03-17 Thread Weger, B.M.M. de
Hi all,

You might be interested in knowing that my MSc student
Marc Stevens has found a considerable speedup of MD5 
collision generation. His improvements of Wang's method
enables one to make MD5 collisions typically in one
minute on a PC; sometimes it takes a few minutes, and 
sometimes only a few seconds.
His paper (shortly to appear on the Cryptology ePrint
Archive) can be found on http://www.win.tue.nl/hashclash/,
where we've also made his software available (source code
and a Win32 executable).

Grtz,
Benne de Weger

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


RE: Nonrepudiation - in some sense

2006-02-11 Thread Weger, B.M.M. de
Hi all,

  server, and re-encrypting the information. Moreover, it
  maintains the non-repudiation of transactions since the
  encrypted communication is between client and application with
  no proxy acting as middleman.
 
 Firstly, even if you believe that _any_ crypto provides 
 non-repudiation
 (see http://www.apache-ssl.org/tech-legal.pdf for a paper I 
 co-authored
 on this and other stuff - executive summary: I don't believe it), you
 can't maintain the non-repudation of SSL because it doesn't provide
 non-repudation.
 
 Secondly, obviously, you can only decrypt SSL if you have the private
 key, so presumably this is referring only to incoming SSL connections.

Moreover, it seems to me that:
1. it is misleading (at least in general) to state that SSL operates 
   between client and application. SSL operates between client
(browser) 
   and (web) server; in many cases the real application might be on 
   another server, way behind the point where the SSL connection
terminates.
   Are there any SSL-aware applications (i.e. implementing business
logic
   rather than providing communication services) for which this solution
   may be useful?
2. it is misleading to state that SSL secures transactions. SSL
secures
   sessions. The authentication of SSL applies only to the session
handshake,
   not to the exchanged data, in which transaction data might be
present. 
   This is why (as Ben remarks) SSL does not provide non-repudiation.
3. with this solution you need your private key in at least two
different 
   places. This introduces essentially more complicated key management,
   and increases the risk of key compromise.

Grtz,
Benne de Weger

=
Technische Universiteit Eindhoven
Coding  Crypto Groep
Faculteit Wiskunde en Informatica
Den Dolech 2
Postbus 513
5600 MB Eindhoven
kamer:  HG 9.84
tel.:   (040) 247 2704, bgg 5141
e-mail: [EMAIL PROTECTED]
www:http://www.win.tue.nl/~bdeweger
=

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


RE: Collisions for hash functions: how to exlain them to your boss

2005-06-13 Thread Weger, B.M.M. de
Hi Eric,

Technically speaking you're correct, they're signing a program.
But most people, certainly non-techies like Alice's boss,
view postscript (or MS Word, or name your favourite document 
format that allows macros) files not as programs but as static 
data. In being targeted at non-techies I find this attack more 
convincing than those of Mikle and Kaminsky, though essentially
it's a very similar idea.

Note that opening the postscript files in an ASCII-editor
(or HEX-editor) immediately reveals the attack. Stefan Lucks
told me they might be able to obfuscate the postscript code, 
but again this will only fool the superficial auditor.

Grtz,
Benne

= 
Technische Universiteit Eindhoven 
Coding  Crypto Groep 
Faculteit Wiskunde en Informatica 
Den Dolech 2 
Postbus 513 
5600 MB Eindhoven 
kamer HG 9.84 
tel. (040) 247 2704, bgg 5141 
e-mail: [EMAIL PROTECTED] 
www: http://www.win.tue.nl/~bdeweger 
= 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla
 Sent: maandag 13 juni 2005 17:05
 To: Stefan Lucks
 Cc: cryptography@metzdowd.com
 Subject: Re: Collisions for hash functions: how to exlain 
 them to your boss
 
 Stefan Lucks [EMAIL PROTECTED] writes:
  Magnus Daum and myself have generated MD5-collisons for 
 PostScript files:
 
http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/
 
  This work is somewhat similar to the work from Mikle and 
 Kaminsky, except 
  that our colliding files are not executables, but real documents. 
 
  We hope to demonstrate how serious hash function collisions 
 should be 
  taken -- even for people without much technical background. 
 And to help 
  you, to explain these issues 
 
- to your boss or your management,
- to your customers,
- to your children ...
 
 While this is a clever idea, I'm not sure that it means what you imply
 it means. The primary thing that makes your attack work is that the
 victim is signing a program which he is only able to observe mediated
 through his viewer. But once you're willing to do that, you've got a
 problem even in the absence of collisions, because it's easy to write
 a program which shows different users different content even if you
 without hash collisions. You just need to be able to write
 conditionals.
 
 For more, including an example, see:
 http://www.educatedguesswork.org/movabletype/archives/2005/06/
 md5_collisions.html
 
 -Ekr
 
 
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to 
 [EMAIL PROTECTED]
 

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


Anti-colliding certificates

2005-05-21 Thread Weger, B.M.M. de
Hi All,
 
It's nice to see that my message on anti-colliding certificates finally
got through.
To fully appreciate its contents you should set back your internal clock

to the date the message was originally sent.
 
Grtz,
Benne de Weger

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


RE: Colliding X.509 Certificates

2005-03-15 Thread Weger, B.M.M. de
Hi Joerg,

 My concern is not MD5, its SHA-1. I don't see that we can get rid of 
 SHA-1 in certificates in the next 5 years:
 * None of the alternatives is widely implemented today.
 * For controlled environments like in-house applications you might be 
 able to switch earlier (0-2 years).
 * In open environments like inter company S/MIME or public facing SSL 
 servers it will take years before you can assume that people 
 are able to 
 verify non SHA-1 certs.
 * For CA certificates you'll have to add more years (not to 
 speak about 
   those CA certs with notAfter=2038).

  From this perspective it makes sense to think about 
 operating a CA with 
 a broken hash function, I believe.
 * Technically SHA-1 is broken today.
 * I don't fear that anybody might attack my CA based on the 
 attack known 
 today.
 * But given the progress in the last year I personally expect the 
 attacks on SHA-1 to get more practical.

It makes sense to do a risk analysis, based on a.o.
* how critical is the particular application to the business
* what threats are there (who might try something bad)
* what's the user community (in-house or the entire world or
  something in between)
and then accept a certain residual risk of continuing the use of
'broken' hash functions for some more time. 

At the same time it is wise to start deploying better hash functions. 
I hope the Microsofts and Suns and name your favourite software
factory of this world are working on this right now. It's clear that 
this is going to take a long time and cost a lot of money. We're very 
lucky that the present attacks are still to a large extent theoretical 
in nature, and do not (yet) lead to realistic attack scenarios (at 
least we couldn't think of one, and we haven't seen anybody else 
coming up with one).

The main lesson to be learnt here is that we have made our systems 
too dependent on a few cryptographic primitives only; much more
flexibility is needed. One of these days some smart person may come 
up with a real attack on name your favorite cryptographic primitive,
then you cannot afford two years to change your systems.

So I still think that the message we should send into the world is
to phase out MD5 now, and SHA-1 a.s.a.p. (NIST says: by 2010, that 
sounds very long to me). If you cannot do that for practical reasons, 
then that's your risk. When you accept that risk, that's fine with me.
 
Apart from that I've never understood why there are CA certificates 
with such incredibly long lifetimes. That's simply asking for trouble.

  A relying party cannot find out from the certificate alone whether
  it has a twin sister or not. The fact that there is a 
 random-looking
  serial number doesn't help you there.
 That is true, and its certainly not nice. But I think the 
 real concern 
 of the relying party is not specifically about certificates with the 
 same hash, its about
 * the correctness of the contents (name of private key holder 
 etc.) and
 * the existance of other certificates issued to same key but 
 different 
 name, which might be used to repudiate signatures, e.g.
 
 The relying party always needs to trust the CA on those two 
 properties, 
 as the CA can easily issue certs with incorrect conents, it 
 doesn't need 
 hash collisions for that.
 
 My question is: Can a CA prevent twin sisters from coming into 
 existance by using my proposed procedure?

With current knowledge the answer is: yes. Randomized serial numbers 
will be sufficient. And indeed: a CA doesn't need hash collisions
to do real damage. 

Grtz,
Benne

= 
Technische Universiteit Eindhoven 
Coding  Crypto Groep 
Faculteit Wiskunde en Informatica 
Den Dolech 2 
Postbus 513 
5600 MB Eindhoven 
kamer HG 9.84 
www: http://www.win.tue.nl/~bdeweger 
= 
 

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


RE: Colliding X.509 Certificates

2005-03-13 Thread Weger, B.M.M. de
Hi Joerg,

It's true that our 'attack' assumes that the attacker has sufficient
control over the CA, in particular over setting DN's, serial numbers 
and the validity period. Yet I have a few remarks on this.

A relying party cannot find out from the certificate alone whether
it has a twin sister or not. The fact that there is a random-looking
serial number doesn't help you there.

A newly issued certificate based on MD5 should not be trusted anymore 
anyway. The only reasonable measure against collision-based attacks is 
to declare MD5 dead. It's better to bury it than to try keeping it alive.
I have nothing against randomized serial numbers. But your security 
should be based on better ideas. And it's just as easy to avoid broken 
hash functions.

Grtz,
Benne de Weger

 -Original Message-
 From: Joerg Schneider [mailto:[EMAIL PROTECTED] 
 Sent: vrijdag 11 maart 2005 11:52
 To: Olle Mulmo
 Cc: Weger, B.M.M. de; cryptography@metzdowd.com
 Subject: Re: Colliding X.509 Certificates
 
 Olle Mulmo wrote:
  Seems to me that a CA can nullify this attack by choosing a serial 
 number or RDN component (after all, a CA should vet the DN and not 
 simply sign what's in the PKCS#10 request), such that the public key 
 does not end up at an appropriate DER-encoded offset in the
  certificate. Or am I completely lost?
 
 Yes, there seem to several possibilities to defend against 
 this kind of 
 attack in a real world scenario. Modifying the subject DN in a way
 un-predictable by the attacker is one of them. For Benne's 
 attack it would
 be enough to modify its length, so that the public key 
 doesn't get to the
 required offset.
 
 I would like to have a general way to fend off collision attacks on
 certificates. To this end I propose that the CA generates the 
 certificate
 serialNumber in a way that cannot be guessed. Some CAs are 
 already doing
 this, I guess mainly to prevent people from seeing how many certs they
 issue.
 
 There are several advantages of using the serialNumber:
 * it has no semantics that we might break, as long as we make sure it
 stays unique
 * it is one of the first items in a certificates, before any 
 content an
 attacker might control
 * its no problem to make it e.g. 128 bits long
 
 By putting an un-guessable value in the serialNumber, the attacker is
 faced with a similar problem as with a HMAC, which people 
 believe are not
 affected by the known collision attacks. For this reason I 
 believe with
 un-guessable serialNumbers, we should be safe to use a hash function,
 which is not collision resistant, as long as it is 2nd pre-image
 resistant.
 
 Its rather easy to implement un-guessable servialNumbers:
 * use a cryptographically strong PRNG (and keep the seed 
 secret) or TRNG
 * encrypt a counter with a block cipher (and keep the key secret)
 
 Best regards,
 
 Jörg
 
 

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


Colliding X.509 Certificates

2005-03-03 Thread Weger, B.M.M. de
Hi all,

We announce the construction of two different valid X.509 certificates
that have identical signatures. This is based on MD5 collisions.

One could e.g. construct the to-be-signed parts of the certificates,
and get the one certificate signed by a CA. Then a valid signature for 
the other certificate is obtained, while the CA has not seen proof of 
possession of the private key of this second certificate. 

The certificates we constructed can be downloaded from
http://www.win.tue.nl/~bdeweger/CollidingCertificates/.
From this site some more technical information can be downloaded as
well.

We provide a short paper explaining in detail our method.
It is available on the website, and on the Cryptology ePrint Archive,
at http://eprint.iacr.org/2005/067.

This is joint work with Arjen Lenstra (Lucent Bell Labs and TU
Eindhoven)
and Xiaoyun Wang (Shandong University).

Grtz,
Benne de Weger

= 
Technische Universiteit Eindhoven 
Coding  Crypto Groep 
Faculteit Wiskunde en Informatica 
Den Dolech 2 
Postbus 513 
5600 MB Eindhoven 
e-mail: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] 
www: http://www.win.tue.nl/~bdeweger 
= 


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


RE: public-key: the wrong model for email?

2004-09-16 Thread Weger, B.M.M. de
Hi Ed,

What about ID-based crypto: the public key can be any string, such as
your e-mail address. So the sender can encrypt even before the
recipient has a key pair. The private key is derived from the
public key by a trusted party when the recipient asks for it.
Yes, the recipient does have some burden here, but it seems to
me that that is unavoidable.
I'm not saying that this is without problems (private key distribution,
inherent key escrow / recovery, revocation issues), or that it's easier 
manageable than traditional PKI, but it may solve some of your issues.

The idea for ID-based crypto comes from Adi Shamir, back in 1984.
The first practical and mathematically sound realisation is due to
Boneh and Franklin (Crypto 2001), and is brought to the market
by Voltage (www.voltage.com). I don't know their products, only that
it exists, and I'm not a shareholder. I do think it's interesting
math and interesting crypto, and that it could lead to interesting 
technology.

Grtz,
Benne de Weger

= 
Technische Universiteit Eindhoven 
Coding  Crypto Groep 
Faculteit Wiskunde en Informatica 
Den Dolech 2 
Postbus 513 
5600 MB Eindhoven 
kamer HG 9.84 
tel. (040) 247 2704, bgg 5141 
e-mail: [EMAIL PROTECTED] 
www: http://www.win.tue.nl/~bdeweger 
= 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gerck
 Sent: woensdag 15 september 2004 20:39
 To: [EMAIL PROTECTED]
 Subject: public-key: the wrong model for email?
 
 [Perry: please use this version, if possible]
 
 Public-key cryptography burdens the recipient and puts the 
 recipient in charge, while the sender is at the recipient's 
 mercy. Is this the right model for email security? After all, 
 the sender is the party at risk.
 
 To clarify, my comment is not that PKC is not useful for 
 email. I believe it is, but not directly used as it is today.
 
 What I am saying is that the problem is key distribution. I 
 want to separate the key distribution solution as directly 
 done by PKC today (send the public-key) from a possible 
 general solution for PKC key distribution that does not 
 require sending the public-key. The point is that when PKC 
 solves this problem directly, it solves it in a way that's 
 useful for webservers (the webserver does not have to trust 
 the client's certificate) but presents difficulties for email 
 senders (the sender has to trust the recipient's 
 certificate). Email use of PKC treats the recipient as a server.
 
 I think that what we need is a key distribution method for 
 email (that can still use PKC and PKI) where, because the 
 sender has all the risk, the sender defines how email is 
 secured and delivered. The recipient should always be able to 
 receive it, without too much burden or required previous work.
 
 For example, let's see how FedEx works. The sender chooses 
 the service and the type of envelope to protect the message. 
 The sender also chooses the instructions that must be 
 followed before the envelope can be opened by the recipient.
 The recipient has no charge to pay for, or burden, in order 
 to receive the envelope, and does not have to do anything 
 before the envelope is sent. The recipient is able to verify 
 the identity of the sender and, if so desired, refuse the 
 envelope. The recipient can open the envelope if and only if 
 the recipient is willing to follow the sender's instructions 
 (e.g., providing name, address, date, signature).
 
 Yes, SSL and public-key encryption are and continue to be a 
 success for web servers. However, the security model for 
 protecting email with public-key cryptography seems to be 
 backwards, technically and business wise. The sender, who is 
 the party at risk, has to trust a lock provided by the recipient (his
 public-key) to protect her secrets (the message). If FedEx 
 would provide message security a la PGP, PGP/MIME or S/MIME 
 email, the sender would have to convince the recipient to pay 
 and send in advance an envelope for the sender to use.
 The sender, however, would never know whether the envelope 
 indeed prevented others from prying into its contents.
 
 A better situation would arise if the lock (i.e., the 
 envelope) would be controlled by the sender. Moreover, the 
 recipient is not the business driver who needs to provide, 
 pay for and protect the lock. The sender is the party who has 
 the motivation to spend money to provide and protect the lock.
 
 In short, I find that public-key cryptography cannot solve 
 the security issues of email when used as it is today and, 
 most importantly, cannot provide the needed motivation for 
 users, senders and recipients, to buy into it.
 
 It's not a matter of improvements in usability, better 
 pricing or user education [1]. It simply does not work as it 
 should work. That's also why, IMO, it does not take off. It 
 is using the wrong mathematics for the problem.
 
 Does