Opinions on S/MIME

4 views
Skip to first unread message

Sam Simpson

unread,
Dec 29, 1998, 3:00:00 AM12/29/98
to
Brad,

I am currently working on a PGP FAQ comparing the security old (RSA) version
of PGP with the new (DH) version.

This FAQ also contains a section covering the crypto security of S/Mime.

The section was (literally!) typed last night and as such suffers from my
usual pre-review bad grammar and spelling.

Still, should give you something to get on with!


Comments / suggestions appreciated,


Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.

5.15. How does the cryptographic security of the PGP & S/Mime standards
compare?

The following table identifies the algorithms mandated (as “MUST”
algorithms) in S/Mime (v3) [IETF98] and OpenPGP [RFC2440]:

------------------------------------------------------------------
OpenPGP v1 S/Mime v3
------------------------------------------------------------------
Symmetric Algorithm 3DES (CFB) 3DES (CBC) & RC2/40
PK Algorithm (encryption) ElGamal (4096) DH (1024)
Signature Algorithm DSS DSS
Hash Function SHA-1 SHA-1
------------------------------------------------------------------


Of course, it is the implementation of the standard that dictates the
security, not the “theoretical” standard. (Note that ElGamal & DH are
equivalent – see Note 1). Readers who are confused by the significance of
“MUST” in IETF documents are referred to [RFC2119].

Asymmetric key size is of great importance in PGP and S/Mime. The following
table, from [Sch96] lists the recommended public key length to protect
against attack by a single corporation (keys should be substantially bigger
to protect against intelligence agencies!):

--------------------------------------
Year Recommended Key Length
--------------------------------------
1995 1280
2000 1280
2005 1536
2010 1536
2015 2048
--------------------------------------

So...The S/Mime standard specifies a maximum public key length of 1024-bits,
which according to the table above doesn’t offer sufficient long-term
protection against a determined corporation! The PGP standard, and the NAI
implementation of the standard, allows public keys of up to 4096 bits, which
should protect data for the foreseeable future.

ANSI X9F1 mandates 1024-bit minimum key-length for RSA and DH, but S/Mime
only supports keys sizes of *up to* 1024-bits.

Some would argue that future versions of the S/Mime standard could possibly
mandate keys greater than 1024-bits. That means that a determined and
well-funded adversary could read your current private communications within
5 years or so.

One of the S/Mime standard documents [PKIX98] describes a "feature" of
S/Mime called "Proof of Possession of Private Key". This is a mechanism
whereby end users private keys are deposited with the CA when certification
is requested. This is a very worrying inclusion and makes the
implementation of mandatory key escrow a trivial matter. The PGP draft
standard contains no such references to key recovery technology.

For completeness I note that PGP specifies the CFB chaining mode whilst
S/Mime mandates CBC mode. Both of these modes equivalent [Sch96], [MOV96]
assuming that a unique IV can be provided in CFB mode. PGP already
implements a random number generator (RNG); thus supplying this IV is not a
concern. PGP implements CFB mode in order to produce a fixed width data
encipherment from an arbitrary length block cipher (one notes that DES, IDEA
& CAST have a 64-bit block size, whilst the AES standard calls for a 128-bit
block size).

Of course, one can apply Bayesian Decision Theory to the implementations of
PGP and S/Mime. PGP source code has been subjected to literally thousands
of hours of analysis by independent, respected cryptographers. No such
analysis can be made of S/Mime implementations since the source code is not
distributed.

Since we can't prove there are no weaknesses in either implementation, the
Bayesian probability of there being such weakness is a straightforward
function of the expert man-hours spent searching for them. One doesn't have
to assert there ARE such weaknesses to make this argument. Thus the
posterior risk in using PGP is less than the risk in using S/Mime
implementations that are not available with source. It's straightforward
applied statistical decision theory. (Thank you for the point David
Sternlight :-;).

Importantly, non US S/Mime users are provided with the RC2/40 symmetric
cipher which has a key length of 40-bits and asymmetric ciphers <=512-bits
which is clearly insecure. From [IETF98]: “40-bit encryption is considered
weak by most cryptographers. Using weak cryptography in S/MIME offers
little actual security over sending plaintext.” Bruce Schneier offers a
screen saver which brute forces 40-bit keys using the idle time on a
standard PC.

