I'm sorry, but I have to disagree on that one. S/MIME DOES use 40 bit RC2, by the standard, but the standard specifically states the weakness of those keys, and recommends using another implementation. The standard strongly recommends the use of triple-DES, and apparently the Communicator and Outlook S/MIME triple-DES now interoperates properly. Deming has also had a plugin which does triple-DES for quite a while. In addition, individual vendors are allowed to put in any other algorithms into an S/MIME implementation that they desire - for example, the default algorithm in Entrust's S/MIME implementation is CAST-128. The point that I'm trying to make here is that while PGP defines both algorithm and protocol, S/MIME just defines protocol. As long as you have two clients which share common algorithms, then you can use any algorithms that you like with S/MIME. ian ---------- From: Jonathan Wienke [SMTP:JonWienk@ix.netcom.com] Sent: Monday, November 03, 1997 9:34 PM To: Nobuki Nakatuji; cypherpunks@toad.com Subject: Re: S/MIME At 08:49 PM 11/2/97 PST, Nobuki Nakatuji wrote:
Is S/MIME secure than PGP ?
No. S/MIME uses 40 bit keys, which are trivially breakable by paralell brute-force key search attacks. Jonathan Wienke
-----BEGIN PGP SIGNED MESSAGE----- In <c=CA%a=_%p=NorTel_Secure_Ne%l=APOLLO-971104145454Z-34522@mail.entrust.com>, on 11/04/97 at 09:54 AM, Ian Clysdale <iancly@entrust.com> said:
I'm sorry, but I have to disagree on that one. S/MIME DOES use 40 bit RC2, by the standard, but the standard specifically states the weakness of those keys, and recommends using another implementation. The standard strongly recommends the use of triple-DES, and apparently the Communicator and Outlook S/MIME triple-DES now interoperates properly. Deming has also had a plugin which does triple-DES for quite a while. In addition, individual vendors are allowed to put in any other algorithms into an S/MIME implementation that they desire - for example, the default algorithm in Entrust's S/MIME implementation is CAST-128.
The point that I'm trying to make here is that while PGP defines both algorithm and protocol, S/MIME just defines protocol. As long as you have two clients which share common algorithms, then you can use any algorithms that you like with S/MIME.
This is not true. If you read the S/MIME specs it says one MUST implement the RC2/40 algorithm. A MUST in an RFC has a very definate purpose: If an aplication does not implement all MUST sections of the RFC then it is not compliant! To create an S/MIME compliant application one MUST implement RC2/40 and one MUST pay RSA to do so!! This is the BIG difference between S/MIME and Open-PGP. In Open-PGP there is no MUST to implemnet weak crypto. In Open-PGP there is no MUST to implement propritary algoritms. For those in the cheap seats: S/MIME: - -Weak Crypto - -Pay RSA Open-PGP: - -Strong Crypto - -Don't Pay Anyone I think that this should be simple enough for anyone here to understand. If your Entrust product is going to be using S/MIME to communicate with overseas users of Netscape and/or MS Outlook then you will be using RC2/40 to do so. That is the reason it is in the specs as a MUST, so MS and Netscape can export their products!!! Netscape, Microsoft, and RSA are letting thier greed get in the way of developing a message encryption protocol that provides strong crypto to ALL users. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNF9Ar49Co1n+aLhhAQH40AQAuHFsUjilp7QeLJoXy6QIZyGEK8T6iQtA LJDZnTyQvVF/dLvbo5cxVZky8rhdp5GsS5jH1ASlaQGuFzPVqddkZouw5a8GRicw fLfJvRethaSE2JEHk5GSVehGNHkGI6UbdIWTYGcap5aHxmAXouJTsAWkJbULdUKq 2GHkdXU6LN0= =7Pba -----END PGP SIGNATURE-----
participants (2)
-
Ian Clysdale -
William H. Geiger III