Request for comments - PGP RSA vs PGP DH FAQ
ssim...@hertreg.ac.uk
The most frequent question that appears in this forum is "which is better RSA
or DH?”. I propose to write a FAQ to attempt to answer this question and
other such related questions (e.g. what is CAST, what is MD5 etc).
It won’t be a “PGP apologist” perspective – it will simply present all
relevant educated opinions and mathematical facts. No doubt the production
of this FAQ will be an iterative process.
When complete I intend on posting this FAQ to the relevant newsgroups
(comp.security.pgp.discuss, alt.security.pgp) on a weekly or monthly basis.
A draft high-level view of the document:
Contents
Distribution
Contributors
Disclaimer
1) Introduction
2) Public Key algorithm changes
2.1) What is RSA?
2.2) What is DH / ElGamal?
2.3) What is DSS?
2.4) Which is stronger, RSA or DH/DSS?
2.5) What are the performance differences between RSA & DH/DSS?
3) Hash function changes
3.1) What is MD5?
3.2) What is SHA-1?
3.3) What is RIPE-MD?
3.4) Is MD5 "broken"?
3.5) Which is stronger, MD5, SHA-1 or RIPE-MD?
3.6) What are the performance differences between MD5, SHA-1 & RIPE-MD?
4) Conventional cipher changes:
4.1) What is IDEA?
4.2) What is CAST?
4.3) What is 3DES?
4.4) Which is stronger, IDEA, CAST or 3DES?
4.5) What are the performance differences between IDEA, CAST, 3DES?
5) Other issues
5.1) OpenPGP
5.2) RSAREF 2 License issues
5.3) “Compelled production” of encryption keys
5.4) DH "breaks" the existing web of trust?
5.5) Command Line (Unix) support
5.6) How does the cryptographic security of PGP compare to modern S/Mime
implementations?
6) Conclusion
References
I look forward to hearing comments or suggestions on this proposal.
Regards,
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
David Sternlight
What is RSAREF?
What are RSAREF's licensing procedures?
Where can I get RSAREF?
What is RSAREF 2?
What are RSAREF 2's licensing procedures?
Where can I get RSAREF 2?
I also suggest covering trust models explicitly. I don't think you can cover PGP vs. S/MIME (section 5.6) without it:
What is a trust model?
What is PGP's trust model?
What is the trust model built into the Netscape and Microsoft browser's S/MIME mailer/newsreaders?
When is each trust model preferred?
When might one be indifferent as between the two trust models?
How does one obtain PGP "certificates" (key signatures)?
What does one know about such certificates a priori?
What does one have to check personally about such certificates?
What do they cost?
Who stands behind them? With what indemnity?
How does one obtain Netscape/Microsoft's S/MIME built-in "certificates"?
What does one know about such certificates a priori?
What does one have to check personally about such certificates?
What do they cost?
Who stands behind them? With what indemnity?
and perhaps:
What has SSL got to do with all this?
Is there a PGP analogue to SSL?
ssim...@hertreg.ac.uk wrote:
> PGP DH vs. PGP RSA FAQ
>
> The most frequent question that appears in this forum is "which is better RSA
> or DH?”. I propose to write a FAQ to attempt to answer this question and
> other such related questions (e.g. what is CAST, what is MD5 etc).
>
> It won’t be a “PGP apologist” perspective ? it will simply present all
Sam Simpson
I do not intend going into Trust Models as this FAQ is specifically meant to
be a discussion of PGP RSA & PGP DH. The S/Mime vs PGP section will deal
with the area central to the FAQ - cryptographic security, not related
issues such as indemnities etc
The FAQ will certainly not cover PGP / SSL issues as this is well outside
the scope of the document.
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.
David Sternlight wrote in message <367FF73A...@sternlight.com>...
D. Lakis
<Big Damn Snip>
Sam, I think you should write your FAQ, anklebiters be damned.
I for one would appreciate it and learn something, for a change. It is
more than I have seen the most prolific posters offer
this group...besides their constant old-bitty bickering.
I can't figure out which is worse. Although the exchange on linewrapping
in Netscape will go down as a classic on how to handle carriage feeds,
I must admit. I certainly saved all the copies.
ssim...@hertreg.ac.uk
The FAQ will (hopefully!) be a central source for information regarding the
cryptographic strength of algorithms supported by PGP.
Some in this forum may not like sections of the FAQ (for example some people
seem to have an unnatural fascination with MD5, RSA etc) but they will not be
able to detract from the sources of the information contained.
I see your point, some on this group are very quick to argue and bicker but
are slow to do anything to actually progress PGP and crypto use in general.
Festive regards,
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.
In article <3681C0E0...@prodigy.net>,
Alex de Jong
Very Very Usefull, so I also vote Yes.
And if you can, please give already an answer to "2.4 which is stronger"
Regards Alex
ssim...@hertreg.ac.uk wrote:
>
> PGP DH vs. PGP RSA FAQ
>
> The most frequent question that appears in this forum is "which is better RSA
> or DH?”. I propose to write a FAQ to attempt to answer this question and
> other such related questions (e.g. what is CAST, what is MD5 etc).
>
> It won’t be a “PGP apologist” perspective – it will simply present all
> 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.
>
Sam Simpson
section personally (via e-mail), but beware of grammar / lack of references.
I should expect a first draft will be posted to this NG within a week.
Regards,
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.
Alex de Jong wrote in message <368247EE...@a1.nl>...
David Sternlight
ssim...@hertreg.ac.uk wrote:
> I am in the process of writing the FAQ nearly as we speak.
>
> The FAQ will (hopefully!) be a central source for information regarding the
> cryptographic strength of algorithms supported by PGP.
>
> Some in this forum may not like sections of the FAQ (for example some people
> seem to have an unnatural fascination with MD5, RSA etc) but they will not be
> able to detract from the sources of the information contained.
If you have any hope of producing an accurate FAQ rather than a partisan screed, you must get that chip off your shoulder. There is no "unnatural fascination" with RSA and MD5. RSA is the de facto crypto algorithm used in tens if not hundreds of millions of copies of the de facto standard applications in their class, including Lotus Notes, Microsoft Internet Explorer/Outlook Express, and Netscape Communicator, as well as many other packages from IBM, DEC, Apple, and even Network Associates' own Trusted Information Systems.. Not to recognize this is to have one's head in the sand.
What is more PGP does not even attempt to provide the package functions of the above--it is a crypto add-on. Thus one is trying to compare a separate add-on which is incompatible with the existing crypto package in the above applications, with that built-in crypto package which users of the applications already have. This must be recognized for any realistic appreciation of PGP's situation.
As to MD5, it may be a bit long in the tooth, but the greatest experts on that say that there is no hurry to replace it and that it may be replaced at the next version upgrade of a product. It has not been broken, but seems possibly weak. And the weakness has little to do with encryption of decryption of message traffic--it is a matter of whether it will ever be possible to counterfeit a valid signature for another's key pair. You need to explain these facts carefully, accurately, and in terms the general reader can grasp so that they will be understood. In the past what we have seen here have been vague and alarmist statements about "collisions" which few really understand.
Most "true believers" tend to see those who have another view as attempting to "detract from" their true belief. Yet is is just those "true beliefs" which originally arose from questioning the conventional wisdom. In effect, the "true believers" have become the thing they hate. I see ample evidence of that here, whenever flaws in PGP are raised, or it is suggested that something else might be more suitable for a particular purpose.
>
>
> I see your point, some on this group are very quick to argue and bicker but
> are slow to do anything to actually progress PGP and crypto use in general.
Sorry--when was it that Stone or Lesher last made a significant contribution to PGP? I must have missed it.
David
>
>
> Festive regards,
>
> 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.
>
> In article <3681C0E0...@prodigy.net>,
> Diana2...@prodigy.net wrote:
> >
> > Sam Simpson wrote:
> >
> > <Big Damn Snip>
> >
> > Sam, I think you should write your FAQ, anklebiters be damned. I for one
> would
> > appreciate it and learn something, for a change. It is more than I have seen
> the
> > most prolific posters offer this group...besides their constant old-bitty
> > bickering. I can't figure out which is worse. Although the exchange on
> > linewrapping in Netscape will go down as a classic on how to handle carriage
> > feeds, I must admit. I certainly saved all the copies.
>
nos...@synernet.com
says...
<snip>
> As to MD5, it may be a bit long in the tooth, but the greatest experts on that say that there is no hurry to replace it and that it may be replaced at the next version upgrade of a product. It has not been broken, but seems possibly weak. And the weakness has little to do with encryption of decryption of message traffic--it is a matter of whether it will ever be possible to counterfeit a valid signature for another's key pair. You need to explain these facts carefully,
accurately, and in terms the general reader can grasp so that they will be understood. In the past what we have seen here have been vague and alarmist statements about "collisions" which few really understand.
RSADSI recommended in November of 1996 that it be replaced with SHA or
other digest algorithm. That was 25 months ago, i.e., back when DES was
still "strong".
--
--
-------------------------------
Ed Stone
est...@synernet-robin.com
remove "-birdname" spam avoider
Sternlight FAQ at http://www.synernet.com/public/sternlight-faq
-------------------------------
David Hamilton
ssim...@hertreg.ac.uk wrote:
>PGP DH vs. PGP RSA FAQ
(snip all)
Excellent idea Sam. I will find sections 2-4 interesting (public key, hash
functions, conventional cipher) ... but I'm not so interested in the
performance differences aspects which you intend to cover under these
headings. I have to admit that I don't expect to find section 5 interesting
... but that may depend on your writing style!
2.5 years ago, I wrote a 'PGP for Absolute Beginners' piece which Bill Unruh
hosts on his cryptography site (http://axion.physics.ubc.ca/crypt.html).
When I suggested the idea in alt.security.pgp, the response was absolutely
... luke warm. However, I enjoyed doing it, found it to be a useful learning
process and, over the years, have had about a dozen people thank me. I regard
that as a success.
You have a more difficult task: the subject area is larger and, probably,
your target audience is not as tightly defined. You'll get people arguing
over any opinion you express but, hopefully, they won't argue over the facts.
Good luck with the FAQ: I'm sure it will be worthwhile.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<da...@davidham.demon.co.uk>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNoKOz8o1RmX6QSF5AQGQGQf+JaPppv3S7hLlZB8JdJsWMgR2CW/vSOMa
WLC0frJ96JgweMqqCrkS7vEVXs3YuZ9DeD2HKUICO5BL0YDMHY+yrBFO/k1pmOhl
QbyAnIqcnNYOQROMrPqPRJmQxNSdd/YCIuqhZ1T3gPsPWc5/GlJkRTU+4KWl5Exi
aN0Qg3kxeM8yJD+OFPcqrtzIxy+CZfbXqdGx55X38npICmFaQDaLUnEpgxOZKEoH
vKJfcR6is5lEc7EvQzI0YbjZakZBuLeR+buYX8QHUVnjbydAmsWKL69odGa4T6iC
PmfSp4AD7HGFNwOjCHqmggV8QcaORgbjqFQJ4f4BF6LyiCEnMyGgAQ==
=MJWO
-----END PGP SIGNATURE-----
nos...@synernet.com
>
> David
Well, I'll point out a contribution I made to your favorite,
S/MIME/VeriSign... Specifically, the contribution I made to the VeriSign
S/MIME cert process when I demonstrated to the VeriSign group that their
MSIE S/MIME cert generation process was providing short 512-bit key
generation (through its erroneous invocation of the export-grade CSP on
the local machine), even when the person genning the key had the US
domestic CSP that would gen a 1024-bit key for VeriSign certification.
VeriSign changed their MSIE enrollment code to remedy this after I
discovered it and pointed it out to them.
See VeriSign's thank-you-note to me at http://www.jya.com/vs-msie-fix.htm
See my report of the VeriSign small key security issue at
http://www.jya.com/vs-msie.htm
Now your turn, Mr. Sternlight. How have you assisted Mr. Zimmermann or
PGP, Inc/NAI? ;-)
Anonymous
-----BEGIN PGP SIGNED MESSAGE-----
Greetings, mr. Sternlight, is it sunny in California?
Could you give some comment to these polite questions:
David Sternlight wrote:
>As to MD5, it may be a bit long in the tooth, but the greatest experts
>on that say that there is no hurry to replace it and that it may be
>replaced at the next version upgrade of a product.
When RSA was dropped from the freeware version
of PGP, was that *not* an upgrade of a product?
Logic would suggest that a change in the free
product would most quickly disseminate across
the user base?
>Sorry--when was it that Stone or Lesher last made a significant
>contribution to PGP? I must have missed it.
Mr. Sternlight, not giving in to the currents here, when did
you made a significant contribution to PGP? And on reflection,
when did you make a significant contribution to S/MIME?
- --EO
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2
iQEVAwUBNoKFmcgXRmWyooNRAQHStQgAknH9GBOr37obCsnVe1FJR2yP+Y3RxOm6
ZMl/jrf5n77jNipGphXT+FPyFcDUN43MeF+D1feQR4J8uKwFX2C5f1q+aZbmbkoP
Fn1IE52M4mHguH7+x2KFfa9gdxaeFswitnw5m4wA7GaxGFRzzY2Rj9zjKViGaOPQ
EVsdZmKqjlO/h/23ZMSH8tcEoWX3CzDp0F+EF9+NKkhw8VieCs2wwt9C2ChuYvHD
0xbjEwI6H2WQtIg4gRLISsLset6t13SAa4yz4/yzqITzSazjBtKvE+rp3dU8x5wr
Syeb4jACdtQSd4/Jz10aOS27N8cVerDkzmP7mqzeuvrkIZjw4unBwA==
=5H2l
-----END PGP SIGNATURE-----
David Sternlight
David
nos...@synernet.com wrote:
> In article <36828462...@sternlight.com>, da...@sternlight.com
> says...
> <snip>
> > As to MD5, it may be a bit long in the tooth, but the greatest experts on that say that there is no hurry to replace it and that it may be replaced at the next version upgrade of a product. It has not been broken, but seems possibly weak. And the weakness has little to do with encryption of decryption of message traffic--it is a matter of whether it will ever be possible to counterfeit a valid signature for another's key pair. You need to explain these facts carefully,
> accurately, and in terms the general reader can grasp so that they will be understood. In the past what we have seen here have been vague and alarmist statements about "collisions" which few really understand.
> <snip>
> RSADSI recommended in November of 1996 that it be replaced with SHA or
> other digest algorithm. That was 25 months ago, i.e., back when DES was
> still "strong".
>
David Sternlight
Stone standard tactic: When you can't answer an embarrassing question, change the subject.
David
nos...@synernet.com wrote:
> In article <36828462...@sternlight.com>, da...@sternlight.com
> says...
> <snip>
> > Sorry--when was it that Stone or Lesher last made a significant contribution to PGP? I must have missed it.
> >
> > David
> <snip>
>
> Well, I'll point out a contribution I made to your favorite,
> S/MIME/VeriSign... Specifically, the contribution I made to the VeriSign
> S/MIME cert process when I demonstrated to the VeriSign group that their
> MSIE S/MIME cert generation process was providing short 512-bit key
> generation (through its erroneous invocation of the export-grade CSP on
> the local machine), even when the person genning the key had the US
> domestic CSP that would gen a 1024-bit key for VeriSign certification.
> VeriSign changed their MSIE enrollment code to remedy this after I
> discovered it and pointed it out to them.
>
> See VeriSign's thank-you-note to me at http://www.jya.com/vs-msie-fix.htm
> See my report of the VeriSign small key security issue at
> http://www.jya.com/vs-msie.htm
>
> Now your turn, Mr. Sternlight. How have you assisted Mr. Zimmermann or
> PGP, Inc/NAI? ;-)
Ed Stone
says...
> As usual Stone quotes half a story out of context. RSADSI's recommendation was that there was no hurry but that it could be done in the course of version improvements.
Yes. will you please tell us exactly what crypto software you are using
that has not had "version improvements" since November, 1996? Since you
say you have pgp 6.0.2, and S/MIME-app via Netscape 4.5, I do not know
what other crypto software you may have that has not had *several*
"version improvements" since November 1996. ;-)
> What is more, until very recently Taher ElGamal, the author whose algorithm PGP now relies on and whose cryptographic expertise is waved in the air when the issue is ElGamal vs. RSA algorithms,, was the technical director of Netscape and saw no need to replace MD5 in any hurry. Stone is vocal on ELGamal's bona fides when it comes to the ElGamal vs RSA algorithm, but is strangely silent on that topic when it comes to ElGamal's decisions with respect to MD5 in Netscape.
>
I don't use Netscape S/MIME apps, other than to play with them. That is
my comment Netscape crypto. And can you point me to the words you rely on
when you say "Stone is vocal on ELGamal's bona fides when it comes to the
ElGamal vs RSA algorithm, but is strangely silent on that topic when it
comes to ElGamal's decisions with respect to MD5 in Netscape"? Thanks.
> David
Ed Stone
says...
> I think what Stone is trying to say is that he found a non-cryptographic flaw in the Verisign user interface, which had nothing to do with making a significant contribution to PGP.. I repeat my question.
>
> Stone standard tactic: When you can't answer an embarrassing question, change the subject.
I must confess, I am not embarrassed. ;-) Now, how have you helped PGP
or Mr. Zimmermann again? Merry Merry Christmas!!!
>
> David
>
> nos...@synernet.com wrote:
>
> > In article <36828462...@sternlight.com>, da...@sternlight.com
> > says...
> > <snip>
> > > Sorry--when was it that Stone or Lesher last made a significant contribution to PGP? I must have missed it.
> > >
> > > David
> > <snip>
> >
> > Well, I'll point out a contribution I made to your favorite,
> > S/MIME/VeriSign... Specifically, the contribution I made to the VeriSign
> > S/MIME cert process when I demonstrated to the VeriSign group that their
> > MSIE S/MIME cert generation process was providing short 512-bit key
> > generation (through its erroneous invocation of the export-grade CSP on
> > the local machine), even when the person genning the key had the US
> > domestic CSP that would gen a 1024-bit key for VeriSign certification.
> > VeriSign changed their MSIE enrollment code to remedy this after I
> > discovered it and pointed it out to them.
> >
> > See VeriSign's thank-you-note to me at http://www.jya.com/vs-msie-fix.htm
> > See my report of the VeriSign small key security issue at
> > http://www.jya.com/vs-msie.htm
> >
> > Now your turn, Mr. Sternlight. How have you assisted Mr. Zimmermann or
> > PGP, Inc/NAI? ;-)
David Sternlight
Note also that PGP does not offer the above option. Instead, the option for message digest is fixed by a particular key holder's key generation selection--either RSA, or Diffie-Hellman/DSS. Binding the message digest method to a user's key has some operational convenience in later correspondence, but creates limited flexibility. There is no underlying reason I can see so to do.
And now to the FAQ input, partially paraphrased from the two RSADSI FAQ items referred to at the end. Readers of this post should note that the RSADSI FAQ will answer many questions readers have about cryptography, PGP, S/MIME, RSA, digital signatures, etc.
What is a message digest?
A message digest is a shortened, or compressed version of the text of a message. Its algorithm is also known as a hash function.
What is it used for?
Message digests are used to compute cryptographic signatures. A cryptographic signature is a message digest encrypted with the secret key of the sender. The recipient decrypts it, and then compares the message digest with the message digest he calculates for the message received. If they match he has very strong evidence for two things:
1. The message digest was in fact sent by the claimed sender, since only that sender is presumed to have the secret key corresponding to the public key used to decrypt the message digest.
2. The message has been unaltered during transmission, since the received and calculated message digests match.
What is a collision?
A complete hash function collision occurs when message digests for two messages match. A message digest algorithm is said to be strongly collision free if it is computationally infeasible to find two messages whose hash functions match. A message digest algorithm is said to be weakly collision free if it is computationally infeasible to find a message (other than the chosen message) whose hash function matches that of a chosen message. Note that in the definitions, either or both messages may be gibberish, so the subset of useful collisions is quite a bit smaller than the set of all possible collisions and thus presents a computationally more difficult problem.
A compression function collision is generated using two different message blocks with the same value to the chaining variable. They are different from pseudo-collisions (see below) and are closer in spirit to the idea of collisions for the complete hash function. As a result, the existence of collisions for the compression function of a hash function might bring into question the longer term resistance of the hash function itself. This is currently the situation with MD5 (see below)
A pseudo collision is generated when collisions for the compression can be found using two different chaining variables but with the same message input. Usually such collisions, while interesting, have little direct relevance to the security of the hash function itself.
Do all message digest algorithms have collisions?
Yes, unless the message digest is as long as the longest message in bit-informational content. The issue isn't whether there are collisions, but in the computational feasibility of exploiting them to produce a meaningful bogus message with a signature that checks against the public key of the putative sender.
What about MD5?
MD5 is a message digest algorithm used in a number of S/MIME implementations including the current versions of Netscape Communicator and Microsoft Outlook Express. Its author, RSADSI, recommends that it be replaced at the next major version change of such implementations.
Why does RSADSI recommend its replacement?
Although there has been no demonstration of full collision weakness, and pseudo-collisions aren't relevant to the security of the hash function, the demonstration of compression function collisions suggests that it may some day be possible to demonstrate full collisions.
How do I protect myself
Since one computational attack, when it becomes feasible, is the "birthday attack" (see the reference below), and this requires persuading you to sign a chosen message, don't sign any messages offered to you by others whom you don't fully trust. If and when your cryptographic package of choice offers SHA-1 or MD5, switch to it if your correspondents can also handle it. At the present time experts do not think it necessary immediately to abandon MD5. Stay tuned.
How can I obtain more information?
Check http://www.rsa.com/rsalabs/faq/html/2-1-6.html, and http://www.rsa.com/rsalabs/faq/html/2-4-6.html
David
David Sternlight
Anonymous wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Greetings, mr. Sternlight, is it sunny in California?
>
> Could you give some comment to these polite questions:
>
> David Sternlight wrote:
>
> >As to MD5, it may be a bit long in the tooth, but the greatest experts
> >on that say that there is no hurry to replace it and that it may be
> >replaced at the next version upgrade of a product.
>
> When RSA was dropped from the freeware version
> of PGP, was that *not* an upgrade of a product?
>
> Logic would suggest that a change in the free
> product would most quickly disseminate across
> the user base?
There was no need to drop RSA. The issue was upgrading the message digest, not changing the message key passing algorithm. One may observe, for example, that S/MIME in Netscape still uses RSA but also has SHA-1 and DSS as message digests in addition to MD2 and MD5.
David
David Sternlight
Ed Stone wrote:
> In article <3682A70C...@sternlight.com>, da...@sternlight.com
> says...
> > As usual Stone quotes half a story out of context. RSADSI's recommendation was that there was no hurry but that it could be done in the course of version improvements.
>
> Yes. will you please tell us exactly what crypto software you are using
> that has not had "version improvements" since November, 1996? Since you
> say you have pgp 6.0.2, and S/MIME-app via Netscape 4.5, I do not know
> what other crypto software you may have that has not had *several*
> "version improvements" since November 1996. ;-)
Netscape Communicator 4.5 uses the RSADSI PKCS #11 package which includes SHA-1 and DSA as well as MD2 and MD5. It also uses RSA. Thus there is no reason to drop RSA in order to offer other signature algorithms. All of the above may be enabled or disabled as user options.
David
David Sternlight
Ed Stone wrote:
> In article <3682A7F6...@sternlight.com>, da...@sternlight.com
> says...
> > I think what Stone is trying to say is that he found a non-cryptographic flaw in the Verisign user interface, which had nothing to do with making a significant contribution to PGP.. I repeat my question.
> >
> > Stone standard tactic: When you can't answer an embarrassing question, change the subject.
>
> I must confess, I am not embarrassed. ;-) Now, how have you helped PGP
> or Mr. Zimmermann again?
Another suggested that some frequent posters here have made no significant contributions to PGP. Stone addressed the question of his own such contribution with an attempted change of subject to a user interface error he found in S/MIME--nothing to do with PGP. At the least that Stone has listed no significant contributions to PGP makes him a fair object of the original comment.
Stone, ever on the attack, also attempts to shift the question to whether I made any such contributions. I could cite a history of extensive activity with Jim Bidzos of RSADSI in an attempt to get him to license free PGP, eventually culminating in RSAREF (I certainly do not claim the main share of credit for this) as used in US free PGP 2.x, as well as a history of beta testing contributions to various people's versions of PGP 2.x (but not for later NA or PGP Inc. versions since they were under a licensing cloud). I could cite that my PGP keys were among the earliest posted to the server, that one were signed by the "fathers" of free MIT PGP, Jeff Schiller and Derek Atkins, that it was thus one remove from Phil's key if we're talking web of trust, and thus that I was an early adopter and supporter-by-use.
But I do not rely on any of that, preferring to leave it at my earlier point . Since Stone hasn't supplied any relevant response, preferring to change the subject, I am happy to rely on his failure to adduce any significant contributions to PGP to making this, at best, a neutrally distinguishing issue with respect to my posts and one which, on the evidence to date, differentially disfavors any claims by him.
I do not plan to engage further with Stone on this topic. "Mine is longer than yours. No it's not." belongs in the playground.
Have a Merry Christmas, all.
David
Ed Stone
says...
> Here is a contribution to the FAQ on hash functions, message digests, and MD5, in simple, easy-to-understand language. It should be taken as a draft, and not the final word. Note also that my latest US version of Netscape Communicator 4,5 uses the PKCS#11 package which includes SHA-1 and DSA, so much of the fuss about MD5, even though it is overblown, may be somewhat irrelevant.
Gosh, the surprise is that Netscape has switched off from MD5 since the
November 1996 recommendation of RSADSI that the world do so??? The
only fuss I saw about MD5 what your footdragging about it being departed
from in favor of SHA-1, etc, per the now 25 month old recommendation of
RSADSI. ;-)
> That this is so (it's not shown in the "about" box yet) may be seen by going to the security preferences, selecting "Cryptographic Modules", doing a "ViewEdit" on PKCS #11, and then doing a "Config" on the sub-modules. One may even disable MD2 and MD5 if one is concerned, with those options, though for compatibility with correspondents using MD2 and MD5 it is probably not a good idea so to do just yet.
Gosh, five levels deep into the menus? ;-)
>
> Note also that PGP does not offer the above option. Instead, the option for message digest is fixed by a particular key holder's key generation selection--either RSA, or Diffie-Hellman/DSS. Binding the message digest method to a user's key has some operational convenience in later correspondence, but creates limited flexibility.
Now you suggest "flexibility" of algorithm selection? ;-)
> There is no underlying reason I can see so to do.
>
> And now to the FAQ input, partially paraphrased from the two RSADSI FAQ items referred to at the end. Readers of this post should note that the RSADSI FAQ will answer many questions readers have about cryptography, PGP, S/MIME, RSA, digital signatures, etc.
>
> What is a message digest?
> A message digest is a shortened, or compressed version of the text of a message. Its algorithm is also known as a hash function.
>
> What is it used for?
> Message digests are used to compute cryptographic signatures. A cryptographic signature is a message digest encrypted with the secret key of the sender. The recipient decrypts it, and then compares the message digest with the message digest he calculates for the message received. If they match he has very strong evidence for two things:
>
> 1. The message digest was in fact sent by the claimed sender, since only that sender is presumed to have the secret key corresponding to the public key used to decrypt the message digest.
>
> 2. The message has been unaltered during transmission, since the received and calculated message digests match.
>
> What is a collision?
> A complete hash function collision occurs when message digests for two messages match. A message digest algorithm is said to be strongly collision free if it is computationally infeasible to find two messages whose hash functions match. A message digest algorithm is said to be weakly collision free if it is computationally infeasible to find a message (other than the chosen message) whose hash function matches that of a chosen message. Note that in the definitions,
either or both messages may be gibberish, so the subset of useful collisions is quite a bit smaller than the set of all possible collisions and thus presents a computationally more difficult problem.
>
> A compression function collision is generated using two different message blocks with the same value to the chaining variable. They are different from pseudo-collisions (see below) and are closer in spirit to the idea of collisions for the complete hash function. As a result, the existence of collisions for the compression function of a hash function might bring into question the longer term resistance of the hash function itself. This is currently the situation with
MD5 (see below)
>
> A pseudo collision is generated when collisions for the compression can be found using two different chaining variables but with the same message input. Usually such collisions, while interesting, have little direct relevance to the security of the hash function itself.
>
> Do all message digest algorithms have collisions?
> Yes, unless the message digest is as long as the longest message in bit-informational content. The issue isn't whether there are collisions, but in the computational feasibility of exploiting them to produce a meaningful bogus message with a signature that checks against the public key of the putative sender.
>
> What about MD5?
> MD5 is a message digest algorithm used in a number of S/MIME implementations including the current versions of Netscape Communicator and Microsoft Outlook Express.
Here you finally get to it...
> Its author, RSADSI, recommends that it be replaced at the next major version change of such implementations.
...and they made that recommendation 25 months ago.... ;-)
>
> Why does RSADSI recommend its replacement?
> Although there has been no demonstration of full collision weakness, and pseudo-collisions aren't relevant to the security of the hash function, the demonstration of compression function collisions suggests that it may some day be possible to demonstrate full collisions.
>
> How do I protect myself
> Since one computational attack, when it becomes feasible, is the "birthday attack" (see the reference below), and this requires persuading you to sign a chosen message, don't sign any messages offered to you by others whom you don't fully trust. If and when your cryptographic package of choice offers SHA-1 or MD5, switch to it if your correspondents can also handle it. At the present time experts do not think it necessary immediately to abandon MD5. Stay tuned.
>
> How can I obtain more information?
> Check http://www.rsa.com/rsalabs/faq/html/2-1-6.html, and http://www.rsa.com/rsalabs/faq/html/2-4-6.html
>
> David
>
>
>
--
Ed Stone
says...
>
>
> Ed Stone wrote:
>
> > In article <3682A70C...@sternlight.com>, da...@sternlight.com
> > says...
> > > As usual Stone quotes half a story out of context. RSADSI's recommendation was that there was no hurry but that it could be done in the course of version improvements.
> >
> > Yes. will you please tell us exactly what crypto software you are using
> > that has not had "version improvements" since November, 1996? Since you
> > say you have pgp 6.0.2, and S/MIME-app via Netscape 4.5, I do not know
> > what other crypto software you may have that has not had *several*
> > "version improvements" since November 1996. ;-)
>
> Netscape Communicator 4.5 uses the RSADSI PKCS #11 package which includes SHA-1 and DSA as well as MD2 and MD5.
Yes, it has had its message digest functions updated since the
recommendation 25 months ago by RSADSI....
> It also uses RSA. Thus there is no reason to drop RSA in order to offer other signature algorithms.
We are now off from MD5 and onto RSA, it seems....
> All of the above may be enabled or disabled as user options.
>
Ed Stone
says...
>
>
> Ed Stone wrote:
>
> > In article <3682A7F6...@sternlight.com>, da...@sternlight.com
> > says...
> > > I think what Stone is trying to say is that he found a non-cryptographic flaw in the Verisign user interface, which had nothing to do with making a significant contribution to PGP.. I repeat my question.
> > >
> > > Stone standard tactic: When you can't answer an embarrassing question, change the subject.
> >
> > I must confess, I am not embarrassed. ;-) Now, how have you helped PGP
> > or Mr. Zimmermann again?
>
> Another suggested that some frequent posters here have made no significant contributions to PGP. Stone addressed the question of his own such contribution with an attempted change of subject to a user interface error he found in S/MIME--nothing to do with PGP. At the least that Stone has listed no significant contributions to PGP makes him a fair object of the original comment.
>
thank-you from VeriSign for my finding weakness in their key generation
interface, resulting in 512-bit keys even for US domestic MSIE. And you?
;-)
> Stone, ever on the attack, also attempts to shift the question to whether I made any such contributions.
Yep. What are they?
> I could cite a history of extensive activity with Jim Bidzos of RSADSI in an attempt to get him to license free PGP, eventually culminating in RSAREF (I certainly do not claim the main share of credit for this)
Good.
> as used in US free PGP 2.x, as well as a history of beta testing contributions to various people's versions of PGP 2.x
Non-US beta testing?
> (but not for later NA or PGP Inc. versions since they were under a licensing cloud).
Awww. That's why no contributions? ;-)
> I could cite that my PGP keys were among the earliest posted to the server,
What a contribution!!
> that one were signed by the "fathers" of free MIT PGP, Jeff Schiller and Derek Atkins,
Not one from PRZ himself?? ;-)
> that it was thus one remove from Phil's key if we're talking web of trust, and thus that I was an early adopter and supporter-by-use.
>
> But I do not rely on any of that,
Good.
> preferring to leave it at my earlier point . Since Stone hasn't supplied any relevant response, preferring to change the subject, I am happy to rely on his failure to adduce any significant contributions to PGP to making this, at best, a neutrally distinguishing issue with respect to my posts and one which, on the evidence to date, differentially disfavors any claims by him.
>
> I do not plan to engage further with Stone on this topic. "Mine is longer than yours. No it's not." belongs in the playground.
How you can make that leap of reference would boggle even Freud. I
suggest you get your mind onto something else... ;-)
>
> Have a Merry Christmas, all.
>
David Sternlight
Ed Stone wrote:
> > Netscape Communicator 4.5 uses the RSADSI PKCS #11 package which includes SHA-1 and DSA as well as MD2 and MD5.
>
> Yes, it has had its message digest functions updated since the
> recommendation 25 months ago by RSADSI....
Actually, as I recall Communicator 4.0x also used PKCS #11.
>
> > It also uses RSA. Thus there is no reason to drop RSA in order to offer other signature algorithms.
>
> We are now off from MD5 and onto RSA, it seems....
No. The argument for PGP's dropping RSA was that MD5 might at some point be found to be weak. The entire MD5 discussion is a component of that RSA syllogism, and would be pointless otherwise.
As I have now shown, it is possible to provide other message digest algorithms without having to drop RSA. Netscape has done it, as has RSADSI via PKCS #11. Thus the MD5 argument in rationalization by some here of PGP's dropping RSA is shown to be bogus.,
David
David Sternlight
Ed Stone wrote:
> In article <3682C203...@sternlight.com>, da...@sternlight.com
> says...
> > Here is a contribution to the FAQ on hash functions, message digests, and MD5, in simple, easy-to-understand language. It should be taken as a draft, and not the final word. Note also that my latest US version of Netscape Communicator 4,5 uses the PKCS#11 package which includes SHA-1 and DSA, so much of the fuss about MD5, even though it is overblown, may be somewhat irrelevant.
>
> Gosh, the surprise is that Netscape has switched off from MD5 since the
> November 1996 recommendation of RSADSI that the world do so??? The
> only fuss I saw about MD5 what your footdragging about it being departed
> from in favor of SHA-1, etc, per the now 25 month old recommendation of
> RSADSI. ;-)
Always the off-topic complainer, eh, Ed? The point was that they changed it at the next major revision. As I recall PKCS #11 has been in use in Netscape for quite some time, not just in 4.5.
>
>
> > That this is so (it's not shown in the "about" box yet) may be seen by going to the security preferences, selecting "Cryptographic Modules", doing a "ViewEdit" on PKCS #11, and then doing a "Config" on the sub-modules. One may even disable MD2 and MD5 if one is concerned, with those options, though for compatibility with correspondents using MD2 and MD5 it is probably not a good idea so to do just yet.
>
> Gosh, five levels deep into the menus? ;-)
Always the off-topic complainer, eh, Ed? The point was about evidence of presence, not ease of use.
>
> >
> > Note also that PGP does not offer the above option. Instead, the option for message digest is fixed by a particular key holder's key generation selection--either RSA, or Diffie-Hellman/DSS. Binding the message digest method to a user's key has some operational convenience in later correspondence, but creates limited flexibility.
>
> Now you suggest "flexibility" of algorithm selection? ;-)
Always the off-topic complainer, eh, Ed. I never objected to PGP having alternatives. I objected to their dropping RSA in free PGP.
>
>
> > There is no underlying reason I can see so to do.
> >
> > And now to the FAQ input, partially paraphrased from the two RSADSI FAQ items referred to at the end. Readers of this post should note that the RSADSI FAQ will answer many questions readers have about cryptography, PGP, S/MIME, RSA, digital signatures, etc.
> >
> > What is a message digest?
> > A message digest is a shortened, or compressed version of the text of a message. Its algorithm is also known as a hash function.
> >
> > What is it used for?
> > Message digests are used to compute cryptographic signatures. A cryptographic signature is a message digest encrypted with the secret key of the sender. The recipient decrypts it, and then compares the message digest with the message digest he calculates for the message received. If they match he has very strong evidence for two things:
> >
> > 1. The message digest was in fact sent by the claimed sender, since only that sender is presumed to have the secret key corresponding to the public key used to decrypt the message digest.
> >
> > 2. The message has been unaltered during transmission, since the received and calculated message digests match.
> >
> > What is a collision?
> > A complete hash function collision occurs when message digests for two messages match. A message digest algorithm is said to be strongly collision free if it is computationally infeasible to find two messages whose hash functions match. A message digest algorithm is said to be weakly collision free if it is computationally infeasible to find a message (other than the chosen message) whose hash function matches that of a chosen message. Note that in the definitions,
> either or both messages may be gibberish, so the subset of useful collisions is quite a bit smaller than the set of all possible collisions and thus presents a computationally more difficult problem.
> >
> > A compression function collision is generated using two different message blocks with the same value to the chaining variable. They are different from pseudo-collisions (see below) and are closer in spirit to the idea of collisions for the complete hash function. As a result, the existence of collisions for the compression function of a hash function might bring into question the longer term resistance of the hash function itself. This is currently the situation with
> MD5 (see below)
> >
> > A pseudo collision is generated when collisions for the compression can be found using two different chaining variables but with the same message input. Usually such collisions, while interesting, have little direct relevance to the security of the hash function itself.
> >
> > Do all message digest algorithms have collisions?
> > Yes, unless the message digest is as long as the longest message in bit-informational content. The issue isn't whether there are collisions, but in the computational feasibility of exploiting them to produce a meaningful bogus message with a signature that checks against the public key of the putative sender.
> >
> > What about MD5?
> > MD5 is a message digest algorithm used in a number of S/MIME implementations including the current versions of Netscape Communicator and Microsoft Outlook Express.
>
> Here you finally get to it...
Always the off-topic complainer, eh Ed? The request was for a comprehensive FAQ, not assertion or appeal to authority.
David Sternlight
Ed Stone wrote:
> I provided a url to a
> thank-you from VeriSign for my finding weakness in their key generation
> interface, resulting in 512-bit keys even for US domestic MSIE.
The question raised was about "significant contributions to PGP". Stone had none to offer thus far, and so has tried to change the subject to "contributions to anything crypto". in order to cover over that apparent abysmal absence.
The rest of Stone's post is so filled with moronic and irrelevant asides that it would unnecessarily burden the readers of this group for me to respond.
David
David Lesher
Sgt. SternFUD announces:
{I see the MACpert still can't figure out how to wrap lines. Must
be too hard for him to figure out, alas....}
>Another suggested that some frequent posters here have made no
>significant contributions to PGP.
I must have missed that unidentified "Another" here...
>I could cite that my PGP keys were among the earliest posted to
>the server, that one were signed by the "fathers" of free MIT PGP,
>Jeff Schiller and Derek Atkins, that it was thus one remove from
>Phil's key if we're talking web of trust, and thus that I was an
>early adopter and supporter-by-use.
Gee, I have a key signed by kinds of folks, too. Somehow I never
considered that a laudable accomplishment, one worthy of
self-congratulatory trumpeting. Maybe I'm wrong....
>I do not plan to engage further with Stone on this topic. "Mine is
>longer than yours. No it's not." belongs in the playground.
This from the man who waves his "big dic" around regularly?
{Apologies to my friends on alt.folklore.urban for misusing that
term of art here, but it does seen appropriate...} As I recall, he
was the one that started the pissing match.
But I *do* wish that when FUD breaks out in song Yet Again; he'd
either get on-key.... or really leave. He's enough off to make
Rosanne's version of the National Anthem sound like the Ode to Joy.
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
D. Lakis
<Snip>
> Sgt. SternFUD announces:
>
> >Another suggested that some frequent posters here have made no
> >significant contributions to PGP.
>
> I must have missed that unidentified "Another" here...
I am the unidentified another. And what I posted was "contributions to
this group", comp.security.pgp.discuss. I did not mention PGP except in
the context of this newsgroup. My apologies to the other prolific
posters in this group. I think I have figured out which end is up in
that regard.
<Snip>
David Sternlight
"D. Lakis" wrote:
What Lakis said was "It is more than I have seen the most prolific posters offer this group...besides
their constant old-bitty bickering."
Lesher clearly falls into that category. As to Stone's finding a user interface error in S/MIME, I'm not sure that counts as a "contribution to _this_ group". But on balance I'd say that Stone has offered helpful material to others here, as have I, though we disagree on such issues as trust models. I have received many e-mails of thanks for my materials, as I'm sure has Stone.
Thus I think that unless Lakis was referring to Lesher, he simply hasn't been reading the traffic for any period of time.
As Stone's latest substantive contribution, I offer his assistance to the user who had trouble converting an encrypted Word file. I had to dig through many Stone posts in which he attacks just about anything I say--not a contribution. I would hope he makes an effort to get his batting average up.
As mine, I offer the contribution to the FAQ, or that on word wrap. Thus I suggest that unless Lakis was talking about Lesher, he was simply wrong. And it is perhaps fair to ask: What contribution has Lakis made to this group?
David
Stuart Krivis
>Mr. Sternlight, not giving in to the currents here, when did
>you made a significant contribution to PGP? And on reflection,
>when did you make a significant contribution to S/MIME?
That's an easy one. He hates PGP and loves S/MIME.
This tells everyone to use PGP and not S/MIME. Significant
contributions to both.
I do have to hand it to SternFUD. He is tenacious. He's been
shovelling his brand of crap for years and years.
Very few people have rated a place in my killfile. Sternblight is in
there. I suppose that could be considered quite an honor...
--
Stuart Krivis stuart at krivis dot com
[Team OS/2] [Team APK]
Use this e-mail address for replies - suitably un-munged, of course.
Remove the mongo in the header for a valid hostname...
Spammers, harvest these...
postm...@aol.com
postm...@msn.com
postm...@microsoft.com
postm...@fbi.gov
postm...@agis.com
LWR...@BELLATLANTIC.NET
postm...@cyberpromo.com
David Lesher
Sgt. SternFUD announces:
{I see the MACpert still can't figure out how to wrap lines. Must
be too hard for him to figure out, alas....}
>Another suggested that some frequent posters here have made no
>significant contributions to PGP.
I must have missed that unidentified "Another" here...
>I could cite that my PGP keys were among the earliest posted to
>the server, that one were signed by the "fathers" of free MIT PGP,
>Jeff Schiller and Derek Atkins, that it was thus one remove from
>Phil's key if we're talking web of trust, and thus that I was an
>early adopter and supporter-by-use.
Gee, I have a key signed by all kinds of folks, too. Somehow I never
David Sternlight
Stuart Krivis wrote:
> On 24 Dec 1998 21:54:36 +0100, Anonymous <nob...@replay.com> wrote:
>
> >Mr. Sternlight, not giving in to the currents here, when did
> >you made a significant contribution to PGP? And on reflection,
> >when did you make a significant contribution to S/MIME?
>
> That's an easy one. He hates PGP and loves S/MIME.
Actually I quite like PGP for the trust model applications it's useful for, as I've said 'til I'm blue in the face. And my recommendation of S/MIME in the other thread was specifically for the situation the poster mentioned, where high reliance on pre-checked e-mail binding to a key was useful. If PGP provided that as an "only if" (Thawte does for PGP keys but any other PGP signature need not and most don't) then I would recommend PGP for that application. It's not a matter of "love" or "hate" but of what I think is most suitable for a particular application.
Some PGP fanatics have a very low tolerance for criticism on technical grounds, so whenever they see such a criticism of PGP they immediately try to demonize the critic rather than considering the criticism rationally. THEY may have a love relationship with PGP but my relationship to crypto systems is strictly business.
>
>
> This tells everyone to use PGP and not S/MIME. Significant
> contributions to both.
>
> I do have to hand it to SternFUD. He is tenacious. He's been
> shovelling his brand of crap for years and years.
>
> Very few people have rated a place in my killfile. Sternblight is in
> there. I suppose that could be considered quite an honor...
Since Kruvis has kill filed my posts, he clearly has little knowledge of much of their content and is in a poor position to comment. All he reads is selective responses mostly from such as Stone and Lesher, many out of context. Here's a fool who thinks so much of himself that he thinks being in his kill file is an honor. In my view anyone may kill file anyone else for any reason, or no reason at all. It's a matter of personal choice, or even whim. It's YOUR computer, not the poster's.
David
Liberty
> I think what Stone is trying to say is that he found a non-cryptographic flaw in the
> Verisign user interface, which had nothing to do with making a significant contribution to
> PGP.. I repeat my question.
He did me a big service when he posted that .. I got convinced that
netscape didn't take it security seriously. and that PGP was realy the only
way to go.
--
Liberty ...
-----------------------------------------------------------------
Liberty :Freedom is first earned
liberty...@revolutionist.com :by demanding it. It's lost by
:forgetting its value.
-----------------------------------------------------------------
David Sternlight
Liberty wrote:
> David Sternlight <da...@sternlight.com> wrote:
>
> > I think what Stone is trying to say is that he found a non-cryptographic flaw in the
> > Verisign user interface, which had nothing to do with making a significant contribution to
> > PGP.. I repeat my question.
>
> He did me a big service when he posted that .. I got convinced that
> netscape didn't take it security seriously. and that PGP was realy the only
> way to go.
If you think flaws that are quickly corrected when found are a sufficient condition to reject a security product, then you'd better not use any, including PGP. Nothing is perfect in this humanly fallible world. Not even you or I.
Having now taken the time to check Stone's pointers, it would seem that his claim of contribution is somewhat misleading and can easily be misinterpreted to make the underlying problem seem more than it was. What happened was that on the Verisign web site (not in the user's or Verisign's crypto software), the language for selecting a key inadvertently could have misled users into failing to select a long 1024 bit key when they could, and thus get the default 512 bit key. At that time, had they checked the drop down menu, they would have found the higher security key available. It was a misphrasing of instructions that was the problem, not a cryptographic flaw. Verisign's correction was simply to rephrase the instructions and change the default on the web site.
It was not, as Stone claims, Verisign's "erroneous invocation of the export grade CSP on the local machine" that was the problem. It was Verisign's poorly phrased instructions that led the user to accept a 512 bit default key rather than his selecting a longer one. As Stone himself says in his report to Verisign: "To get the high-security RSA 1024-bit key, ingore (sic) VeriSign's instructions, and select "Microsoft Enhanced Cryptographic Provider v1.0". You will then receive the RSA 1024-bit key."
To Verisign's credit, not only did they change the language, but they changed the web site software so it defaults to the highest security key the user can have. I would agree with a claim that this is what they should have done in the first place, but that still does not make Verisign's prior behavior an "erroneous invocation". And the problem was not a cryptographic flaw but an error in the instructions, and perhaps the failure to insure that the default was the highest, rather than the lowest security alternative the user had available.
Users who read this post should note that Verisign fixed the matter in June 1998, so those MSIE users with Verisign Class 1 keys generated after that date need not be concerned, nor should those MSIE users who generated keys before that date and selected the higher security option from the drop-down menu . It is those who generated keys before July 1998 and accepted the default on Verisign's site who might be concerned about encrypted traffic prior to key expiry. If the keys were free trial keys, they will have expired by now, so such users also need not be concerned about current and future use, though their past traffic might have used 512 bit keys (not the best thing).
I do not defend Verisign here; I simply report what the real situation was, and comment on Stone's possibly misleading exaggeration of the source of the flaw. I do not take anything away from the usefulness of Stone's discovery of this flaw..
----
One's risk diminishes (other things being equal) the longer a particular version has been on the market and there has been an opportunity for flaws to be found and corrected. Thus I would attribute less risk to PGP 2.x than to either PGP 5.x or 6.x or to versions of S/MIME in Netscape or Microsoft on that factor, other things being equal. Other things are not, however, equal. New versions, often with improved features, always carry a bit more risk and one is always trading off between improved features and at least temporarily higher risk.
David
Ed Stone
says...
Understanding your view of "Stone", can you now speak of your own
contributions? ;-)
Ed Stone
says...
>
>
> Stuart Krivis wrote:
>
> > On 24 Dec 1998 21:54:36 +0100, Anonymous <nob...@replay.com> wrote:
> >
> > >Mr. Sternlight, not giving in to the currents here, when did
> > >you made a significant contribution to PGP? And on reflection,
> > >when did you make a significant contribution to S/MIME?
> >
> > That's an easy one. He hates PGP and loves S/MIME.
>
> Actually I quite like PGP for the trust model applications it's useful for, as I've said 'til I'm blue in the face. And my recommendation of S/MIME in the other thread was specifically for the situation the poster mentioned, where high reliance on pre-checked e-mail binding to a key was useful. If PGP provided that as an "only if" (Thawte does for PGP keys but any other PGP signature need not and most don't) then I would recommend PGP for that application. It's not a
matter of "love" or "hate" but of what I think is most suitable for a particular application.
>
> Some PGP fanatics have a very low tolerance for criticism on technical grounds,
You have developed an empirical basis to connect and correlate PGP
"fanaticism" and "low tolerance for criticism on technical grounds"? Very
interesting. ;-)
> so whenever they see such a criticism of PGP they immediately try to demonize the critic rather than considering the criticism rationally.
Gosh, they must be EVIL!! Them!
> THEY may have a love relationship with PGP but my relationship to crypto systems is strictly business.
And balanced, fair, rational, technically astute, well-informed, and
clearly articulated without bias, as the pigs are cleared to flight level
20. ;-)
>
> >
> >
> > This tells everyone to use PGP and not S/MIME. Significant
> > contributions to both.
> >
> > I do have to hand it to SternFUD. He is tenacious. He's been
> > shovelling his brand of crap for years and years.
> >
> > Very few people have rated a place in my killfile. Sternblight is in
> > there. I suppose that could be considered quite an honor...
>
> Since Kruvis has kill filed my posts, he clearly has little knowledge of much of their content and is in a poor position to comment. All he reads is selective responses mostly from such as Stone and Lesher, many out of context. Here's a fool who thinks so much of himself that he thinks being in his kill file is an honor. In my view anyone may kill file anyone else for any reason, or no reason at all. It's a matter of personal choice, or even whim. It's YOUR computer,
not the poster's.
Possibly you are just not universally "appreciated".
Are we all following the potential for S/MIME CMS to interoperate with
PGP keys? (Sorry for the PGP-focused comment. ;-) )>
>
> David
Ed Stone
liberty...@revolutionist.com says...
> David Sternlight <da...@sternlight.com> wrote:
>
> > I think what Stone is trying to say is that he found a non-cryptographic flaw in the
> > Verisign user interface, which had nothing to do with making a significant contribution to
> > PGP.. I repeat my question.
>
> He did me a big service when he posted that .. I got convinced that
> netscape didn't take it security seriously. and that PGP was realy the only
> way to go.
Thank you, sir.
Ed Stone
says...
>
>
> Liberty wrote:
>
> > David Sternlight <da...@sternlight.com> wrote:
> >
> > > I think what Stone is trying to say is that he found a non-cryptographic flaw in the
> > > Verisign user interface, which had nothing to do with making a significant contribution to
> > > PGP.. I repeat my question.
> >
> > He did me a big service when he posted that .. I got convinced that
> > netscape didn't take it security seriously. and that PGP was realy the only
> > way to go.
>
The writer was not bemoaning a lack of perfection is this world, rather
he was responding to what he found as a sufficient sign to him that a
browser did not take security seriously. Those are different issues, and
the former is your strawman, the latter, his obvious point.
>
> Having now taken the time to check Stone's pointers, it would seem that his claim of contribution is somewhat misleading and can easily be misinterpreted to make the underlying problem seem more than it was. What happened was that on the Verisign web site (not in the user's or Verisign's crypto software), the language for selecting a key inadvertently could have misled users into failing to select a long 1024 bit key when they could, and thus get the default 512 bit
key. At that time, had they checked the drop down menu, they would have found the higher security key available. It was a misphrasing of instructions that was the problem, not a cryptographic flaw.
It was a default to weaker 512-bit keys, combined with instructions to
not alter the settings unless you were dealing with a certain type of
device like a smart card, combined with the resultant invocation of the
local machine's low-security, export grade cryptographic service provider
(CSP) to gen a 512-bit key without warning of its lesser security, even
when a US domestic "high security" version of MSIE was used to gen the
key... Quite an extraordinary confluence of errors, all leading to more
small keys, wouldn't you say? ;-) If you are not concerned about
inadvertant generation of small key sizes, then you may see no problem
with this major flaw in the VeriSign/MSIE key gen process.
> Verisign's correction was simply to rephrase the instructions and change the default on the web site.
Only that? You mean they now don't steer people to gen 512-bit keys when
those people could be genning 1024-bit keys? Very nice of them as a
security firm to do that... ;-)
>
> It was not, as Stone claims, Verisign's "erroneous invocation of the export grade CSP on the local machine" that was the problem. It was Verisign's poorly phrased instructions that led the user to accept a 512 bit default key rather than his selecting a longer one. As Stone himself says in his report to Verisign: "To get the high-security RSA 1024-bit key, ingore (sic) VeriSign's instructions, and select "Microsoft Enhanced Cryptographic Provider v1.0". You will then
receive the RSA 1024-bit key."
It was exactly that. You will need to study the MS CryptoAPI, CSPs, and a
few other technical details to grasp this matter. VeriSign had no trouble
grasping it after I pointed it out to them. I would have expected them to
do their own security quality control. Possibly some view key generation
as a matter not directly related to crypto security. I recommend Playfair
to people like that. ;-)
>
> To Verisign's credit, not only did they change the language, but they changed the web site software so it defaults to the highest security key the user can have. I would agree with a claim that this is what they should have done in the first place, but that still does not make Verisign's prior behavior an "erroneous invocation". And the problem was not a cryptographic flaw but an error in the instructions, and perhaps the failure to insure that the default was the
highest, rather than the lowest security alternative the user had available.
>
> Users who read this post should note that Verisign fixed the matter in June 1998, so those MSIE users with Verisign Class 1 keys generated after that date need not be concerned, nor should those MSIE users who generated keys before that date and selected the higher security option from the drop-down menu . It is those who generated keys before July 1998 and accepted the default on Verisign's site who might be concerned about encrypted traffic prior to key expiry. If the
keys were free trial keys, they will have expired by now, so such users also need not be concerned about current and future use, though their past traffic might have used 512 bit keys (not the best thing).
>
They are heroes for not ceasing to shove 512-bit keys to US domestic high
security browsers!! ;-)
> I do not defend Verisign here; I simply report what the real situation was, and comment on Stone's possibly misleading exaggeration of the source of the flaw. I do not take anything away from the usefulness of Stone's discovery of this flaw..
>
The real situation? You will need to get a little deeper into the
technical matters.
> ----
>
> One's risk diminishes (other things being equal) the longer a particular version has been on the market and there has been an opportunity for flaws to be found and corrected.
Does this apply to DES? ;-)
> Thus I would attribute less risk to PGP 2.x than to either PGP 5.x or 6.x or to versions of S/MIME in Netscape or Microsoft on that factor, other things being equal. Other things are not, however, equal. New versions, often with improved features, always carry a bit more risk and one is always trading off between improved features and at least temporarily higher risk.
>
> David
>
>
>
--
David Sternlight
ssim...@hertreg.ac.uk wrote:
<non-productive matter excised>
>
> > As to MD5, it may be a bit long in the tooth, but the greatest experts on
> that say that there is no hurry to replace it and that it may be replaced at
> the next version upgrade of a product.
>
> Shall I cite eminent cryptographers who disagree with this statement? Ok,
> just for you:
>
> “Therefore we suggest that in the future MD5 should no longer be implemented
> in applications like signature schemes, where a collision-resistant hash
> function is required.”
>
> (H.Dobbertin, “The Status of MD5 After a Recent Attack”, RSA CryptoBytes ?
> Volume2, Number2, Summer 96.)
"in the future" does not mean "drop it now from existing applications". The above
is perfectly consistent with RSA's advice to move to something else at the next
revision. There is no rush. In fact RSADSI PKCS has gone to #11 (used in Microsoft
and Netscape software) some time ago.
<more non-productive matter excised>
David
David Sternlight
ssim...@hertreg.ac.uk wrote:
> My FAQ will be short on opinion and heavy on statements from well respected
cryptographers.
What is wanted in a FAQ is substance rather than appeal to authority.
David
David Sternlight
ssim...@hertreg.ac.uk wrote:
> In article <3682C203...@sternlight.com>,
> da...@sternlight.com wrote:
>
> <SNIP>
>
> > And now to the FAQ input, partially paraphrased from the two RSADSI FAQ items
> referred to at the end. Readers of this post should note that the RSADSI FAQ
> will answer many questions readers have about cryptography, PGP, S/MIME, RSA,
> digital signatures, etc.
> >
> > What is a message digest?
> > A message digest is a shortened, or compressed version of the text of a
> message. Its algorithm is also known as a hash function.
> >
>
> Incorrect terminology ? refer to Handbook of Applied Cryptography.
>
> Actually Dr Sternlight, I have twice before corrected you (do I need to cite?)
> on references to Hash Functions ? maybe you should desist from commenting on
> hash functions in the future.
Derived from the RSA FAQ written by a far more professional and experienced
cryptographer than you or I.
>
>
> <SNIP>
> > What about MD5?
> > MD5 is a message digest algorithm used in a number of S/MIME implementations
> including the current versions of Netscape Communicator and Microsoft Outlook
> Express. Its author, RSADSI, recommends that it be replaced at the next major
> version change of such implementations.
> >
>
> Is MD5 a “MUST” algorithm in the latest (v3) S/Mime standard? No, SHA-1 is.
If you wish to make this point separately, you should. But it is irrelevant to the
matter just above. You are still being argumentative rather than developing a FAQ.
To use a FAQ as a thinly disguised way of making an argument is not only a
disservice to the reader, but dishonest.
You may say that the latest versions of Netscape and (AFAIK) MIcrosoft S/MIME
(probably since 4.0 and I have it in Netscape 4.5 as I write) have added SHA-1.
Thus this issue is a red herring. MD5 is included in the current versions of NS
and (AFAIK) MS via RSADSI's PKCS #11. So is SHA-1 and, come to that, DSA.. And
including MD5 is an important thing to do so that you can still validate past
traffic or archived traffic if you wish. You have to get off your biases and see
the situation for what it is.
>
>
> What do the most respected hash function cryptographers say about MD5?:
>
> “Therefore we suggest that in the future MD5 should no longer be implemented
> in applications like signature schemes, where a collision-resistant hash
> function is required.”
>
> H.Dobbertin, “The Status of MD5 After a Recent Attack”, RSA CryptoBytes ?
> Volume2, Number2, Summer 96.
What part of "in the future" don't you understand? And Dobbertin is flat wrong,
unless you have quoted him out of context. While it is true that one should
include SHA-1, and perhaps DSA, one must also include MD5 in order to be able to
authenticate past traffic. The alternative is for the user to have to keep two
systems around.
This is also the mistake PGP made when dropping RSA. It put users of the newer
free versions in a position where they were unable to send or receive to past RSA
keys, and unable to decrypt or authenticate past archived traffic. While there was
nothing wrong with PGP adding new algorithms they liked, they should have kept
RSA. As we have seen, their action has forced some users to ignore the new free
version and keep using less convenient older free versions, other users to have to
keep two versions, and yet other users who would have preferred the free version
to have to get the pay version and then pay yet more for the RSA module. There is
considerable resentment in the user base because of this to this day. These are
hard facts and no amount of hand-waving or personal attack can alter them.
>
>
> Still, you will have to wait for the full FAQ. Frankly, this FAQ isn’t
> designed to appease you, instead it is meant as an informative and
> authoritative document on the cryptographic security of PGP. You are entitled
> to comment on the FAQ, as is every other member of this forum.
I am simply trying to be helpful in urging you to see beyond your prejudices and
partisan views. I have offered some draft material and you have taken that as yet
another occasion to be rancorous. It does not augur well for the work you are
doing. I do not want you to appease me, but to present an accurate and unbiased
version of the facts and issues. Please get off it, so you can benefit everyone.
David
David Sternlight
Ed Stone wrote:
>
> The writer was not bemoaning a lack of perfection is this world, rather
> he was responding to what he found as a sufficient sign to him that a
> browser did not take security seriously. Those are different issues, and
> the former is your strawman, the latter, his obvious point.
I think this to be a dishonest remark. As you yourself know, the problem was with Verisign's web site and not the browser.
David
ssim...@hertreg.ac.uk
da...@sternlight.com wrote:
>
>
> ssim...@hertreg.ac.uk wrote:
>
> > I am in the process of writing the FAQ nearly as we speak.
> >
> > The FAQ will (hopefully!) be a central source for information regarding the
> > cryptographic strength of algorithms supported by PGP.
> >
> > Some in this forum may not like sections of the FAQ (for example some people
> > seem to have an unnatural fascination with MD5, RSA etc) but they will not
be
> > able to detract from the sources of the information contained.
>
> If you have any hope of producing an accurate FAQ rather than a partisan
screed, you must get that chip off your shoulder. There is no "unnatural
fascination" with RSA and MD5.
I have no “chip on my shoulder”. I have an interest in pursuing the
implementation of communication and information security for “the masses”.
Unfortunately, I can’t stand misinformation and uninformed opinion, which you
seem to produce occasionally. This isn’t a personal attack (I haven’t got
time to get into a flame war) but rather an observation of fact. Would you
like me to produce quotes of your misinformation? Or can we move on without
bickering further?
>RSA is the de facto crypto algorithm used in tens if not hundreds of millions
of copies of the de facto standard applications in their class, including
Lotus Notes, Microsoft Internet Explorer/Outlook Express, and Netscape
Communicator, as well as many other packages from IBM, DEC, Apple, and even
Network Associates' own Trusted Information Systems.. Not to recognize this
is to have one's head in the sand.
So defacto standard = equals better than the alternatives? I think not.
Maybe you could explain to this group why RSA is better than its many
alternatives?
> What is more PGP does not even attempt to provide the package functions of
the above--it is a crypto add-on. Thus one is trying to compare a separate
add- on which is incompatible with the existing crypto package in the above
applications, with that built-in crypto package which users of the
applications already have. This must be recognized for any realistic
appreciation of PGP's situation.
>
I have already stated that the FAQ is a review of the cryptographic security
of PGP.
> As to MD5, it may be a bit long in the tooth, but the greatest experts on
that say that there is no hurry to replace it and that it may be replaced at
the next version upgrade of a product.
Shall I cite eminent cryptographers who disagree with this statement? Ok,
just for you:
“Therefore we suggest that in the future MD5 should no longer be implemented
in applications like signature schemes, where a collision-resistant hash
function is required.”
(H.Dobbertin, “The Status of MD5 After a Recent Attack”, RSA CryptoBytes –
Volume2, Number2, Summer 96.)
> Most "true believers" tend to see those who have another view as attempting
to "detract from" their true belief. Yet is is just those "true beliefs"
which originally arose from questioning the conventional wisdom. In effect,
the "true believers" have become the thing they hate. I see ample evidence of
that here, whenever flaws in PGP are raised, or it is suggested that
something else might be more suitable for a particular purpose.
I look forward to your civil criticism of the FAQ.
You will note that I am not a “true believer” (whatever that means) of PGP – I
have been candid with my criticism of aspects of PGP.
> > I see your point, some on this group are very quick to argue and bicker but
> > are slow to do anything to actually progress PGP and crypto use in general.
>
> Sorry--when was it that Stone or Lesher last made a significant contribution
to PGP? I must have missed it.
You seem to be a little touchy about something. I didn’t name names or point
fingers, I was just making a general observation on this group. Maybe you
would like to challenge MY contributions to this group and the application of
cryptography?
Sam
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
ssim...@hertreg.ac.uk
da...@davidham.demon.co.uk (David Hamilton) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> ssim...@hertreg.ac.uk wrote:
>
> >PGP DH vs. PGP RSA FAQ
>
> (snip all)
>
> Excellent idea Sam. I will find sections 2-4 interesting (public key, hash
> functions, conventional cipher) ... but I'm not so interested in the
> performance differences aspects which you intend to cover under these
> headings. I have to admit that I don't expect to find section 5 interesting
> ... but that may depend on your writing style!
You are quite right of course, performance is secondary to security. Still,
these figures are included for completeness.
> 2.5 years ago, I wrote a 'PGP for Absolute Beginners' piece which Bill Unruh
> hosts on his cryptography site (http://axion.physics.ubc.ca/crypt.html).
I have read it, good piece.
> When I suggested the idea in alt.security.pgp, the response was absolutely
> ... luke warm. However, I enjoyed doing it, found it to be a useful learning
> process and, over the years, have had about a dozen people thank me. I regard
> that as a success.
>
> You have a more difficult task: the subject area is larger and, probably,
> your target audience is not as tightly defined. You'll get people arguing
> over any opinion you express but, hopefully, they won't argue over the facts.
> Good luck with the FAQ: I'm sure it will be worthwhile.
My FAQ will be short on opinion and heavy on statements from well respected
cryptographers. To be honest, people are more than welcome to check the
copious references I provide. I have already posted a (very!) draft version
of the most contentious section of the FAQ to this group, and the response
was “timid”.
> David Hamilton. Only I give the right to read what I write and PGP allows me
> to make that choice. Use PGP now.
Thanks (once again!) for your positive input to this forum Dave. (BTW good
sig!).
Seasonal greetings,
Sam.
ssim...@hertreg.ac.uk
<SNIP>
> And now to the FAQ input, partially paraphrased from the two RSADSI FAQ items
referred to at the end. Readers of this post should note that the RSADSI FAQ
will answer many questions readers have about cryptography, PGP, S/MIME, RSA,
digital signatures, etc.
>
> What is a message digest?
> A message digest is a shortened, or compressed version of the text of a
message. Its algorithm is also known as a hash function.
>
Incorrect terminology – refer to Handbook of Applied Cryptography.
Actually Dr Sternlight, I have twice before corrected you (do I need to cite?)
on references to Hash Functions – maybe you should desist from commenting on
hash functions in the future.
<SNIP>
> What about MD5?
> MD5 is a message digest algorithm used in a number of S/MIME implementations
including the current versions of Netscape Communicator and Microsoft Outlook
Express. Its author, RSADSI, recommends that it be replaced at the next major
version change of such implementations.
>
Is MD5 a “MUST” algorithm in the latest (v3) S/Mime standard? No, SHA-1 is.
What do the most respected hash function cryptographers say about MD5?:
“Therefore we suggest that in the future MD5 should no longer be implemented
in applications like signature schemes, where a collision-resistant hash
function is required.”
H.Dobbertin, “The Status of MD5 After a Recent Attack”, RSA CryptoBytes –
Volume2, Number2, Summer 96.
Still, you will have to wait for the full FAQ. Frankly, this FAQ isn’t
designed to appease you, instead it is meant as an informative and
authoritative document on the cryptographic security of PGP. You are entitled
to comment on the FAQ, as is every other member of this forum.
Anonymous
David Sternlight wrote:
>This is also the mistake PGP made when dropping RSA. It put users
>of the newer free versions in a position where they were unable to
>send or receive to past RSA keys, and unable to decrypt or
>authenticate past archived traffic. While there was nothing wrong
>with PGP adding new algorithms they liked, they should have kept
>RSA. As we have seen, their action has forced some users to ignore
>the new free version and keep using less convenient older free
>versions, other users to have to keep two versions, and yet other
>users who would have preferred the free version to have to get the
>pay version and then pay yet more for the RSA module. There is
>considerable resentment in the user base because of this to this
>day. These are hard facts and no amount of hand-waving or personal
>attack can alter them.
Mr. Sternlight, as you may recall, there was a change in
format between PGP versions 2.3a and 2.6. This change was
executed fully in software and triggered by a timer at a
specific date. While this was due to a legality issue, there
is evidence that PGP has, in the past, forced users to
upgrade to a newer version. At present, motives and methods
differ, yet there is little difference in the mode of
delivery. Comment?
Quote from the docs of PGP 2.6x:
"This format change beginning with 2.6 is similar to the
process that naturally happens when new features are added,
causing older versions of PGP to be unable to read stuff
from the newer PGP, while the newer version can still read
the old stuff. The only difference is that this is a
"legal upgrade", instead of a technical one. It's a
worthwhile change, if it can achieve peace in our time."
Please bear in mind that PGP 6.0.2 can read RSA even in the
DH-only version, with the use of IE 128-bit upgrade, so there
is little need to conjure unneccessary paranoia on behalf of
the old user base.
- --EO
BTW, could you engage your line wrap? It's a pain to
edit the lines by hand when replying.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2
iQEVAwUBNoSRXcgXRmWyooNRAQH9xQf/Z7gvaR1prS/YGeXFz187vwQH50R360m9
sMosGoDh6eDVDAbQGKcBw52oN5lh9ZjbbmTId1eVSULnmfudpooJggGs9bLxAyIf
/9kTh+Cr4JST6LWSgpDebqkI2uDVEg3E1gGJ9R8aBPZdRwCwzJVCUBjurxavCu8e
8xkS7WpIt/P4tlLbgo9nJY12sBNGj1AxjvjnMEX2bdSKnfaeMfqSiPErofDx0ZMj
PnNAHaOi/U7ngYeJ2bS0TjLnxhPNDjvJI0EYk8NeCSuiBHfPA1k2Y/bmN8J8UNUH
zQeUL6bcwDIfbwuTkR3jU0kT4W65vfW+sj22F3mTBkQsXMJu9BO0eQ==
=0v0P
-----END PGP SIGNATURE-----
Ed Stone
says...
> > that say that there is no hurry to replace it and that it may be replaced at
> > the next version upgrade of a product.
> >
> > Shall I cite eminent cryptographers who disagree with this statement? Ok,
> > just for you:
> >
> > in applications like signature schemes, where a collision-resistant hash
> > function is required.”
> >
> > Volume2, Number2, Summer 96.)
>
> "in the future" does not mean "drop it now from existing applications". The above
> is perfectly consistent with RSA's advice to move to something else at the next
> revision. There is no rush.
RSADSI made that recommendation in November, 1996. One year ago, would be
"in the future" for that recommendation. ;-)
> In fact RSADSI PKCS has gone to #11 (used in Microsoft
> and Netscape software) some time ago.
Possibly they followed that now long-in-tooth RSADSI advice...
>
> <more non-productive matter excised>
>
> David
>
>
>
--
Ed Stone
says...
<snip>
> I am simply trying to be helpful in urging you to see beyond your prejudices and
> partisan views. I have offered some draft material and you have taken that as yet
> another occasion to be rancorous. It does not augur well for the work you are
> doing. I do not want you to appease me, but to present an accurate and unbiased
> version of the facts and issues. Please get off it, so you can benefit everyone.
>
> David
This may be Mr. Sternlight's way of offering to do the FAQ, and allow
others to review and revise it!
Ed Stone
says...
>
>
> Ed Stone wrote:
>
> >
> > The writer was not bemoaning a lack of perfection is this world, rather
> > he was responding to what he found as a sufficient sign to him that a
> > browser did not take security seriously. Those are different issues, and
> > the former is your strawman, the latter, his obvious point.
>
>
> David
If that is how you view it, that is how you view it. But when can we see
your list of your contributions to PGP?
David Lesher
FUD proclaims:
>What is wanted in a FAQ is substance rather than appeal to authority.
Thus it will be *very* interesting to read FUD's own FAQ, and see
if he practices what he preaches.
David Hamilton
David Sternlight <da...@sternlight.com> wrote:
>ssim...@hertreg.ac.uk wrote:
>> My FAQ will be short on opinion and heavy on statements from well
>> respected
>> cryptographers.
>What is wanted in a FAQ is substance rather than appeal to authority.
I didn't make the same inference from that quote as you. My inference is that
Sam's FAQ will contain substance and not 'appeal to authority' but evidence
('statements'). Sam's sentence immediately after the one quoted by you was
'To be honest, people are more than welcome to check the copious references I
provide.' This seems to be a very honest way of going about things.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<da...@davidham.demon.co.uk>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNoT9MMo1RmX6QSF5AQG/FQgAprDUdAckGqWvCzhNBCoEokSgWaUIXtTJ
JKkBPI8PgpKU4YUoLelgh1OfO8pZoP8LCeOdGnvR45DlpbuLrlGZqc+l3eBFoMNk
1w42EKNWINjmqUIYguMsOypYouBjQOt44J2u7T2zFuGKVPc9I2REpG7+OuQxPMgM
o78SZOsn89eGWWFC+G5+/UCu+JyLK8uBm7oS5tXHdEY2NdOmURuJwejLH7HTWrxw
hmwpoKz3TjolHgD3ZfygC5Ji6qi1Ls5nJfohtZk/IyHxjl8konSXeXAiP89+mnsD
HUK/TOBuZrai/DhYIU9bbXWfJNoGd0MDzBbJhwyDZQafkSxUjjhAKA==
=EYGf
-----END PGP SIGNATURE-----
David Sternlight
Ed Stone wrote:
> >
> > "in the future" does not mean "drop it now from existing applications". The above
> > is perfectly consistent with RSA's advice to move to something else at the next
> > revision. There is no rush.
>
> RSADSI made that recommendation in November, 1996. One year ago, would be
> "in the future" for that recommendation. ;-)
So? When did they switch to PKCS #11? A while ago as I recall. You can bird-dog the
date if you like--you're good at that kind of retrieval.
And surely we're not going to start quibbling about the timing of new versions, given
everyone's (including PGP's) glacial history of revisions in the past. How long were
we waiting for PGP 2.x? 3.x? (what?) 4.x? (what?) 5.x?
David
David Sternlight
David Hamilton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> David Sternlight <da...@sternlight.com> wrote:
>
> >ssim...@hertreg.ac.uk wrote:
>
> >> My FAQ will be short on opinion and heavy on statements from well
> >> respected
> >> cryptographers.
>
> >What is wanted in a FAQ is substance rather than appeal to authority.
>
> I didn't make the same inference from that quote as you.
My inference is based on his already-posted discussion of some of the issues the
FAQ will cover, which were pure appeal to authority.
David
ssim...@hertreg.ac.uk
da...@sternlight.com wrote:
>
>
> ssim...@hertreg.ac.uk wrote:
>
> > In article <3682C203...@sternlight.com>,
> > da...@sternlight.com wrote:
> >
> > <SNIP>
> >
> > > And now to the FAQ input, partially paraphrased from the two RSADSI FAQ
items
> > referred to at the end. Readers of this post should note that the RSADSI FAQ
> > will answer many questions readers have about cryptography, PGP, S/MIME,
RSA,
> > digital signatures, etc.
> > >
> > > What is a message digest?
> > > A message digest is a shortened, or compressed version of the text of a
> > message. Its algorithm is also known as a hash function.
> > >
> >
> >
> > Actually Dr Sternlight, I have twice before corrected you (do I need to
cite?)
> > hash functions in the future.
>
> cryptographer than you or I.
I think "derived" is the key word in that sentance. In the process of
"deriving" you have missused terminology.
> > <SNIP>
> > > What about MD5?
> > > MD5 is a message digest algorithm used in a number of S/MIME
implementations
> > including the current versions of Netscape Communicator and Microsoft
Outlook
> > Express. Its author, RSADSI, recommends that it be replaced at the next
major
> > version change of such implementations.
> > >
> >
> > Is MD5 a “MUST” algorithm in the latest (v3) S/Mime standard? No, SHA-1 is.
>
> If you wish to make this point separately, you should. But it is irrelevant
to the
> matter just above. You are still being argumentative rather than developing a
FAQ.
> To use a FAQ as a thinly disguised way of making an argument is not only a
> disservice to the reader, but dishonest.
>
You will see in the FAQ that I have made some very strong argument _against_
some of the technology used in PGP in preference to other technology.
<SNIP>
> > What do the most respected hash function cryptographers say about MD5?:
> >
> > “Therefore we suggest that in the future MD5 should no longer be implemented
> > in applications like signature schemes, where a collision-resistant hash
> > function is required.”
> >
> > H.Dobbertin, “The Status of MD5 After a Recent Attack”, RSA CryptoBytes ?
> > Volume2, Number2, Summer 96.
>
> What part of "in the future" don't you understand? And Dobbertin is flat
wrong,
> unless you have quoted him out of context.
Check the context yourself! May I remind you that Dobertin is one of THE most
respected cryptographers in respect of hash functions.
Maybe you should learn respect?
Maybe you should check context of quotes before you say that an eminent
cryptographer is "wrong".
<SNIP>
> > Still, you will have to wait for the full FAQ. Frankly, this FAQ isn’t
> > designed to appease you, instead it is meant as an informative and
> > authoritative document on the cryptographic security of PGP. You are
entitled
> > to comment on the FAQ, as is every other member of this forum.
>
> I am simply trying to be helpful in urging you to see beyond your prejudices
and
> partisan views.
I have no prejudice. To the contrary, I am just quoting the most respected
cryptographers. It would appear that _you_ have an unnatural fascination with
"broken" technology (MD5).
> I have offered some draft material and you have taken that as yet
> another occasion to be rancorous.
I (and eminent cryptographers) disagree with your humble opinion.
> It does not augur well for the work you are
> doing. I do not want you to appease me, but to present an accurate and
unbiased
> version of the facts and issues.
No doubt you will be pleased by the new FAQ then.
Sam
> Please get off it, so you can benefit everyone.
>
> David
-----------== Posted via Deja News, The Discussion Network ==----------
ssim...@hertreg.ac.uk
da...@davidham.demon.co.uk (David Hamilton) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> David Sternlight <da...@sternlight.com> wrote:
>
> >ssim...@hertreg.ac.uk wrote:
>
> >> My FAQ will be short on opinion and heavy on statements from well
> >> respected
> >> cryptographers.
>
> >What is wanted in a FAQ is substance rather than appeal to authority.
>
> Sam's FAQ will contain substance and not 'appeal to authority' but evidence
> ('statements'). Sam's sentence immediately after the one quoted by you was
> 'To be honest, people are more than welcome to check the copious references I
> provide.' This seems to be a very honest way of going about things.
>
> David Hamilton. Only I give the right to read what I write and PGP allows me
> to make that choice. Use PGP now.
Unfortunately, it would appear David Sternlight has shown his agenda in
another post to this group, where he claims that a most respected
cryptographer who specialises in Hash Functions, Hans Dobbertin was "flat
wrong". I note with some interest that the eminent Dobbertin has papers
published by RSA Labs and is mentioned in AC2 and HAC. I can't seem to find
such reference of credentials from Sternlight however....
Maybe Sternlight would like to provide citations which prove that Dobbertin is
"flat wrong"? Or maybe he can't?
Hey, I'll stand by my statements (and the FAQ), will you Sternlight?
I am sure most on this group will recognise that I am fairly clear and
unbiased in respect of crypto - if my FAQ somehow appears to some as "appeal
to authority" then maybe they would prefer if I were more subjective?
Anyway, I guess the FAQ will be complete within a week... Its running at 20
pages at the moment... The section on "S/Mime vs PGP" takes up substantial
space :-)
TTFN,
Sam.
David Sternlight
ssim...@hertreg.ac.uk wrote:
> In article <3684fef0...@news.demon.co.uk>,
> da...@davidham.demon.co.uk (David Hamilton) wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > David Sternlight <da...@sternlight.com> wrote:
> >
> > >ssim...@hertreg.ac.uk wrote:
> >
> > >> My FAQ will be short on opinion and heavy on statements from well
> > >> respected
> > >> cryptographers.
> >
> > >What is wanted in a FAQ is substance rather than appeal to authority.
> >
> > I didn't make the same inference from that quote as you. My inference is that
> > Sam's FAQ will contain substance and not 'appeal to authority' but evidence
> > ('statements'). Sam's sentence immediately after the one quoted by you was
> > 'To be honest, people are more than welcome to check the copious references I
> > provide.' This seems to be a very honest way of going about things.
> >
> > David Hamilton. Only I give the right to read what I write and PGP allows me
> > to make that choice. Use PGP now.
>
> Unfortunately, it would appear David Sternlight has shown his agenda in
> another post to this group, where he claims that a most respected
> cryptographer who specialises in Hash Functions, Hans Dobbertin was "flat
> wrong". I note with some interest that the eminent Dobbertin has papers
> published by RSA Labs and is mentioned in AC2 and HAC. I can't seem to find
> such reference of credentials from Sternlight however....
I am sure Dobbertin would agree if you asked him, that one should keep old
algorithms around if they are needed to read archived traffic. I am pretty sure
that either you quoted him out of context or he hadn't thought his statement
through. You are starting to sound like a loon.
>
>
> Maybe Sternlight would like to provide citations which prove that Dobbertin is
> "flat wrong"? Or maybe he can't?
In my original post I gave the above reasoning. You have excised it in order to
take a comment of mine out of context. You ARE starting to sound like a loon.
>
>
> Hey, I'll stand by my statements (and the FAQ), will you Sternlight?
You are fond of appeal to authority instead of explanation. That is an ignorant
and inappropriate way to write a FAQ.
>
>
> I am sure most on this group will recognise that I am fairly clear and
> unbiased in respect of crypto - if my FAQ somehow appears to some as "appeal
> to authority" then maybe they would prefer if I were more subjective?
No. More factual. Don't say "X is good because Y says so." Explain why X is good.
That's what a FAQ is supposed to do.
>
>
> Anyway, I guess the FAQ will be complete within a week... Its running at 20
> pages at the moment... The section on "S/Mime vs PGP" takes up substantial
> space :-)
I am eager to see your explanation of the differing trust models (which is the key
difference in the most common implementations), the place where each trust model
is suitable, and the trust institutions and infrastructure behind each. I am
withholding judgment until I see the results of your effort.
David
David Sternlight
ssim...@hertreg.ac.uk wrote:
> > > >
> > > > What is a message digest?
> > > > A message digest is a shortened, or compressed version of the text of a
> > > message. Its algorithm is also known as a hash function.
> > > >
> > >
> > > Incorrect terminology ? refer to Handbook of Applied Cryptography.
> > >
> > > Actually Dr Sternlight, I have twice before corrected you (do I need to
> cite?)
> > > on references to Hash Functions ? maybe you should desist from commenting on
> > > hash functions in the future.
> >
> > Derived from the RSA FAQ written by a far more professional and experienced
> > cryptographer than you or I.
>
> I think "derived" is the key word in that sentance. In the process of
> "deriving" you have missused terminology.
You are still trying to rehash a losing argument, which is based on trying to make
the dictionary argument some have criticized. My use of "checksum", "hash function"
and "message digest" was itself taken from RSA material. If you disagree with
that, fine, but don't throw some other reference (Handbook of Applied Cryptography)
at the words of the world's most eminent cryptographers outside the NSA because you
want to try to make debating points with me. I thought you were the one claiming
that one should kiss the hem of the robe of "eminent cryptographers" such as
Dobbertin, even when their statements seemed wrong.
Which is it? Eminent cryptographers should have their word accepted regardless, or
eminent cryptographers should have their word accepted only when they agree with
Simpson? As for me, I read the words, not the eminence, and think for myself.
> > > What do the most respected hash function cryptographers say about MD5?:
> > >
> > > “Therefore we suggest that in the future MD5 should no longer be implemented
> > > in applications like signature schemes, where a collision-resistant hash
> > > function is required.”
> > >
> > > H.Dobbertin, “The Status of MD5 After a Recent Attack”, RSA CryptoBytes ?
> > > Volume2, Number2, Summer 96.
> >
> > What part of "in the future" don't you understand? And Dobbertin is flat
> wrong,
> > unless you have quoted him out of context.
>
> Check the context yourself! May I remind you that Dobertin is one of THE most
> respected cryptographers in respect of hash functions.
>
> Maybe you should learn respect?
>
> Maybe you should check context of quotes before you say that an eminent
> cryptographer is "wrong".
No. If a quote is subject to misinterpretation out of context it is YOUR
responsibility, as the presenter of the quotes, to provide that context.
Dobbertin's quote clearly says "no longer be implemented in applications" and that
is clearly wrong since it would mean one could no longer read archived traffic. If
you asked Dobbertin, I'm sure he'd agree, and rephrase, unless he had already done
so in the context you excised.
>
>
> <SNIP>
> > > Still, you will have to wait for the full FAQ. Frankly, this FAQ isn’t
> > > designed to appease you, instead it is meant as an informative and
> > > authoritative document on the cryptographic security of PGP. You are
> entitled
> > > to comment on the FAQ, as is every other member of this forum.
> >
> > I am simply trying to be helpful in urging you to see beyond your prejudices
> and
> > partisan views.
>
> I have no prejudice. To the contrary, I am just quoting the most respected
> cryptographers. It would appear that _you_ have an unnatural fascination with
> "broken" technology (MD5).
You ARE sounding like a loon. What is this "unnatural fascination" stuff? When we
discuss MD5 (which in fact Stone first criticized here), if I respond and then we
go through the comment-response-comment-response cycle it is "unnatural
fascination"? What about those who comment on my comments (which were themselves
comments on others' comments about MD5)? Are they also suffering this "unnatural
fascination"? Are you, since you seem to engage in the same discussion?
Let's remind ourselves of the presenting argument, made by Stone (as I recall). It
was that PGP was justified in removing RSA from free PGP because MD5 might be found
to be weak at a later date, so argued because (although there were as yet no
complete hash function collisions, which would be a real threat) there were
compression function collisions. Thus this was basically an argument about whether
dropping RSA was justified. As was shown, SHA-1 and DSA could be (and were)
included in later revisions (as RSADSI suggested) of Netscape and Microsoft's
packages and RSADSI's PKCS #11 without the need to drop RSA. PGP could have done
the same. Therefore the argument that the justification for dropping RSA from PGP
was MD5 is refuted, and we must look elsewhere. (I say, to PGP's vendetta against
RSA because RSA blew the legal whistle on their license violations cum
infringements.)
Then we move on to another argument--that they dropped it from free PGP because the
RSA license cost money. I showed this also to be false since RSAREF, the RSA
package which could be used with free versions of crypto packages, was free.
Then we moved onto another argument, that the RSAREF 2 license terms might be
onerous. I showed that RSAREF (1.x) was still viable, licensable and had no such
onerous license terms.
Then we moved to the argument about two code bases, and I showed that since RSAREF
was a drop-in maintained by RSADSI this wasn't a big issue.
There was also a silly diversion by Stone on the subject of whether RSADSI revised
their stuff with respect to their recommendation about message digests, presented
as an unsupported attack without evidence as to RSADSI's actual revisions, and
without reference to the speed of PGP's own earlier revisions. We were waiting for
some promised PGP revisions for well over a year after they were expected.
We also had a discussion of the "book" method of transmission using one code base,
but that involved multiple volumes and multiple alternative versions (since PGP has
such for different platforms, free vs. pay, etc.), and in addition that itself
introduces far more room for error than using RSAREF as a drop-in for free PGP.
And so on.
This was a major issue seized by some in this group which dragged on for some time
and was actively participated in by at least Stone and myself, with some
contributions from others. It was quite relevant to PGP and hardly "unnatural".
Although there were unpleasant atmospherics when some didn't like being refuted, it
was basically a sensible, sequential argument about an important issue. Your
attempts to discredit by the use of "unnatural fascination" must thus be seen for
the nonsense they are.
>
>
> > I have offered some draft material and you have taken that as yet
> > another occasion to be rancorous.
>
> I (and eminent cryptographers) disagree with your humble opinion.
I think there is no doubt you were rancorous. Read your own words. You may disagree
with my draft, but there's no need for rancor since it was factually based and
itself non-polemical.
>
>
> > It does not augur well for the work you are
> > doing. I do not want you to appease me, but to present an accurate and
> unbiased
> > version of the facts and issues.
>
> No doubt you will be pleased by the new FAQ then.
I suspend further judgment until it is revealed. I have pointed out some possible
pitfalls based on your posts here to date, and I devoutly hope you don't fall into
them.
David
nos...@synernet.com
says...
>
>
> ssim...@hertreg.ac.uk wrote:
>
> > > > >
> > > > > What is a message digest?
> > > > > A message digest is a shortened, or compressed version of the text of a
> > > > message. Its algorithm is also known as a hash function.
> > > > >
> > > >
> > > > Incorrect terminology ? refer to Handbook of Applied Cryptography.
> > > >
> > > > Actually Dr Sternlight, I have twice before corrected you (do I need to
> > cite?)
> > > > on references to Hash Functions ? maybe you should desist from commenting on
> > > > hash functions in the future.
> > >
> > > Derived from the RSA FAQ written by a far more professional and experienced
> > > cryptographer than you or I.
> >
> > I think "derived" is the key word in that sentance. In the process of
> > "deriving" you have missused terminology.
>
> You are still trying to rehash a losing argument,
> which is based on trying to make
> the dictionary argument some have criticized.
> My use of "checksum", "hash function"
> and "message digest" was itself taken from RSA material.
> If you disagree with
> that, fine, but don't throw some other reference (Handbook of Applied Cryptography)
> at the words of the world's most eminent cryptographers outside the NSA
> because you
> want to try to make debating points with me.
> I thought you were the one claiming
> that one should kiss the hem of the robe of "eminent cryptographers" such as
> Dobbertin, even when their statements seemed wrong.
kissed. Pointer? ;-)
>
> Which is it? Eminent cryptographers should have their word accepted regardless, or
> eminent cryptographers should have their word accepted only when they agree with
> Simpson?
RSADSI lackey" to paraphrase the rhetoric of an older generation.
>
> > > > What do the most respected hash function cryptographers say about MD5?:
> > > >
> > > > “Therefore we suggest that in the future MD5 should no longer be implemented
> > > > in applications like signature schemes, where a collision-resistant hash
> > > > function is required.”
> > > >
> > > > H.Dobbertin, “The Status of MD5 After a Recent Attack”, RSA CryptoBytes ?
> > > > Volume2, Number2, Summer 96.
> > >
> > > What part of "in the future" don't you understand? And Dobbertin is flat
> > wrong,
> > > unless you have quoted him out of context.
> >
> > Check the context yourself! May I remind you that Dobertin is one of THE most
> > respected cryptographers in respect of hash functions.
> >
> > Maybe you should learn respect?
> >
> > Maybe you should check context of quotes before you say that an eminent
> > cryptographer is "wrong".
>
> No. If a quote is subject to misinterpretation out of context it is YOUR
> responsibility, as the presenter of the quotes, to provide that context.
of context to me. ;-)
> Dobbertin's quote clearly says "no longer be implemented in applications" and that
> is clearly wrong since it would mean one could no longer read archived traffic.
message digests for authentication, not for encryption/confidentiality.
> If
> you asked Dobbertin, I'm sure he'd agree, and rephrase, unless he had already done
> so in the context you excised.
"sure" to mean "possibly"? ;-)
>
> >
> >
> > <SNIP>
> > > > Still, you will have to wait for the full FAQ. Frankly, this FAQ isn’t
> > > > designed to appease you, instead it is meant as an informative and
> > > > authoritative document on the cryptographic security of PGP. You are
> > entitled
> > > > to comment on the FAQ, as is every other member of this forum.
> > >
> > > I am simply trying to be helpful in urging you to see beyond your prejudices
> > and
> > > partisan views.
> >
> > I have no prejudice. To the contrary, I am just quoting the most respected
> > cryptographers. It would appear that _you_ have an unnatural fascination with
> > "broken" technology (MD5).
>
> You ARE sounding like a loon.
> What is this "unnatural fascination" stuff?
> When we
> discuss MD5 (which in fact Stone first criticized here), if I respond and then we
> go through the comment-response-comment-response cycle it is "unnatural
> fascination"? What about those who comment on my comments (which were themselves
> comments on others' comments about MD5)?
comments, which were comments on others comments?
> Are they also suffering this "unnatural
> fascination"? Are you, since you seem to engage in the same discussion?
>
> Let's remind ourselves of the presenting argument, made by Stone (as I recall). It
> was that PGP was justified in removing RSA from free PGP because MD5 might be found
> to be weak at a later date,
> so argued because (although there were as yet no
> complete hash function collisions, which would be a real threat) there were
> compression function collisions. Thus this was basically an argument about whether
> dropping RSA was justified.
> As was shown, SHA-1 and DSA could be (and were)
> included in later revisions (as RSADSI suggested) of Netscape and Microsoft's
> packages and RSADSI's PKCS #11 without the need to drop RSA. PGP could have done
> the same. Therefore the argument that the justification for dropping RSA from PGP
> was MD5 is refuted, and we must look elsewhere.
> (I say, to PGP's vendetta against
> RSA because RSA blew the legal whistle on their license violations cum
> infringements.)
>
> Then we move on to another argument--that they dropped it from free PGP because the
> RSA license cost money. I showed this also to be false since RSAREF, the RSA
> package which could be used with free versions of crypto packages, was free.
You'd grant RSADSI license to redistribute the application if you were
Networks Associates? An unusual view for a professional marketing and
economic strategy consultant. ;-)
>
> Then we moved onto another argument, that the RSAREF 2 license terms might be
> onerous. I showed that RSAREF (1.x) was still viable, licensable and had no such
> onerous license terms.
RSAREF "1.0" license of Jan 5, 1993:
"LICENSE. RSA grants you a non-exclusive, non-transferable,
perpetual (subject to the conditions of section 8) license
for the "RSAREF" program (the "Program") and its associated
documentation, subject to all of the following terms and
conditions: ... to modify the Program in any manner for porting or
performance improvement purposes (subject to Section 2)
or to incorporate the Program into other computer programs
for your own personal or internal use, provided that you
provide RSA with a copy of any such modification or
Application Program by electronic mail, and grant RSA
a perpetual, royalty-free license to use and distribute
such modifications and Application Programs on the terms
set forth in this Agreement."
But what do they mean, "Application Program"?
" "Application Programs" are programs which incorporate all or any
portion of the Program in any form. The restrictions imposed on
Application Programs in this Agreement shall not apply to any software
which, through the mere aggregation on distribution media, is
co-located or stored with the Program."
See http://bs.mit.edu/pgp/rsalicen.html
You advise this to Networks Associates as a professional economic and
marketing strategy consultant? Whewwwwww! ;-)
>
> Then we moved to the argument about two code bases, and I showed that since RSAREF
> was a drop-in maintained by RSADSI this wasn't a big issue.
Have you asked RSADSI if they still "maintain" RSAREF? ;-)
>
> There was also a silly diversion by Stone on the subject of whether RSADSI revised
> their stuff
Stuff? Is that a technical cryptographic term?
> with respect to their recommendation about message digests, presented
> as an unsupported attack without evidence as to RSADSI's actual revisions, and
> without reference to the speed of PGP's own earlier revisions.
If PGP's earlier revisions are very fast, or very slow, how does it alter
the cryptographic security of MD5? ;-)
> We were waiting for
> some promised PGP revisions for well over a year after they were expected.
And during that wait, MD5
(a) became stronger
(b) became weaker
(c) was unaffected
because we were waiting for some promised PGP revisions...
>
> We also had a discussion of the "book" method of transmission using one code base,
> but that involved multiple volumes and multiple alternative versions (since PGP has
> such for different platforms, free vs. pay, etc.), and in addition that itself
> introduces far more room for error than using RSAREF as a drop-in for free PGP.
Third verse, same as the first. ;-)
>
> And so on.
And on and on...
>
> This was a major issue seized by some in this group which dragged on for some time
> and was actively participated in by at least Stone and myself, with some
> contributions from others. It was quite relevant
And in context?
> to PGP and hardly "unnatural".
And Merriam Webster's Tenth defines "unnatural" as.....
> Although there were unpleasant atmospherics when some didn't like being refuted,
You are still footdragging about it.
> it
> was basically a sensible, sequential argument about an important issue. Your
> attempts to discredit by the use of "unnatural fascination" must thus be seen for
> the nonsense they are.
Fascinating important attempts to discredit Unnatural sequential loons
out of context?
>
> >
> >
> > > I have offered some draft material and you have taken that as yet
> > > another occasion to be rancorous.
> >
> > I (and eminent cryptographers) disagree with your humble opinion.
>
> I think there is no doubt you were rancorous.
Be polite like Mr. Sternlight, darn it!!
> Read your own words. You may disagree
> with my draft, but there's no need for rancor since it was factually based and
> itself non-polemical.
Oh YES! Like all of your post, not disputatious, not controversial, not
argumentative, not litigious! ;-)
>
> >
> >
> > > It does not augur well for the work you are
> > > doing. I do not want you to appease me, but to present an accurate and
> > unbiased
> > > version of the facts and issues.
> >
> > No doubt you will be pleased by the new FAQ then.
>
> I suspend further judgment until it is revealed. I have pointed out some possible
> pitfalls based on your posts here to date, and I devoutly hope you don't fall into
> them.
I expect you'd like a FAQ written by you or by RSADSI, and no others,
when it comes to crypto.
Pleasant holiday!
</tongue-in-cheek>
>
> David
D. Lakis
> In article <765rd5$pv7$1...@nnrp1.dejanews.com>, ssim...@hertreg.ac.uk
> wrote:
> >Anyway, I guess the FAQ will be complete within a week... Its running
> at 20 pages at the moment... The section on "S/Mime vs PGP" takes up
> substantial space :-)
> When you have the FAQ available, please announce it in a new thread.
> I do want to see it, but I'm afraid that I'm not interested in
> routinely wading through all the postings in this thread.
Yes, please do so...
David Sternlight
nos...@synernet.com wrote:
Stone's content-free sniping has become so moronic it is time once again to start
ignoring him for a while. Readers may breathe a sigh of relief that if this interminable
nonsense continues, they may lay their complaints at Stone's door.
Stone, of course, uses his Standard Tactic--post such moronic nonsense that one's
correspondent will leave the correspondence, and then declare a victory possibly
pointing to one's web site. How predictable!
David
David Lesher
UnProfessor FUD tunes up:
>Stone's content-free sniping has become so moronic it is time once again to sta
>ignoring him for a while. Readers may breathe a sigh of relief that if this int
Yep, It's PlonkTime Yet Again, In UseNetville...
>Stone, of course, uses his Standard Tactic--post such moronic nonsense that one
>correspondent will leave the correspondence, and then declare a victory possibl
>pointing to one's web site. How predictable!
It's a real ROTFLMAO to hear FUD, once accused of being an Eliza
implimentation, call someone else predictable...
It *will* be interesting to see HIS web site; the unbiased,
technically superiour one we've awaited so long....
[I think there's a Snicker's commercial here...]
(n.b. for international readers: Snickers is a candy bar with a
series of commercials involving long waits. One is two fans with
seats on the 50 yard line of the Cleveland Browns -- you see, they
left town and the new team will not exist for another year or 2,
etc....)
Ed Stone
says...
>
>
> nos...@synernet.com wrote:
>
> Stone's content-free sniping......
<snip>
On topic of your reintroduction of the following:
> > Then we moved onto another argument, that the RSAREF 2 license terms might be
> > onerous. I showed that RSAREF (1.x) was still viable, licensable and had no such
> > onerous license terms.
That is from your message <3686887F...@sternlight.com> of this same
subject title, of 12/27/98.
... What is your response to the licence terms of Jan 5, 1993 for RSAREF
"1.0" that I provided? Those terms were provided in my followup as:
> RSAREF "1.0" license of Jan 5, 1993:
> "LICENSE. RSA grants you a non-exclusive, non-transferable,
> perpetual (subject to the conditions of section 8) license
> for the "RSAREF" program (the "Program") and its associated
> documentation, subject to all of the following terms and
> conditions: ... to modify the Program in any manner for porting or
> performance improvement purposes (subject to Section 2)
> or to incorporate the Program into other computer programs
> for your own personal or internal use, provided that you
> provide RSA with a copy of any such modification or
> Application Program by electronic mail, and grant RSA
> a perpetual, royalty-free license to use and distribute
> such modifications and Application Programs on the terms
> set forth in this Agreement."
>
> But what do they mean, "Application Program"?
> " "Application Programs" are programs which incorporate all or any
> portion of the Program in any form. The restrictions imposed on
> Application Programs in this Agreement shall not apply to any software
> which, through the mere aggregation on distribution media, is
> co-located or stored with the Program."
> See http://bs.mit.edu/pgp/rsalicen.html
>
> You advise this to Networks Associates as a professional economic and
> marketing strategy consultant?
So it is still your view that granting RSADSI a "perpetual, royalty-free
license to use and distribute" PGP 6.0.2 with RSAREF makes good business
sense??? You consider that term "not onerous", and you'd actually stand
behind such a recommendation for licensing?
ssim...@hertreg.ac.uk
da...@sternlight.com wrote:
>
>
> ssim...@hertreg.ac.uk wrote:
>
> > > > >
> > > > > What is a message digest?
> > > > > A message digest is a shortened, or compressed version of the text of
a
> > > > message. Its algorithm is also known as a hash function.
> > > > >
> > > >
> > > > Incorrect terminology ? refer to Handbook of Applied Cryptography.
> > > >
> > > > Actually Dr Sternlight, I have twice before corrected you (do I need to
> > cite?)
> > > > on references to Hash Functions ? maybe you should desist from
commenting on
> > > > hash functions in the future.
> > >
> > > Derived from the RSA FAQ written by a far more professional and
experienced
> > > cryptographer than you or I.
> >
> > I think "derived" is the key word in that sentance. In the process of
> > "deriving" you have missused terminology.
>
> You are still trying to rehash a losing argument, which is based on trying to
make
> the dictionary argument some have criticized. My use of "checksum", "hash
function"
> and "message digest" was itself taken from RSA material.
That’s strange. A cursory glance through v3 and v4 of the RSA FAQ has proven
fruitless in my search for a statement of the equivalence of “checksum” and
“hash function”.
HAC specifically states that checksums are not a cryptographic mechanism.
But you know better than THE most respected cryptographic literature, don’t
you David? Personally I doubt it.
> If you disagree with
> that, fine, but don't throw some other reference (Handbook of Applied
Cryptography)
> at the words of the world's most eminent cryptographers outside the NSA
because you
> want to try to make debating points with me.
I’m not trying to “make debating points” with you – I am just trying to get
you to use correct, standard and accepted terminology. Is that too much to
ask? If, in order to do this, you need to purchase further material, then I
apologise. I do not, however, apologise for asking you to be rigorous when
discussing this science.
After all, you are the person that frequently resorts to a “Miriam Webster” or
some such dictionary, and also commonly makes the statement “What part of x do
you fail to understand?”.
I shall pose a question in the same manner to you; ‘What part of “the
academic, landmark, widely respected literature disagrees with you” do you
not understand?’.
> I thought you were the one claiming
> that one should kiss the hem of the robe of "eminent cryptographers" such as
> Dobbertin, even when their statements seemed wrong.
Where did I make a claim about “kissing hem”? A Dejanews search of this
phrase hasn’t turned up any such references.
> Which is it? Eminent cryptographers should have their word accepted
regardless, or
> eminent cryptographers should have their word accepted only when they agree
with
> Simpson? As for me, I read the words, not the eminence, and think for myself.
>
I bow to greater educated opinion unless I have reason to believe otherwise.
You seem to start from the premise that you are correct and that all other
opinions are wrong.
Once again this is a total fallacy. How would removing MD5 from the digital
signature section of PGP (e.g. the application to which the reference was
made) stop users from reading archived traffic? One can, of course, read
traffic without verifying a signature.
Please explain how “one could no longer read archived traffic” if the hash
function in this context were removed?
Is this your sole reason for calling the eminent Dobbertin “flat wrong”?
> > <SNIP>
> > > > Still, you will have to wait for the full FAQ. Frankly, this FAQ isn’t
> > > > designed to appease you, instead it is meant as an informative and
> > > > authoritative document on the cryptographic security of PGP. You are
> > entitled
> > > > to comment on the FAQ, as is every other member of this forum.
> > >
> > > I am simply trying to be helpful in urging you to see beyond your
prejudices
> > and
> > > partisan views.
> >
> > I have no prejudice. To the contrary, I am just quoting the most respected
> > cryptographers. It would appear that _you_ have an unnatural fascination
with
> > "broken" technology (MD5).
>
> You ARE sounding like a loon. What is this "unnatural fascination" stuff?
When we
> discuss MD5 (which in fact Stone first criticized here), if I respond and
then we
> go through the comment-response-comment-response cycle it is "unnatural
> fascination"? What about those who comment on my comments (which were
themselves
> comments on others' comments about MD5)? Are they also suffering this
"unnatural
> fascination"? Are you, since you seem to engage in the same discussion?
No, but then again I’m not trying to defend an algorithm that has been
deprecated by, dare I say it, eminent cryptographers.
> Let's remind ourselves of the presenting argument, made by Stone (as I
recall). It
> was that PGP was justified in removing RSA from free PGP because MD5 might be
found
> to be weak at a later date, so argued because (although there were as yet no
> complete hash function collisions, which would be a real threat) there were
> compression function collisions.
One should also be reminded that the design goal of MD5 was to build a CRHF
from a collision resistant compression function; this design goal has now been
violated.
In the words of RSA Labs: “With regards to existing applications which use MD2
and MD5, collisions for these hash functions have not yet been discovered but
this advance should be expected... RSA Laboratories currently recommends that
in general, the hash function SHA-1 be used instead but RIPEMD-160 would also
be a good alternative.”
And in the words of HAC: “An iterated hash function is thus in this regard at
most as strong as its compression function”.
Schneier says “I am wary of using MD5”.
> Thus this was basically an argument about whether
> dropping RSA was justified. As was shown, SHA-1 and DSA could be (and were)
> included in later revisions (as RSADSI suggested) of Netscape and Microsoft's
> packages and RSADSI's PKCS #11 without the need to drop RSA. PGP could have
done
> the same. Therefore the argument that the justification for dropping RSA from
PGP
> was MD5 is refuted, and we must look elsewhere. (I say, to PGP's vendetta
against
> RSA because RSA blew the legal whistle on their license violations cum
> infringements.)
Continuing from the above paragraph, one notes that S/Mime v3 does not include
RSA as a “MUST” algorithm, in the same way that the OpenPGP standard doesn’t.
> Then we move on to another argument--that they dropped it from free PGP
because the
> RSA license cost money. I showed this also to be false since RSAREF, the RSA
> package which could be used with free versions of crypto packages, was free.
>
> Then we moved onto another argument, that the RSAREF 2 license terms might be
> onerous. I showed that RSAREF (1.x) was still viable, licensable and had no
such
> onerous license terms.
>
I of course entirely agree with your point that RSAREF (1) could still be used
in PGP (you will note that I wasn’t taking part in that discussion, but I also
note that RSAREF is legacy code, which is slower than the alternatives.
<SNIP>
> > > I have offered some draft material and you have taken that as yet
> > > another occasion to be rancorous.
> >
> > I (and eminent cryptographers) disagree with your humble opinion.
>
> I think there is no doubt you were rancorous. Read your own words. You may
disagree
> with my draft, but there's no need for rancor since it was factually based and
> itself non-polemical.
>
Your draft entry to the FAQ does not reflect the opinion of the cryptographic
community at large, thus has been rejected. I think you will see that the FAQ
has been fair and even handed in all respects (including its handling of MD5,
RSA, S/Mime).
Just as importantly, the FAQ has been very carefully phrased in order to
prevent confusing the reader.
> > > It does not augur well for the work you are
> > > doing. I do not want you to appease me, but to present an accurate and
> > unbiased
> > > version of the facts and issues.
> >
> > No doubt you will be pleased by the new FAQ then.
>
> I suspend further judgment until it is revealed. I have pointed out some
possible
> pitfalls based on your posts here to date, and I devoutly hope you don't fall
into
> them.
>
> David
As previously stated, my FAQ will try to remain objective.
Sam
ssim...@hertreg.ac.uk
da...@sternlight.com wrote:
How would the removal of MD5 from the implementation of digital signatures
imply that a user couldn’t read archived traffic?
<SNIP>
> You are fond of appeal to authority instead of explanation. That is an
ignorant
> and inappropriate way to write a FAQ.
>
Lets see if this group at large thinks that the FAQ is inappropriate.
> > I am sure most on this group will recognise that I am fairly clear and
> > unbiased in respect of crypto - if my FAQ somehow appears to some as "appeal
> > to authority" then maybe they would prefer if I were more subjective?
>
> No. More factual. Don't say "X is good because Y says so." Explain why X is
good.
> That's what a FAQ is supposed to do.
My FAQ will certainly be factual and explanative.
> > Anyway, I guess the FAQ will be complete within a week... Its running at 20
> > pages at the moment... The section on "S/Mime vs PGP" takes up substantial
> > space :-)
>
> I am eager to see your explanation of the differing trust models (which is
the key
> difference in the most common implementations), the place where each trust
model
> is suitable, and the trust institutions and infrastructure behind each. I am
> withholding judgment until I see the results of your effort.
I dispute that the key difference between S/Mime & PGP lies in the
implementation of trust models. One notes (largely from U.Maurer, ”Modelling
a Public-Key Infrastructure", Proceedings 1996 European Symposium on Research
in Computer Security (ESORICS '96), E. Bertino (Ed.), Lecture Notes in
Computer Science, Berlin: Springer-Verlag, Rome, Italy, Sept 1996.) that the
PGP trust model (which is based upon Maurer’s paper) is actually a super-set
of the S/Mime model. Thus PGP can implement the S/Mime “CA-centric” model if
desired. Just add CA / TTP / Big Brother.
Still, as I told you in one of my first replies on this thread, the FAQ
covers the CRYPTOGRAPHIC SECURITY of PGP (and, for one section of the FAQ
S/MIME), not wider issues that don’t directly involve or imply crypto
security. The trust model used by PGP does not reflect upon its
cryptographic security.
Sam.
> David
ssim...@hertreg.ac.uk
amended accordingly.
Regards,
Sam
In article <MPG.10f164b5f...@news.vnet.net>,
nos...@synernet.com (Ed Stone) wrote:
> In article <3686C6AA...@sternlight.com>, da...@sternlight.com
> says...
> >
> >
> > nos...@synernet.com wrote:
> >
> > Stone's content-free sniping......
> <snip>
>
> On topic of your reintroduction of the following:
> > > Then we moved onto another argument, that the RSAREF 2 license terms
might be
> > > onerous. I showed that RSAREF (1.x) was still viable, licensable and had
no such
> > > onerous license terms.
> That is from your message <3686887F...@sternlight.com> of this same
> subject title, of 12/27/98.
>
> ... What is your response to the licence terms of Jan 5, 1993 for RSAREF
> "1.0" that I provided? Those terms were provided in my followup as:
> > RSAREF "1.0" license of Jan 5, 1993:
> > "LICENSE. RSA grants you a non-exclusive, non-transferable,
> > perpetual (subject to the conditions of section 8) license
> > for the "RSAREF" program (the "Program") and its associated
> > documentation, subject to all of the following terms and
> > conditions: ... to modify the Program in any manner for porting or
> > performance improvement purposes (subject to Section 2)
> > or to incorporate the Program into other computer programs
> > for your own personal or internal use, provided that you
> > provide RSA with a copy of any such modification or
> > Application Program by electronic mail, and grant RSA
> > a perpetual, royalty-free license to use and distribute
> > such modifications and Application Programs on the terms
> > set forth in this Agreement."
> >
> > But what do they mean, "Application Program"?
> > " "Application Programs" are programs which incorporate all or any
> > portion of the Program in any form. The restrictions imposed on
> > Application Programs in this Agreement shall not apply to any software
> > which, through the mere aggregation on distribution media, is
> > co-located or stored with the Program."
> > See http://bs.mit.edu/pgp/rsalicen.html
> >
> > You advise this to Networks Associates as a professional economic and
> > marketing strategy consultant?
>
> So it is still your view that granting RSADSI a "perpetual, royalty-free
> license to use and distribute" PGP 6.0.2 with RSAREF makes good business
> sense??? You consider that term "not onerous", and you'd actually stand
> behind such a recommendation for licensing?
> --
> --
> -------------------------------
> Ed Stone
> est...@synernet-robin.com
> remove "-birdname" spam avoider
> Sternlight FAQ at http://www.synernet.com/public/sternlight-faq
> -------------------------------
>
-----------== Posted via Deja News, The Discussion Network ==----------
David Sternlight
ssim...@hertreg.ac.uk wrote:
<omittted>
Simpson has degenerated from posting useful technical information to out-and-out
polemics and personal attack. It is no longer useful to reply to his posts until he
returns to civil discourse.
And he wonders why we need a moderated list, such as internet-crypto.
Readers who join the list may opt to receive immediate e-mail copies of all posts,
digests, or to read the posts on the web.
http://www.eGroups.com/list/internet-crypto
David
David Sternlight
ssim...@hertreg.ac.uk wrote:
> Thanks for pointing this out Ed, I had missed it... I shall ensure the FAQ is
> amended accordingly.
>
> Regards,
>
> Sam
>
> In article <MPG.10f164b5f...@news.vnet.net>,
> nos...@synernet.com (Ed Stone) wrote:
> > In article <3686C6AA...@sternlight.com>, da...@sternlight.com
> > says...
> > >
> > >
> > > nos...@synernet.com wrote:
> > >
> > > Stone's content-free sniping......
> > <snip>
> >
> > On topic of your reintroduction of the following:
> > > > Then we moved onto another argument, that the RSAREF 2 license terms
> might be
> > > > onerous. I showed that RSAREF (1.x) was still viable, licensable and had
> no such
> > > > onerous license terms.
> > That is from your message <3686887F...@sternlight.com> of this same
> > subject title, of 12/27/98.
> >
> > ... What is your response to the licence terms of Jan 5, 1993 for RSAREF
> > "1.0" that I provided? Those terms were provided in my followup as:
> > > RSAREF "1.0" license of Jan 5, 1993:
> > > "LICENSE. RSA grants you a non-exclusive, non-transferable,
> > > perpetual (subject to the conditions of section 8) license
> > > for the "RSAREF" program (the "Program") and its associated
> > > documentation, subject to all of the following terms and
> > > conditions: ... to modify the Program in any manner for porting or
> > > performance improvement purposes (subject to Section 2)
> > > or to incorporate the Program into other computer programs
> > > for your own personal or internal use, provided that you
> > > provide RSA with a copy of any such modification or
> > > Application Program by electronic mail, and grant RSA
> > > a perpetual, royalty-free license to use and distribute
> > > such modifications and Application Programs on the terms
> > > set forth in this Agreement."
> > >
> > > But what do they mean, "Application Program"?
> > > " "Application Programs" are programs which incorporate all or any
> > > portion of the Program in any form. The restrictions imposed on
> > > Application Programs in this Agreement shall not apply to any software
> > > which, through the mere aggregation on distribution media, is
> > > co-located or stored with the Program."
> > > See http://bs.mit.edu/pgp/rsalicen.html
> > >
> > > You advise this to Networks Associates
This discussion is about Free PGP. I see nothing wrong with this. It is not
onerous. Since they're giving Free PGP away, what's wrong with sending a copy for
which they use RSAREF to RSADSI?
>
> >
> > So it is still your view that granting RSADSI a "perpetual, royalty-free
> > license to use and distribute" PGP 6.0.2 with RSAREF makes good business
> > sense???
This discussion is about Free PGP. If giving away Free PGP 6.0.2 weren't in PGP's
business interest they wouldn't do it. Thus giving a copy to RSADSI and letting
them distribute it as well, in exchange for a free RSA license via RSAREF (1.0)
in Free PGP 6.0.2 hardly seems in conflict with PGP's "good business sense". That
is--the "business sense" issue arises with respect to their own widespread
distribution of Free PGP, and not whether RSADSI also gets a copy and can
redistribute it.
You seem not to be following the discussion.
David
D. Lakis
Hash: SHA1
ssim...@hertreg.ac.uk wrote:
In article <3686887F...@sternlight.com>,
da...@sternlight.com wrote:
>
> ssim...@hertreg.ac.uk wrote:
<Snip>
Etc.
<Snip>
I’m not trying to “make debating points” with you – I am just trying
to get
you to use correct, standard and accepted terminology. Is that too
much to
ask? If, in order to do this, you need to purchase further material,
then I
apologise. I do not, however, apologise for asking you to be
rigorous when
discussing this science.
<Snip>
I bow to greater educated opinion unless I have reason to believe
otherwise.
You seem to start from the premise that you are correct and that all
other
opinions are wrong.
Exchange of energy here.
> > Maybe you should learn respect?
<Snip>
Once again this is a total fallacy. How would removing MD5 from the
digital
signature section of PGP (e.g. the application to which the
reference was
made) stop users from reading archived traffic? One can, of course,
read
traffic without verifying a signature.
Please explain how “one could no longer read archived traffic” if
the hash
function in this context were removed?
Is this your sole reason for calling the eminent Dobbertin “flat
wrong”?
> > <SNIP>
<Snip>
> I suspend further judgment until it is revealed. I have pointed
out some
possible
> pitfalls based on your posts here to date, and I devoutly hope you
don't fall...
<Snip>
A book was published a few years ago, by Eric Hoffer I think, entitled
The True Believer. Such a
person cannot hear beyond his or her world view. They are essentially
fundamentalist, only they can
be so about anything...anything at all. There is no discussing with
them; in fact, they, through some
weird mechanism, draw strength from conflict around those things they
believe...this conflict is, in
fact, necessary for them to continue anything, even, it is argued,
life itself; at a minimum, it is
necessary to keep cognitive dissonance at bay...they are almost like a
parasite, only they feed on
conflict, or rather its results, the energy of it...
In the Tao, and in Martial Arts in general, (and many other "folk"
traditions) there is the idea that to
resist is (possibly) fatal for the resistor...the enemy, or
overpowering force, (or whatever may
present the challenge, in the most generic of terms) draws strength
from the resistor's resistance; the
idea is that to become even angry at the enemy is to feed, to nourish,
to strengthen the enemy, or
challenge, or obstacle, or whatever it is one faces. So to actively
resist is to give even more strength
to the difficulty, or whatever on faces...
I know it is off topic.
Hope this helps.
Strictly PGP. Look forward to learning from you all, and maybe
teaching something one day.
Best Regards.
-----BEGIN PGP SIGNATURE-----
Version: 5.5.3a
iQA/AwUBNog+HCdyfjZ4tICtEQJDyACfeyvywtCXnajcTvwal8vY5MjNVZ8AoK9x
f83UIzQf0ZrRoptYgDdIYT1n
=ChDa
-----END PGP SIGNATURE-----
whg...@no.openpgp.net.spam.please
>ssim...@hertreg.ac.uk wrote:
><omittted>
>http://www.eGroups.com/list/internet-crypto
Yes David I am sure you would love to have everyone on a list where any
opposition to the "Truth According to David" can be silenced by some
benevolent "moderator", get's rid of all those messy freedom of speech
issues. God forbid that we have any competition of ideas in a free and
open forum.
I noticed that the list does not allow any anonymous posts. Nice, say
something wrong and have the jack boots drag you off in the middle of the
night (and before you go off on some tangent about how nice the USG is and
that they would never do such a thing remember that the Internet is global
with some very nasty governments).
I am sure you also prefer a nice benevolent dictator to rule your life
thereby getting rid of any nasty inconveniences that may be caused by
freedom and democracy.
If you are really interested in increasing the S/N ratio try posting some
signal instead of your never ending stream of noise.
--
---------------------------------------------------------------
William H. Geiger III http://www.openpgp.net
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 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------
David Sternlight
Simpson leaves off and Lakis begins, so I'll comment without reference to
the particular speaker.
>
> I’m not trying to “make debating points” with you ? I am just trying
> to get
> you to use correct, standard and accepted terminology.
The terminology I used was used in a respected crypto web site. What you
want me to use is your terminology. And you go further. You use the
occasion of my using informal terminology to try to discredit the
underlying position, in fact picking nits about the terminology to avoid
confronting substance. That is not a contribution to this discussion, but
to ego gratification.
> Is that too
> much to
> ask? If, in order to do this, you need to purchase further material,
> then I
> apologise. I do not, however, apologise for asking you to be
> rigorous when
> discussing this science.
This is a usenet discussion group and not a Ph.D. oral. The lack of
perspective suggests the "true believer" syndrome Hoffer described (see
below).
>
>
> <Snip>
>
> I bow to greater educated opinion unless I have reason to believe
> otherwise.
> You seem to start from the premise that you are correct and that all
> other
> opinions are wrong.
Here you concatenate two logically separate points. The first is an
appeal to authority. I have covered that with my comment that it's not
helpful to say "X is good because Y says so" in a FAQ, but rather "X is
useful for the following reasons". If you quote Y it had better be with
a substantive discussion and not a testimonial.
In the past simpson has quoted testimonials rather than substance, and
where I quote I try to make it substantive. There's a big difference.
The second point is just inaccurate. Opinions are just that. I have mine
and you have yours. Substance is a different matter, and is dealt with
via data and logic. If someone posts a logical fallacy, that is not
dispositive. If another posts a correct syllogism it is. Usually we are
relaxed so the syllogisms are cast in informal terms, but their bones may
be exhumed and subjected to scrutiny nevertheless in order to refine the
discussion and arrive at insight or truth.
> Once again this is a total fallacy. How would removing MD5 from the
> digital
> signature section of PGP (e.g. the application to which the
> reference was
> made) stop users from reading archived traffic? One can, of course,
> read
> traffic without verifying a signature.
> Please explain how “one could no longer read archived traffic” if
> the hash
> function in this context were removed?
> Is this your sole reason for calling the eminent Dobbertin “flat
> wrong”?
As I have explained, by "reading" I meant referring to archived traffic
and checking the authentication. That was clear from the context. It is
part of the reading operation on most mailers and news readers. Taken
"reading" literally, of course MD5 doesn't affect encryption. But without
it you cannot check signatures on past MD5 traffic you're reading.
Therefore it's a bad idea to drop it from software, even if it may be a
good idea to add, say, SHA-1 as RSA has done with PKCS #11 used in
Netscape and (I assume) Microsoft.
>
> A book was published a few years ago, by Eric Hoffer I think, entitled
> The True Believer. Such a
> person cannot hear beyond his or her world view. They are essentially
> fundamentalist, only they can
> be so about anything...anything at all. There is no discussing with
> them; in fact, they, through some
> weird mechanism, draw strength from conflict around those things they
> believe...this conflict is, in
> fact, necessary for them to continue anything, even, it is argued,
> life itself; at a minimum, it is
> necessary to keep cognitive dissonance at bay...they are almost like a
> parasite, only they feed on
> conflict, or rather its results, the energy of it...
Your last sentence does great violence to Hoffer's book, as I remember
it.
I have noticed the general syndrome with some PGP fanatics here. My
position, in contrast, is a balanced one: PGP is good for some things and
not for others; S/MIME similarly. It is worth discussing what those
differentiating application areas are and why.
>
>
> In the Tao, and in Martial Arts in general, (and many other "folk"
> traditions) there is the idea that to
> resist is (possibly) fatal for the resistor...the enemy, or
> overpowering force, (or whatever may
> present the challenge, in the most generic of terms) draws strength
> from the resistor's resistance; the
> idea is that to become even angry at the enemy is to feed, to nourish,
> to strengthen the enemy, or
> challenge, or obstacle, or whatever it is one faces. So to actively
> resist is to give even more strength
> to the difficulty, or whatever on faces...
This is somewhat irrelevant in that some here resort to character
assassination, defamation and personal attack. One cannot accept such
behavior; at best one can ignore it.
David
nos...@synernet.com
says...
<snip>
Re needing MD5 to "read" traffic:
> As I have explained, by "reading" I meant referring to archived traffic
> and checking the authentication. That was clear from the context. It is
> part of the reading operation on most mailers and news readers. Taken
> "reading" literally, of course MD5 doesn't affect encryption. But without
> it you cannot check signatures on past MD5 traffic you're reading.
> Therefore it's a bad idea to drop it from software, even if it may be a
> good idea to add, say, SHA-1 as RSA has done with PKCS #11 used in
> Netscape and (I assume) Microsoft.
<snip>
Again, you defend writing with a lack of precision. Such a lack of
precision, as one finds in casual conversation, is not generally a
problem. But your holding others to a standard of precision (pedanticism)
from which you exempt yourself, is telling. You can likely obtain some
slack from others, as you give it (a paraphrase ;-) )
Sam Simpson
David Sternlight wrote in message <368827B3...@sternlight.com>...
>
>
>ssim...@hertreg.ac.uk wrote:
>
>> Thanks for pointing this out Ed, I had missed it... I shall ensure the
FAQ is
>> amended accordingly.
>>
>> Regards,
>>
>> Sam
>>
>> In article <MPG.10f164b5f...@news.vnet.net>,
>> nos...@synernet.com (Ed Stone) wrote:
>> > In article <3686C6AA...@sternlight.com>, da...@sternlight.com
>> > says...
>> > >
>> > >
>> > > nos...@synernet.com wrote:
>> > >
>> > > Stone's content-free sniping......
>> > <snip>
>> >
>> > On topic of your reintroduction of the following:
terms
>> might be
>> > > > onerous. I showed that RSAREF (1.x) was still viable, licensable
and had
>> no such
>> > > > onerous license terms.
same
>> > subject title, of 12/27/98.
>> >
>> > ... What is your response to the licence terms of Jan 5, 1993 for
RSAREF
>> > "1.0" that I provided? Those terms were provided in my followup as:
>> > > "LICENSE. RSA grants you a non-exclusive, non-transferable,
>> > > perpetual (subject to the conditions of section 8) license
>> > > for the "RSAREF" program (the "Program") and its associated
>> > > documentation, subject to all of the following terms and
>> > > conditions: ... to modify the Program in any manner for porting or
>> > > performance improvement purposes (subject to Section 2)
>> > > or to incorporate the Program into other computer programs
>> > > for your own personal or internal use, provided that you
>> > > provide RSA with a copy of any such modification or
>> > > Application Program by electronic mail, and grant RSA
>> > > a perpetual, royalty-free license to use and distribute
>> > > such modifications and Application Programs on the terms
>> > > set forth in this Agreement."
>> > >
>> > > But what do they mean, "Application Program"?
>> > > " "Application Programs" are programs which incorporate all or any
>> > > portion of the Program in any form. The restrictions imposed on
>> > > Application Programs in this Agreement shall not apply to any
software
>> > > which, through the mere aggregation on distribution media, is
>> > > co-located or stored with the Program."
>> > > See http://bs.mit.edu/pgp/rsalicen.html
>> > >
>> > > You advise this to Networks Associates
>
>onerous. Since they're giving Free PGP away, what's wrong with sending a
copy for
>which they use RSAREF to RSADSI?
So, PGP should allow RSA "a perpetual, royalty-free license to use and
distribute..." PGP?
So PGP should give away its intellectual property to another business?
Without remuneration?
>> > So it is still your view that granting RSADSI a "perpetual,
royalty-free
>> > license to use and distribute" PGP 6.0.2 with RSAREF makes good
business
>> > sense???
>
>This discussion is about Free PGP. If giving away Free PGP 6.0.2 weren't in
PGP's
>business interest they wouldn't do it. Thus giving a copy to RSADSI and
letting
>them distribute it as well, in exchange for a free RSA license via RSAREF
(1.0)
AND USE.
>
>in Free PGP 6.0.2 hardly seems in conflict with PGP's "good business
sense". That
>is--the "business sense" issue arises with respect to their own widespread
>distribution of Free PGP, and not whether RSADSI also gets a copy and can
>redistribute it.
>
>You seem not to be following the discussion.
>
To the contrary.
You therefore suggest that PGP/NAI allows another business to use
intellectual property for free, without a license?
Surely not...
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.
>David
>
>
David Sternlight
Sam Simpson wrote:
>
> You therefore suggest that PGP/NAI allows another business to use
> intellectual property for free, without a license?
>
> Surely not...
Time to stop the trolling, simpson. The free product is given away to all legal comers. Giving it in exchange for value (RSAREF and a license to RSA for that selfsame product) is thus hardly inappropriate. And giving a perpetual license to the free product in exchange for a perpetual license to RSAREF for the free product is also not unreasonable.
They are always free to buy a license to RSA for the pay versions, which they then don't have to give to RSADSI. And that's exactly what they've done.
Since you know all of the above, the only conclusion one can come to from this and most of your other recent posts is that you are trying to be deliberately disruptive to this newsgroup. Time to knock it off.
David
Ed Stone
says...
>
>
> Sam Simpson wrote:
>
> >
> > You therefore suggest that PGP/NAI allows another business to use
> > intellectual property for free, without a license?
> >
> > Surely not...
>
> Time to stop the trolling, simpson. The free product is given away to all legal comers. Giving it in exchange for value (RSAREF and a license to RSA for that selfsame product) is thus hardly inappropriate. And giving a perpetual license to the free product in exchange for a perpetual license to RSAREF for the free product is also not unreasonable.
>
Associates give a perpetual free license to RSADSI to directly
redistribute 6.0.2 with RSAREF. A marketing and economic strategy
consultant!!!
That would be a Bad Idea from a legal, marketing, and economic
standpoint.
> They are always free to buy a license to RSA for the pay versions, which they then don't have to give to RSADSI. And that's exactly what they've done.
Possibly they see the same obvious reason that you are missing...
>
> Since you know all of the above, the only conclusion one can come to from this and most of your other recent posts is that you are trying to be deliberately disruptive to this newsgroup. Time to knock it off.
I'm surprised you even have time to post here with the task of moderating
all of the posts on your new Sternlight-moderated egroup weighing on you.
David Sternlight
Ed Stone wrote:
> In article <36892339...@sternlight.com>, da...@sternlight.com
> says...
> >
> >
> > Sam Simpson wrote:
> >
> > >
> > > You therefore suggest that PGP/NAI allows another business to use
> > > intellectual property for free, without a license?
> > >
> > > Surely not...
> >
> > Time to stop the trolling, simpson. The free product is given away to all legal comers. Giving it in exchange for value (RSAREF and a license to RSA for that selfsame product) is thus hardly inappropriate. And giving a perpetual license to the free product in exchange for a perpetual license to RSAREF for the free product is also not unreasonable.
> >
> Well we have heard Mr. Sternlight's recommendation that Networks
> Associates give a perpetual free license to RSADSI to directly
> redistribute 6.0.2 with RSAREF.
You misrepresent what I said. I said "Free PGP 6.0.2.".
>
>
> That would be a Bad Idea from a legal, marketing, and economic
> standpoint.
To the contrary, it is a commonly used technique in business, called an exchange of licenses. PGP gets a non-exclusive RSA license and the software for RSAREF, for use in Free PGP; RSA gets a non-exclusive license and the software for Free PGP. It often makes good legal sense. It is good marketing sense since RSADSI's credibility, reputation, and market power are added to that of PGP with respect to Free PGP. It is good economics since if Free PGP is to be given away, a free license to RSA keeps the costs down. I simply cannot fathom what you are going on about.
>
>
> > They are always free to buy a license to RSA for the pay versions, which they then don't have to give to RSADSI. And that's exactly what they've done.
>
> Possibly they see the same obvious reason that you are missing...
Hand waving.
>
> >
> > Since you know all of the above, the only conclusion one can come to from this and most of your other recent posts is that you are trying to be deliberately disruptive to this newsgroup. Time to knock it off.
>
> I'm surprised you even have time to post here with the task of moderating
> all of the posts on your new Sternlight-moderated egroup weighing on you.
Gee, thanks for the plug. Readers who are interested may learn more at
http://www.eGroups.com/list/internet-crypto
David
Ed Stone
says...
>
>
> Ed Stone wrote:
>
> > In article <36892339...@sternlight.com>, da...@sternlight.com
> > says...
> > >
> > >
> > > Sam Simpson wrote:
> > >
> > > >
> > > > You therefore suggest that PGP/NAI allows another business to use
> > > > intellectual property for free, without a license?
> > > >
> > > > Surely not...
> > >
> > > Time to stop the trolling, simpson. The free product is given away to all legal comers. Giving it in exchange for value (RSAREF and a license to RSA for that selfsame product) is thus hardly inappropriate. And giving a perpetual license to the free product in exchange for a perpetual license to RSAREF for the free product is also not unreasonable.
> > >
> > Well we have heard Mr. Sternlight's recommendation that Networks
> > Associates give a perpetual free license to RSADSI to directly
> > redistribute 6.0.2 with RSAREF.
>
> You misrepresent what I said. I said "Free PGP 6.0.2.".
See above. Wouldn't "6.0.2 with RSAREF", by definition, be a free
product? ;-)
>
> >
> >
> > That would be a Bad Idea from a legal, marketing, and economic
> > standpoint.
>
> To the contrary, it is a commonly used technique in business, called an exchange of licenses. PGP gets a non-exclusive RSA license and the software for RSAREF, for use in Free PGP; RSA gets a non-exclusive license and the software for Free PGP. It often makes good legal sense. It is good marketing sense since RSADSI's credibility, reputation, and market power are added to that of PGP with respect to Free PGP. It is good economics since if Free PGP is to be given away,
a free license to RSA keeps the costs down. I simply cannot fathom what you are going on about.
That you can't fathom it discloses your view on crypto marketing and
branding issues. Suffice it to say that those with money on the table
(NAI) don't choose to hand the rights to redistribute 6.0.2 with RSAREF
to RSADSI. If you wish to cast that as some tendency on their part to
prefer fighting (inheriting some 'evil' from PGP's founders?) to making
money, then your economics views are of publicly-held firms are,
interesting.
>
> >
> >
> > > They are always free to buy a license to RSA for the pay versions, which they then don't have to give to RSADSI. And that's exactly what they've done.
> >
> > Possibly they see the same obvious reason that you are missing...
>
> Hand waving.
see http://www.synernet.com/public/sternlight-faq/handwaving.html
>
> >
> > >
> > > Since you know all of the above, the only conclusion one can come to from this and most of your other recent posts is that you are trying to be deliberately disruptive to this newsgroup. Time to knock it off.
> >
> > I'm surprised you even have time to post here with the task of moderating
> > all of the posts on your new Sternlight-moderated egroup weighing on you.
>
> Gee, thanks for the plug. Readers who are interested may learn more at
> http://www.eGroups.com/list/internet-crypto
So you are bearing up under the burden of moderating *all* of those
posts? ;-)
Bringhell
Hash: SHA1
Could you explain what "collisions" are in hash algorithms?
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBNpC4zQvGm3EfNItNEQJ23QCeJUSLcAwJx8MgawmK1jtj7DqDwlsAoPfW
eFdf38ATOaTQAZEf6brYl4Fw
=dwnY
-----END PGP SIGNATURE-----
Sam Simpson
From the (still not proof read!) FAQ:
1. Hash Function Algorithms in PGP
1.1. What is a Hash Function?
A cryptographic hash function takes an arbitrary length message as input and
produces a fixed length output. The input is typically a file or a message.
The output of the hash function is called a Message Digest, hash value or
message fingerprint
By their very nature, hash functions are many to one - that is to say there
will certainly be more than one input message that produces a given hash
value. The purpose of the hash function is to make the job of finding such
"collisions" computationally infeasible.
Being able to produce collisions for a hash function in reasonable time
renders a hash function ineffectual.
Most modern hash functions are built from a compression function, which is
iterated on the input stream. Like a complete hash function, a compression
function can suffer from collisions. The precise design of the hash
function dictates how detrimental compression function collisions are to the
security of the overall hash function - but a collision free compression
function is necessary for an overall secure iterated hash function [MOV96].
1.2. What is a "checksum"?
A checksum or CRC function etc is a non-cryptographic mechanism for
detecting transmission errors [MOV96], [RSA98].
PGP uses a checksum value to:
a) Produce non-cryptographically secure pseudo-random numbers. A
strong PRNG exists for the production on numbers that need to be
cryptographically secure.
b) Checking whether a message has been corrupted during transit. Note
that this is in addition to any cryptographically secure method of error
detection.
Note that the checksum function is only used in areas that don't require
cryptographic strength. When cryptographic strength is required, PGP uses a
hash function.
1.3. What function does a hash algorithm perform in PGP?
The hash function is responsible for two primary tasks in PGP:
a) Creation of Digital Signatures. The message is passed through the
hash function and the resulting hash value is signed with the users private
key.
b) Obfuscation of the passphrase. Passphrases are passed through the
hash algorithm to produce a "fingerprint" which is then used by the
symmetric cipher to decrypt the private keyring.
It is therefore important that the hash function has the following two
characteristics:
a) The function is One Way - that is to say it should be "hard" to find
a message that hashes to a pre-specified value.
b) The function is Collision Resistance - that is to say it should be
"hard" to find two messages that hash to the same value.
1.4. What is MD5?
MD5 is a hash function by Ron Rivest [RFC1321]. It is an enhanced version
of the MD4 hash function (MD4 has been totally broken [RSA98]).
MD5 has been included in PGP since conception, but has recently been
deprecated due to several security concerns (see section 3.7). MD5 seems to
have been a catalyst for the changes that we have seen post PGP v2.x.
MD5 is supported in S/Mime (v3) only for [IETF98]: "providing backward
compatibility".
1.5. What is SHA-1?
SHA-1 is the current hash function of choice as implemented in both the PGP
and S/Mime standards. SHA-1 is formally defined in [FIPS180-1], [ANSI930-2]
& [ISOIEC10118-3].
SHA-1 is based upon the MD4 algorithm, but was enhanced by NIST / NSA. The
output of SHA-1 is 160-bits.
SHA-1 has been extensively analysed but to date there have been no
successful attacks.
1.6. What is RIPE-MD?
RIPE-MD is another hash function derived from MD4. It is formally defined
in [DBP96].
To date there have been no successful cryptanalysis of RIPE-MD. PGP
implements RIPE-MD160, which produces an output of 160-bits.
1.7. Has MD5 been broken?
Not totally. First, pseudo-collisions in the compression function were
found by den Boer and Bosselaers [BB94] then collisions in the compression
function were found by Dobbertin [Dob96].
This doesn't mean that collisions have been found in the full hash function,
but it does mean that MD5 shouldn't be used in situations where collision
resistance is required [Dob96], for example in the creation of digital
signatures (the main application of a hash function in PGP). To quote Hans
Dobbertin directly [Dob96]: "Therefore we suggest that in the future MD5
should no longer be implemented in applications like signature schemes,
where a collision-resistant hash function is required. According to our
present knowledge, the best recommendations for alternatives to MD5 are
SHA-1 and RIPEMD-160."
One should be reminded that the design goal of MD5 was to build a CRHF from
a collision resistant compression function [Sch96a], [MOV96], this design
goal has now been violated.
In the words of RSA Labs [RSA96b]: "With regards to existing applications
which use MD2 and MD5, collisions for these hash functions have not yet been
discovered but this advance should be expected... RSA Laboratories currently
recommends that in general, the hash function SHA-1 be used instead but
RIPEMD-160 would also be a good alternative."
And in the words of [MOV96]: "An iterated hash function is thus in this
regard at most as strong as its compression function".
A further complaint about MD5 is the 128-bit output. This is insufficient
for long term security [PBD97] & [Sch96a]. Schneier says [Sch96a] "I am
wary of using MD5".
One also notes that MD5 is supported in S/Mime (v3) only for [IETF98]:
"providing backward compatibility". It would seem foolish to continue to
use technology that is so dubious when far superior unencumbered algorithms
are available.
So, to summarise, there are three main concerns about the use of MD5:
a) Pseudo-collisions have been found in the compression function.
b) Collisions have been found in the compression function. This
violates the design of MD5.
c) The hash function only returns 128-bits, which is insufficient for
long term security.
Regards,
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.
Bringhell wrote in message <36919...@news2.chevalier.net>...
David Sternlight
compression function need to be explained. There is at least one typo (which
will pass a spelling checker) that should be corrected). "The function is
Collision Resistance " should either be "has" or "Resistant".
David