PGP uses symmetric keys of 128-bits and asymmetric keys of up to 4096-bits
irrespective of the locale. Thus users of PGP can communicate securely
globally whereas S/Mime users currently can’t.

From a security perspective, PGP can rightfully be considered more secure
than S/Mime for the following reasons:

a) S/Mime is limited to 1024-bit public keys; PGP can accommodate keys
of up to 4096-bits.

b) The S/Mime certification standard contains facilities that can be
used easily for mandatory escrow. No such feature is present in the PGP
standard.

c) PGP implementations are open to and are subjected to extensive peer
review. Users of S/Mime have to trust the implementation. To quote the NSA
“...most security failures in its area of interest are due to failures in
implementation, not failure in algorithms or protocols” [Sch96]. So, as
part of the export licensing procedure, the NSA can review the S/Mime
implementation and thus exploit any weaknesses, but the end users aren’t
afforded this privilege.

d) Non-US users of S/Mime can only use 40-bit symmetric keys which,
according to the S/Mime documentation [IETF98]: “offers little actual
security over sending plaintext.”

Brad Aisa wrote in message <3688538B...@istar.ca>...
>Hello,
>
>I am interested in opinions on the S/MIME system for email/usenet
>authentication and (email) encryption.
>
>Also, is it typical for S/MIME signatures to be invalidated when a
>message is passed through an automoderation bot onto a mailing list or
>moderated newsgroup? Does PGP suffer from this problem?
>
>thanks
>
>--
>Brad Aisa
>ba...@NOSPAMistar.ca
>S/MIME signed using freemail ID from www.thawte.com
>
>"Laissez faire."

Roger Schlafly

unread,
Dec 29, 1998, 3:00:00 AM12/29/98
to

Sam Simpson wrote in message <36889...@nnrp1.news.uk.psi.net>...

>Asymmetric key size is of great importance in PGP and S/Mime. The
following
>table, from [Sch96] lists the recommended public key length to protect
>against attack by a single corporation (keys should be substantially bigger
>to protect against intelligence agencies!):
>
> --------------------------------------
> Year Recommended Key Length
> --------------------------------------
> 1995 1280
> 2000 1280
> 2005 1536
> 2010 1536
> 2015 2048
> --------------------------------------

I don't know that reference, but these recommendations seem quite
paranoid to me. No one has publicly broken a 512-bit RSA key yet.
Breaking a 512-bit DSA key is significantly more difficult.

By my estimates, breaking a 1280-bit key is about a billion times
more work. This is way out range for anyone today.


Roger Schlafly

unread,
Dec 29, 1998, 3:00:00 AM12/29/98
to

Brad Aisa wrote in message <36895AE6...@istar.ca>...
>Excuse my possible ignorance, but I am assuming that the association of
>key lengths with dates is not supposed to mean that someone can
>effectively break the messages on those dates, only that they may very
>well be able to break the messages some fairly small number of years
>*after* the date, if they were encrypted using the indicated key
>lengths.

I suppose. Some people want to protect data for a few minutes, and
others for many years. Either way, I don't see the justification for the
rapid increase in key length, unless you think computers are going
to get 5 times as fast, every years, for many years.


Rich Ankney

unread,
Dec 30, 1998, 3:00:00 AM12/30/98
to
This is from the PKIX (not S/MIME) RFC set. Sam is not quite correct that
Proof of Possession (PoP) is the same as sending your private key to the
CA. PoP allows the user to prove to the CA that he knows a private key
(e.g., sign a challenge with your private key, decrypt a challenge with
your
private key, etc.). The ability to archive your private key IS an OPTIONAL
part
of both PKIX certificate management protocols (CMP and CMC) but is not
the same as PoP.

Regards,
Rich

Brad Aisa <ba...@istar.ca> wrote in article <36895A20...@istar.ca>...
> Sam,
>
> Thanks for your detailed and instructive response. The thing that most
> disturbed me (apart from the 1024-bit key limit), was this:


>
> Sam Simpson wrote:
>
> > One of the S/Mime standard documents [PKIX98] describes a "feature" of
> > S/Mime called "Proof of Possession of Private Key". This is a
mechanism
> > whereby end users private keys are deposited with the CA when
certification
> > is requested. This is a very worrying inclusion and makes the
> > implementation of mandatory key escrow a trivial matter. The PGP draft
> > standard contains no such references to key recovery technology.
>

> Does this mean that when I obtained a certificate from Thawte, that my
> *private key* was transmitted to them???
>
> Please tell me it ain't so...

Sam Simpson

unread,
Dec 30, 1998, 3:00:00 AM12/30/98
to
Roger,

The table was taken from Applied Cryptography. The figures do seem
conservative, but "bits are cheap" these days....

Once again, my apologies for the "draftness" of the previous post.

Once quick question; you state that "Breaking a 512-bit DSA key is
significantly more difficult. [than an RSA key]". Could you please explain
(in laymen terms - I'm not that bright <g>). I thought ElGamal and RSA keys
of the same length were thought to be equivalently secure?

Thanks in advance,


Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.


Roger Schlafly wrote in message <76b9g1$d...@enews4.newsguy.com>...


>
>Sam Simpson wrote in message <36889...@nnrp1.news.uk.psi.net>...

>>Asymmetric key size is of great importance in PGP and S/Mime. The
>following
>>table, from [Sch96] lists the recommended public key length to protect
>>against attack by a single corporation (keys should be substantially
bigger
>>to protect against intelligence agencies!):
>>
>> --------------------------------------
>> Year Recommended Key Length
>> --------------------------------------
>> 1995 1280
>> 2000 1280
>> 2005 1536
>> 2010 1536
>> 2015 2048
>> --------------------------------------
>

Roger Schlafly

unread,
Dec 30, 1998, 3:00:00 AM12/30/98
to

Sam Simpson wrote in message <3689f...@nnrp1.news.uk.psi.net>...

>Once quick question; you state that "Breaking a 512-bit DSA key is
>significantly more difficult. [than an RSA key]". Could you please explain
>(in laymen terms - I'm not that bright <g>). I thought ElGamal and RSA
keys
>of the same length were thought to be equivalently secure?

The asymptotics are similar. But breaking DH (ElGamal or DSA) requires some
large tables. Much larger RSA keys have been broken than DH keys.


Sam Simpson

unread,
Dec 31, 1998, 3:00:00 AM12/31/98
to
Rich,

Thanks for the additional information. I appreciate the need for the
individual to prove to the CA that they are in possession of the private key
in order to stop some attacks, but having an "archive private key field"
seems like mandatory escrow waiting to happen.


Thanks again,

Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.

Rich Ankney wrote in message
<01be3389$6b161ce0$a824...@fujitsu1.ny.certco.com>...


>This is from the PKIX (not S/MIME) RFC set. Sam is not quite correct that
>Proof of Possession (PoP) is the same as sending your private key to the
>CA. PoP allows the user to prove to the CA that he knows a private key
>(e.g., sign a challenge with your private key, decrypt a challenge with
>your
>private key, etc.). The ability to archive your private key IS an OPTIONAL
>part
>of both PKIX certificate management protocols (CMP and CMC) but is not
>the same as PoP.
>
>Regards,
>Rich
>
>Brad Aisa <ba...@istar.ca> wrote in article <36895A20...@istar.ca>...
>> Sam,
>>
>> Thanks for your detailed and instructive response. The thing that most
>> disturbed me (apart from the 1024-bit key limit), was this:
>>
>> Sam Simpson wrote:
>>

>> > One of the S/Mime standard documents [PKIX98] describes a "feature" of
>> > S/Mime called "Proof of Possession of Private Key". This is a
>mechanism
>> > whereby end users private keys are deposited with the CA when
>certification
>> > is requested. This is a very worrying inclusion and makes the
>> > implementation of mandatory key escrow a trivial matter. The PGP draft
>> > standard contains no such references to key recovery technology.
>>

>> Does this mean that when I obtained a certificate from Thawte, that my
>> *private key* was transmitted to them???
>>
>> Please tell me it ain't so...
>>

Sam Simpson

unread,
Dec 31, 1998, 3:00:00 AM12/31/98
to

Ah, I see. But creating the large tables is a "one off" process for each
field right?

Thanks again,


Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.


Roger Schlafly wrote in message <76ekuo$p...@darkstar.ucsc.edu>...

Peter Gutmann

unread,
Jan 1, 1999, 3:00:00 AM1/1/99
to
"Rich Ankney" <ran...@erols.com> writes:

>This is from the PKIX (not S/MIME) RFC set. Sam is not quite correct that
>Proof of Possession (PoP) is the same as sending your private key to the
>CA. PoP allows the user to prove to the CA that he knows a private key
>(e.g., sign a challenge with your private key, decrypt a challenge with
>your
>private key, etc.). The ability to archive your private key IS an OPTIONAL
>part
>of both PKIX certificate management protocols (CMP and CMC) but is not
>the same as PoP.

Since several governments (principally the US) have been trying to implement
some form of GAK for years, and failing miserably (initially with Clipper,
more recently with the Committee to Develop a Federal Information Processing
Standard for the Federal Key Management Infrastructure farce where members
were asked to resign at the final meeting so a quorum could be achieved). If
the IETF is going to build a GAK-ready system for them, how long do you think
it'll take before its use becomes mandated by law? The UK is trying to do
this right now, and their GAK uses the PKIX protocols to get at users keys.
It doesn't matter what the IETF says about the matter, if you build it...

Peter.


Ed Stone

unread,
Jan 1, 1999, 3:00:00 AM1/1/99
to
In article <76ibsf$lfl$1...@scream.auckland.ac.nz>,
pgu...@cs.auckland.ac.nz says...
"POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- posession is proven in this message (which contains the private
-- key itself (encrypted for the CA))"

Source: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crmf-01.txt
--
--
-------------------------------
Ed Stone
est...@synernet-robin.com
remove "-birdname" spam avoider
-------------------------------

Arnoud Galactus Engelfriet

unread,
Jan 2, 1999, 3:00:00 AM1/2/99
to
In article <368b4...@nnrp1.news.uk.psi.net>,

"Sam Simpson" <ssim...@hertreg.ac.uk> wrote:
> Thanks for the additional information. I appreciate the need for the
> individual to prove to the CA that they are in possession of the private key
> in order to stop some attacks, but having an "archive private key field"
> seems like mandatory escrow waiting to happen.

For authentication-only systems, that's not likely. All European
proposals I've read state quite explicitly that "private keys for
authentication shall not be archived." Perhaps the Americans think
differently about this.

The big problem with archiving secret keys for authentication is
that it is no longer possible to guarantee that only the real owner
of the secret key could have created the signature. This makes it
impossible to provide non-repudiation services, since the owner can
now always claim that the CA must have compromised its copy of the
secret key. In a normal setup, only the owner has the secret key, so
any compromise is the fault of the owner, so it is only his
responsibility to handle this.

Greetings,

Arnoud

--
\/ Arnoud "Galactus" Engelfriet - gala...@stack.nl This space
5th year Business & Computing Science student left blank
URL: http://www.stack.nl/~galactus/ PGP: 0x416A1A35 intentionally.


Larry Kilgallen

unread,
Jan 2, 1999, 3:00:00 AM1/2/99
to
In article <o1gj24uY...@stack.nl>, gala...@stack.nl (Arnoud "Galactus" Engelfriet) writes:
> In article <368b4...@nnrp1.news.uk.psi.net>,
> "Sam Simpson" <ssim...@hertreg.ac.uk> wrote:
>> Thanks for the additional information. I appreciate the need for the
>> individual to prove to the CA that they are in possession of the private key
>> in order to stop some attacks, but having an "archive private key field"
>> seems like mandatory escrow waiting to happen.
>
> For authentication-only systems, that's not likely. All European
> proposals I've read state quite explicitly that "private keys for
> authentication shall not be archived." Perhaps the Americans think
> differently about this.

Please do not confuse "Americans" with "US citizens" or "US citizens"
with "US authorities" :-).

My understanding is that it was precisely the different archive goals
that caused X509v3 to allow separate signature and privacy keys.

Larry Kilgallen

Lyal Collins

unread,
Jan 3, 1999, 3:00:00 AM1/3/99
to
Please define your understanding of "normal setup"
At least one Australian commercial CA generates keypairs for the
applicant/end-user.
It would seem this is justified on the grounds of ensuring the key pairs are
random and properly created (sorry if I use the term somewhat loosely)

Most commercial "off the shelf packages" I've seen have no accreditation of
the key generation process (or encryption/signing processe) - so this
approach has some validity from one perspective.

Lyal

Arnoud "Galactus" Engelfriet wrote in message ...


>In article <368b4...@nnrp1.news.uk.psi.net>,
>"Sam Simpson" <ssim...@hertreg.ac.uk> wrote:
>> Thanks for the additional information. I appreciate the need for the
>> individual to prove to the CA that they are in possession of the private
key
>> in order to stop some attacks, but having an "archive private key field"
>> seems like mandatory escrow waiting to happen.
>
>For authentication-only systems, that's not likely. All European
>proposals I've read state quite explicitly that "private keys for
>authentication shall not be archived." Perhaps the Americans think
>differently about this.
>

Larry Kilgallen

unread,
Jan 3, 1999, 3:00:00 AM1/3/99
to
In article <76n3bu$mbg$1...@reader1.reader.news.ozemail.net>, "Lyal Collins" <ly...@ozemail.com.au> writes:
> Please define your understanding of "normal setup"
> At least one Australian commercial CA generates keypairs for the
> applicant/end-user.
> It would seem this is justified on the grounds of ensuring the key pairs are
> random and properly created (sorry if I use the term somewhat loosely)
>
> Most commercial "off the shelf packages" I've seen have no accreditation of
> the key generation process (or encryption/signing processe) - so this
> approach has some validity from one perspective.

Requiring that only certain brands of software be used to generate the
key pairs would provide some defense against insufficent randomness
without introducing the _large_ vulnerability of possible leaking of
private keys for illicit purposes.

Larry Kilgallen

ssim...@hertreg.ac.uk

unread,
Jan 4, 1999, 3:00:00 AM1/4/99
to
In article <1999Jan3.042412.1@eisner>,

Like the fiasco with early SSL implementations from versions of NS / MS
browsers as exploited by Wagner et al?

To quote the DDJ article:

“Until they learn their lesson and open their security programming to public
evaluation, many security experts will remain justifiably skeptical of the
company's security claims.”

Dah well,

--


Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

ssim...@hertreg.ac.uk

unread,
Jan 4, 1999, 3:00:00 AM1/4/99
to
In article <76ibsf$lfl$1...@scream.auckland.ac.nz>,

pgu...@cs.auckland.ac.nz (Peter Gutmann) wrote:
> "Rich Ankney" <ran...@erols.com> writes:
>
> >This is from the PKIX (not S/MIME) RFC set. Sam is not quite correct that
> >Proof of Possession (PoP) is the same as sending your private key to the
> >CA. PoP allows the user to prove to the CA that he knows a private key
> >(e.g., sign a challenge with your private key, decrypt a challenge with
> >your
> >private key, etc.). The ability to archive your private key IS an OPTIONAL
> >part
> >of both PKIX certificate management protocols (CMP and CMC) but is not
> >the same as PoP.
>
> Since several governments (principally the US) have been trying to implement
> some form of GAK for years, and failing miserably (initially with Clipper,
> more recently with the Committee to Develop a Federal Information Processing
> Standard for the Federal Key Management Infrastructure farce where members
> were asked to resign at the final meeting so a quorum could be achieved). If
> the IETF is going to build a GAK-ready system for them, how long do you think
> it'll take before its use becomes mandated by law? The UK is trying to do
> this right now, and their GAK uses the PKIX protocols to get at users keys.
> It doesn't matter what the IETF says about the matter, if you build it...
>
> Peter.
>
>

I'm with you Peter...

It is believed that the inclusion of PoP was added to the S/Mime standard at
the request of the USG. Personally I believe that there should be a clear
statement on whether the S/Mime standard requires unconditionally or
functionally trusted TTPs – not some fuzzy standard that is subject to
political pressure.

Because we all know what way that'll swing, don't we?

--


Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.

-----------== Posted via Deja News, The Discussion Network ==----------

Reply all
Reply to author
Forward
0 new messages