Xref: sparky sci.crypt:6542 alt.security.pgp:467
Newsgroups: sci.crypt,alt.security.pgp
Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!
usc!sol.ctr.columbia.edu!destroyer!ncar!sage.cgd.ucar.edu!prz
From: p...@sage.cgd.ucar.edu (Philip Zimmermann)
Subject: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan8.173701.8858@ncar.ucar.edu>
Sender: ne...@ncar.ucar.edu (USENET Maintenance)
Organization: Climate and Global Dynamics Division/NCAR, Boulder, CO
Date: Fri, 8 Jan 1993 17:37:01 GMT
Lines: 183
This note is in response to criticisms of PGP by Dr. Sidelnikov of
the Moscow State University in Russia, posted on sci.crypt and
alt.security.pgp.
My responses are interspersed with the remarks of Dr. Sidelnikov.
> About using the electronic signature for protection of
> commercial information:
> The analysis of PGP ver.2.0 program.
> THE MATHEMATICAL CRYPTOGRAPHY PROBLEMS LABORATORY
>
> The MSU mathematical cryptography problems laboratory
>employeers with some addition specialists were executed the
>preliminary analysis of PGP ver.2.0 program.
>
> The preliminary study of working and program source code
>analysis result in following PGP features and problems:
>
> 1. The common character problems
>
> - the sequence of random numbers has strong prevalences on
>bytes (up to 0.05 ... 0.1 on material of 10000 byte) and strong
>correlation dependence between contiguous bytes;
Really? How so? What does "strong prevalences" mean? Is he talking
about the internal random number source in random.c, used for making
RSA keys? Or is he talking about the output of the IDEA cipher? In
either case, evidence should be presented that allows others to
reproduce his results. The random.c code for getting randomness from
keyboard latency has been tested pretty well, and it uses MD5 to
enhance the raw randomness from the keyboard timings. It looks
pretty good to me. Does the IDEA cipher running in CFB mode output
text that appears nonrandom? This is disturbing, if true. Biham and
Shamir have thus far not succeeded in finding weaknesses in the IDEA
cipher. Perhaps Dr. Sidelnikov has found one. I'd like to see some
evidence of this claim.
> - the program doesn't check it's own integrity, so it can be
>infected by "virus" which intercept confidential keys and
>passwords used for their protection and save them onto magnetic
>carriers;
The PGP manual warns of this problem. A well-designed virus could
defeat any self-checking logic by attacking the self-checking logic.
It would create a false sense of security if PGP claimed to check
itself for viruses when you run it.
> - the program has not optimal exponentiation algorithm in
>GF(P) field, when P - prime number, which result in low
>performance;
PGP is freeware. Maybe the exponentiation is not as optimal as it
could be if the PGP development effort were funded. In any case,
improvements in the math algorithms have made PGP 2.0 faster than
version 1.0, and version 2.1 is faster still. Of course, suggestions
for improving the performance of the algorithms are always welcome.
> 2. The RSA algorithm realization problems
>
> - the prime numbers reception using in this program (R and q
>in RSA algorithm) permits not less than on two order to reduce
>the labour-intensiveness of factorization; with 256 bit blocks
>of data lenght it is possible to execute the cryptanalysis in
>real time;
I don't know what this means. PGP does not normally work with RSA
keys as small as 256 bits. No claims are made that this is a safe
key length. Larger RSA keys are specifically recommended in the
manual. And what does "real time" mean in this case?
> - before using RSA the program executes compression and block
>encryption that positively affects on the common stability
>encryption.
What does this mean, in English? It sounds like a positive remark,
not a criticism. Is a better English translation available?
> 3. The electronic signature problems
>
> - for signature calculation the program originally executes
>hashing of file into number of given length (256, 512 or 1024 bit),
>but hashing function does not corresponds the ISO recommendations;
The MD5 hash used in PGP is widely respected in the crypto community.
Not conforming to some particular ISO specification does not imply the
hash function is weak. The MD5 hash is used in certain other crypto
standards-- so why should the ISO standard be somehow better than other
crypto standards?
> - when considering the hashing function as the automatic device
>without output, it is enough simply possible to construct the
>image of reverse automatic device and with using the blanks in
>text files (or free fields in some standard formats as in DBF),
>to compensate the hashing function at changed file to former
>significance.
> Thus, it is possible to forge the electronic signature
>without analysis of RSA algorithm.
How? This claim sounds alarming, if true. But it requires that one
of the following be true:
a) The RSA algorithm itself has a weakness.
b) The MD5 hash algorithm has a weakness.
c) PGP has a programming bug in implementing either RSA or MD5.
I doubt that RSA or MD5 have weaknesses that have surfaced here.
If PGP has a bug in implementing RSA or MD5, I'd like to see a better
description of the problem, to help find the bug. Is it possible
to get a more coherent English translation of these remarks? What is
the evidence of these assertions, so that the results may be reproduced?
> 4. The block encryption algorithm problems
>
> - when executing analysis on plaintext and ciphertext the
>linear correlation dependences with encryption key were founded
>(0.01 and more degree);
>
> - also the effective method of decreasing security which
>reduces the order of time necessery to key definition in two
>times in comparison with exhaustive search of all keys (i.e.
>algorithm has the labour-intensiveness which is equal the root
>square from labour-intensiveness of the exhaustive search algorithm)
>have been found.
Again, a better English translation is required to decipher this
claim. Also, where is the evidence? This sounds like he's saying
the IDEA cipher is weak. Or maybe PGP has a bug in implementing it.
If so, it should be fixed. But more information is needed to help
reproduce the problem, if indeed there is a problem.
>
> The conclusions:
>
> It is recommended to use encryption with 1024 bit key length.
>
> The using of electronic signature is not recommended and
> requires the additional study.
>
> The block encryption algorithm has temporary stability.
What does "temporary stability" mean?
>
> The hashing function should be reduce in conformity with ISO
> recommendations.
>
> The using of PGP program in actual version is undesired.
>
>
> The MSU mathematical cryptography
> problems Laboratory Manager
> Academician
>
> Dr. Sidelnikov V.M.
In conclusion, I'd like to point out that normally, when an academic
paper is published that claims a cryptosystem is weak, it generally
includes some real data to back up its claims. Such data is
conspicuously absent here.
There have been some programming bugs in PGP. Some of these bugs are
found by the user community. When they have been found, they have
been fixed. PGP 2.1 has numerous bug fixes over version 2.0. There
are also some known bugs in 2.1, as were recently discovered by Juha
Sarlin. But I am not aware of any extant bugs or bugs that were in
2.0 that could cause the symptoms described above, at least for the
passages I can understand. I would certainly welcome some
clarification of these claims to help discover if there are any real
weaknesses in PGP.
Philip Zimmermann
Xref: sparky sci.crypt:6546 alt.security.pgp:469
Newsgroups: sci.crypt,alt.security.pgp
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!
uwm.edu!linac!att!news.cs.indiana.edu!umn.edu!csus.edu!netcom.com!strnlght
From: strn...@netcom.com (David Sternlight)
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan8.193153.4336@netcom.com>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <1993Jan8.173701.8858@ncar.ucar.edu>
Date: Fri, 8 Jan 1993 19:31:53 GMT
Lines: 225
My purpose in posting this is not to enter into the dispute between
Zimmermann and Sidelnikov, but to comment on some interesting questions that
the Sidelnikov post may raise. Some preface may be in order:
In my many individual visits to the Soviet Union at the personal
invitation of the Soviet Academy of Sciences, and in my discussions
with Soviet scientific leaders, it became clear to me that in the
Soviet structure, the academic and Academy scientific structure was
intimately bound up with the military and intelligence structure.
Through the mechanism of the State Committee on Science and Technology
the Soviets ran their Nuclear, Missile, and many other programs.
Leaders in the State Committee were also leaders in the Soviet Academy
of Sciences and in the academic community.
This raises the question of whether Sidelnikov had some senior role,
directly or indirectly, in the Soviet's equivalent of the NSA. If he
did, then his comments may be both authoritative with respect to
access to what once was highly classified technology in the USSR,
and (by the argument of parallelism) revelatory of the state of
technology at the NSA.
In article <1993Jan8.1...@ncar.ucar.edu>
p...@sage.cgd.ucar.edu (Philip Zimmermann) writes:
>
>This note is in response to criticisms of PGP by Dr. Sidelnikov of
>the Moscow State University in Russia, posted on sci.crypt and
>alt.security.pgp.
>
>My responses are interspersed with the remarks of Dr. Sidelnikov.
>
>
>> About using the electronic signature for protection of
>> commercial information:
>
>> The analysis of PGP ver.2.0 program.
>
>
>> THE MATHEMATICAL CRYPTOGRAPHY PROBLEMS LABORATORY
>>
>> The MSU mathematical cryptography problems laboratory
>>employeers with some addition specialists were executed the
>>preliminary analysis of PGP ver.2.0 program.
Is this lab a former part of the Soviet NSA? If so, one may assume
a very high level of expertise, which gives major weight to what
Sidelnikov says. We know that many intelligence specialists in
Russia are now under- or unemployed and looking for work in
the Western community. Thus it would not be surprising for Sidelnikov
to "go public" as it were.
>>
>> The preliminary study of working and program source code
>>analysis result in following PGP features and problems:
>>
>> 1. The common character problems
>>
>> - the sequence of random numbers has strong prevalences on
>>bytes (up to 0.05 ... 0.1 on material of 10000 byte) and strong
>>correlation dependence between contiguous bytes;
>
>Biham and
>Shamir have thus far not succeeded in finding weaknesses in the IDEA
>cipher. Perhaps Dr. Sidelnikov has found one.>evidence of this claim.
>
>> - the program doesn't check it's own integrity, so it can be
>>infected by "virus" which intercept confidential keys and
>>passwords used for their protection and save them onto magnetic
>>carriers;
>
>The PGP manual warns of this problem. A well-designed virus could
>defeat any self-checking logic by attacking the self-checking logic.
>It would create a false sense of security if PGP claimed to check
>itself for viruses when you run it.
Maybe Sidelnikov is trying to tell us something here that goes beyond
the theoretical.
>
>> - the program has not optimal exponentiation algorithm in
>>GF(P) field, when P - prime number, which result in low
>>performance;
>
>PGP is freeware. Maybe the exponentiation is not as optimal as it
>could be if the PGP development effort were funded. In any case,
>improvements in the math algorithms have made PGP 2.0 faster than
>version 1.0, and version 2.1 is faster still. Of course, suggestions
>for improving the performance of the algorithms are always welcome.
Is Sidelnikov saying more than that the exponentiation isn't as fast
as possible? Is he, perhaps, saying something about cryptographic
weakness?
>
>> 2. The RSA algorithm realization problems
>>
>> - the prime numbers reception using in this program (R and q
>>in RSA algorithm) permits not less than on two order to reduce
>>the labour-intensiveness of factorization; with 256 bit blocks
>>of data lenght it is possible to execute the cryptanalysis in
>>real time;
>
>I don't know what this means. PGP does not normally work with RSA
>keys as small as 256 bits. No claims are made that this is a safe
>key length. Larger RSA keys are specifically recommended in the
>manual. And what does "real time" mean in this case?
If Sidelnikov says real time, he means real time. I take this to mean
that the Russians, and the NSA can do the factorization and read RSA
traffic with 256 bit keys in real time. If NSA's technology is better
than the Russians, maybe they can read even longer key traffic so
quickly as to make no difference. It would be interesting to see a
calculation (Phil?) which, assuming 256 bit keys can be read in real
time (call it a difficulty factor of 1.0), presents the difficulty
factors for 512 and 1024 bit keys.
>
>> - when considering the hashing function as the automatic device
>>without output, it is enough simply possible to construct the
>>image of reverse automatic device and with using the blanks in
>>text files (or free fields in some standard formats as in DBF),
>>to compensate the hashing function at changed file to former
>>significance.
>
>> Thus, it is possible to forge the electronic signature
>>without analysis of RSA algorithm.
>
>How? This claim sounds alarming, if true. But it requires that one
>of the following be true:
>
> a) The RSA algorithm itself has a weakness.
> b) The MD5 hash algorithm has a weakness.
> c) PGP has a programming bug in implementing either RSA or MD5.
>
>I doubt that RSA or MD5 have weaknesses that have surfaced here.
>If PGP has a bug in implementing RSA or MD5, I'd like to see a better
>description of the problem, to help find the bug. Is it possible
>to get a more coherent English translation of these remarks? What is
>the evidence of these assertions, so that the results may be reproduced?
>
>
>> 4. The block encryption algorithm problems
>>
>> - when executing analysis on plaintext and ciphertext the
>>linear correlation dependences with encryption key were founded
>>(0.01 and more degree);
>>
>> - also the effective method of decreasing security which
>>reduces the order of time necessery to key definition in two
>>times in comparison with exhaustive search of all keys (i.e.
>>algorithm has the labour-intensiveness which is equal the root
>>square from labour-intensiveness of the exhaustive search algorithm)
>>have been found.
>
>Again, a better English translation is required to decipher this
>claim. Also, where is the evidence? This sounds like he's saying
>the IDEA cipher is weak. Or maybe PGP has a bug in implementing it.
>If so, it should be fixed. But more information is needed to help
>reproduce the problem, if indeed there is a problem.
>
>>
>> The conclusions:
>>
>> It is recommended to use encryption with 1024 bit key length.
>>
>> The using of electronic signature is not recommended and
>> requires the additional study.
>>
>> The block encryption algorithm has temporary stability.
>
>What does "temporary stability" mean?
>
>>
>> The hashing function should be reduce in conformity with ISO
>> recommendations.
>>
>> The using of PGP program in actual version is undesired.
>>
>>
>> The MSU mathematical cryptography
>> problems Laboratory Manager
>> Academician
>>
>> Dr. Sidelnikov V.M.
>
>
>In conclusion, I'd like to point out that normally, when an academic
>paper is published that claims a cryptosystem is weak, it generally
>includes some real data to back up its claims. Such data is
>conspicuously absent here.
>
This attitude is a hiding behind "academic" practice in an area where
Sidelnikov has raised the most serious doubts about a number of
aspects of PGP as presently implemented. For him to be both an
Academician (the highest rank in Soviet Science, given to very few,
and after massive and extended demonstrations of competence) and a
Laboratory Manager means we ought to take his words with at least as
much seriousness (but without the associated "special pleading" doubts
some might have) as similar words from the head of the cryptanalysis
division (or whatever it is called) of the NSA.
Let me be perfectly clear here. Sidelnikov's standing in the
cryptology field in the Soviet scientific community is of the most
senior level, and that's not a statement about science politics. It's
also likely he was (is?) either one of the most senior scientists in the
former KGB cryptanalysis activity, or one of their most senior
advisors.
It's inappropriate to take his remarks as if they were those of some
competitive programmer picking nits about PGP's program code. It's
especially inappropriate to take a confrontational attitude. I suggest
Phil rethink this. I also suggest that Sidelnikov's advice about the
use of PGP be heeded. Were I going to use it, I'd use no less than a
1024 bit key, and even then worry about some of the other weaknesses.
Finally, I'd suggest extreme politeness in responding to Sidelnikov,
and no little respect. Think of him as the Russian equivalent of
Einstein in his field if it will help. In Soviet Science, Academicians
are analogous to "the immortals".
David
--
David Sternlight
RIPEM Public Key on server -- Consider it an envelope for your e-mail
Newsgroups: sci.crypt
Path: sparky!uunet!enterpoop.mit.edu!bloom-picayune.mit.edu!daemon
From: ty...@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan8.223337.14551@athena.mit.edu>
Sender: dae...@athena.mit.edu (Mr Background)
Reply-To: ty...@ATHENA.MIT.EDU (Theodore Ts'o)
Organization: The Internet
Date: Fri, 8 Jan 1993 22:33:37 GMT
Lines: 81
Crossposted-To: alt.security.pgp
From: strn...@netcom.com (David Sternlight)
Date: Fri, 8 Jan 1993 19:31:53 GMT
Maybe Sidelnikov is trying to tell us something here that goes beyond
the theoretical.
Maybe Mr. Sternlight is trying (once again) to raise Fear, Uncertainty,
and Doubt. You really don't like PGP, don't you? Unfortunately for
you, if what Dr. Sidelnikov says is true, then PEM and RIPEM will also
be vulnerable......
>
>> - when considering the hashing function as the automatic device
>>without output, it is enough simply possible to construct the
>>image of reverse automatic device and with using the blanks in
>>text files (or free fields in some standard formats as in DBF),
>>to compensate the hashing function at changed file to former
>>significance.
I interpreted this to mean that Dr. Sidelnikov believes that there is a
design flaw in MD5, which is the hashing function used by PGP. Perhaps
there is; MD5 hasn't been out there for all that long. But if it were
as simple as just changing the number of blanks in text files, someone
should have noticed by now. The whole point of a "cryptographic
checksum" such as MD5 is that it is not computationally feasible to
change the text in such a way to produce a given hash value, and thus
"compensate the hashing function at changed file to former
significance". To quote from RFC1321, "The MD5 Message-Digest
Algorithm":
The MD5 message-digest algorithm is simple to implement, and provides
a "fingerprint" or message digest of a message of arbitrary length.
It is conjectured that the difficulty of coming up with two messages
having the same message digest is on the order of 2^64 operations,
and that the difficulty of coming up with any message having a given
message digest is on the order of 2^128 operations. The MD5 algorithm
has been carefully scrutinized for weaknesses. It is, however, a
relatively new algorithm and further security analysis is of course
justified, as is the case with any new proposal of this sort.
If what Dr. Sidelnikov is true, then not only is PGP's signatures
insecure, but also everything else which uses MD5 --- which includes
PEM, RIPEM, SNMP security, and many other things. This does not mean
that what he says may not be true; but it is a major disaster if it is
really the case.
One final point; Mr. Sternlight seems to be saying that we should
believe everything posted by Sidelnikov because he is a Soviet
Academician. I would like to remind everyone that we have no
*authentication* that said posting was really posted by a Dr.
Sidelnikov, and even if it was, we have no *proof* that he really is an
Academician. This is not a slight against Dr. Sidelnikov; he may very
well be who he claims to be. But given the seriousness of his claims, I
think it is quite understandable that we request a some proof that what
he has claimed.
If he really does have an algorithm for breaking MD5, there are some
easy ways for him to demonstrate this without divulging the algorithm,
however. In RFC1321, Prof. Rivest published a MD5 test suite, which
included the following test items:
MD5 ("message digest") = f96b697d7cb7938d525a2f31aaf161d0
MD5 ("abcdefghijklmnopqrstuvwxyz") = c3fcd3d76192e4007dfb496cca67e13b
MD5 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =
d174ab98d277d9f5a5611c2c9f419d9f
MD5 ("1234567890123456789012345678901234567890123456789012345678901234567
8901234567890") = 57edf4a22be3c955ac49da2e2107b67a
If Dr. Sidelnikov can produce text strings which are different from the
above, and which evaluate to the same MD5 Message digests, then he will
have provided proof of his statement --- and a lot of people all over
the world will be scrambling to stop using MD5. :-)
[ If Dr. Sidelnikov isn't reading sci.crypt, could whoever originally
forwarded his message to sci.crypt kindly forward this message back to
him? Thanks! ]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o bloom-beacon!mit-athena!tytso
72 Marathon St, Arlington, MA 02155 ty...@athena.mit.edu
Everybody's playing the game, but nobody's rules are the same!
Xref: sparky sci.crypt:6592 alt.security.pgp:480
Newsgroups: sci.crypt,alt.security.pgp
Path: sparky!uunet!zaphod.mps.ohio-state.edu!n8emr!colnet!res
From: r...@colnet.cmhnet.org (Rob Stampfli)
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan9.172046.17709@colnet.cmhnet.org>
Organization: Little to None
References: <1993Jan8.173701.8858@ncar.ucar.edu>
Date: Sat, 9 Jan 1993 17:20:46 GMT
Lines: 38
In article <1993Jan8.1...@ncar.ucar.edu>
p...@sage.cgd.ucar.edu (Philip Zimmermann) writes:
>> - the sequence of random numbers has strong prevalences on
>>bytes (up to 0.05 ... 0.1 on material of 10000 byte) and strong
>>correlation dependence between contiguous bytes;
>
>Really? How so? What does "strong prevalences" mean? Is he talking
>about the internal random number source in random.c, used for making
>RSA keys? Or is he talking about the output of the IDEA cipher? In
>either case, evidence should be presented that allows others to
>reproduce his results. The random.c code for getting randomness from
>keyboard latency has been tested pretty well, and it uses MD5 to
>enhance the raw randomness from the keyboard timings. It looks
>pretty good to me. Does the IDEA cipher running in CFB mode output
>text that appears nonrandom? This is disturbing, if true. Biham and
>Shamir have thus far not succeeded in finding weaknesses in the IDEA
>cipher. Perhaps Dr. Sidelnikov has found one. I'd like to see some
>evidence of this claim.
It is not my intent to add fuel to any fire, but this seems like a good
springboard to voice a potential concern I have had with the Unix port of
pgp. Pgp seeds certain random number vectors by asking the user to type
some characters at the terminal and then measuring the times between
keystrokes. I know Phil gave some thought to this for pgp1.0, and it
probably works well in a DOS environment. However, some flavors of Unix do
not have the ability to measure time to the same granularity as DOS, and,
combined with the multiprocessing environment of Unix, the times gathered
may not be representative of the typist's true signature. I have not looked
at the code, but, empirically, I have gotten quite a few instances of '?'
when performing this ritual, which I believe means the number was thrown
out because it was too small.
Has anyone indeed paid any consideration to the randomness of the numbers
so generated under Unix? It would be comforting to know that someone has
looked into this, and even more comforting to know they concluded that
this is, indeed, not a problem.
--
Rob Stampfli r...@colnet.cmhnet.org The neat thing about standards:
614-864-9377 HAM RADIO: kd8wk@n8jyv.oh There are so many to choose from.
Xref: sparky sci.crypt:6593 alt.security.pgp:481 alt.security.ripem:81
Newsgroups: sci.crypt,alt.security.pgp,alt.security.ripem
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!usc!
sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!csus.edu!netcom.com!strnlght
From: strn...@netcom.com (David Sternlight)
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan10.000015.20757@netcom.com>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <1993Jan8.173701.8858@ncar.ucar.edu>
<1993Jan9.172046.17709@colnet.cmhnet.org>
Date: Sun, 10 Jan 1993 00:00:15 GMT
Lines: 16
Rob Stampfli suggests there may be a problem with unix systems'
granularity in measuring the intervals between random characters
typed as part of the PGP key generation process.
I notice that one RIPEM public key in the public server file has its
first 34 characters identical to my ripem public key. Perhaps this is
related. It seems an unlikely coincidence, given that the two keys
were generated by different individuals, apparently on different
computers, and very likely at different clock times.
David
--
David Sternlight
RIPEM Public Key on server -- Consider it an envelope for your e-mail
Xref: sparky sci.crypt:6594 alt.security.pgp:482 alt.security.ripem:82
Newsgroups: sci.crypt,alt.security.pgp,alt.security.ripem
Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!
linac!att!news.cs.indiana.edu!mvan...@mango.ucs.indiana.edu
From: Marc VanHeyningen <mvan...@whale.cs.indiana.edu>
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan9.193520.15261@news.cs.indiana.edu>
X-Quoted: 33%
Organization: Computer Science Dept, Indiana University
References: <1993Jan8.173701.8858@ncar.ucar.edu>
<1993Jan9.172046.17709@colnet.cmhnet.org> <1993Jan10.000015.20757@netcom.com>
Date: Sat, 9 Jan 1993 19:35:16 -0500
Lines: 20
Thus said strn...@netcom.com (David Sternlight):
>I notice that one RIPEM public key in the public server file has its
>first 34 characters identical to my ripem public key. Perhaps this is
>related. It seems an unlikely coincidence, given that the two keys
>were generated by different individuals, apparently on different
>computers, and very likely at different clock times.
From the RIPEM distribution "todo" file:
#=== Documentation ===
#
#-- Explain that all keys start with a PKCS identifier, so people won't
#think RIPEM has a bug that makes all keys similar.
This probably explains much, if not all, of the similarity.
--
Marc VanHeyningen mvan...@whale.cs.indiana.edu MIME & RIPEM accepted
Kirk: I won't hurt you.
Alien: You hit me!
Kirk: Well, I won't hit you again.
Xref: sparky sci.crypt:6597 alt.security.pgp:483 alt.security.ripem:83
Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!
msuinfo!scss3.cl.msu.edu!mrr
From: m...@scss3.cl.msu.edu (Mark Riordan)
Newsgroups: sci.crypt,alt.security.pgp,alt.security.ripem
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Date: 10 Jan 1993 01:23:17 GMT
Organization: Michigan State University
Lines: 25
Message-ID: <1intq5INNc5t@msuinfo.cl.msu.edu>
References: <1993Jan9.193520.15261@news.cs.indiana.edu>
NNTP-Posting-Host: scss3.cl.msu.edu
X-Newsreader: TIN [version 1.1 PL6]
Marc VanHeyningen (mvan...@whale.cs.indiana.edu) wrote:
: >I notice that one RIPEM public key in the public server file has its
: >first 34 characters identical to my ripem public key. Perhaps this is
: >related. It seems an unlikely coincidence, given that the two keys
:
: #=== Documentation ===
: #
: #-- Explain that all keys start with a PKCS identifier, so people won't
: #think RIPEM has a bug that makes all keys similar.
:
: This probably explains much, if not all, of the similarity.
Yes, I really ought to make this point in the documentation.
RIPEM uses MD5 is a pseudo-random-number generator in producing
keys (both keypairs and message keys). MD5 makes a very high-quality
PRNG. RIPEM keys are encoded according to OSI's Distinguished
Encoding Rules, using PKCS identifiers. This puts a lot of constant
bytes at the beginning of the key, so a program can tell exactly
what it's dealing with. If the key format is changed in the
future, RIPEM will be able to figure out that a given key was
in an old format and (presumably) adjust accordingly.
See the "pkcs" documents
available from rsa.com.
/mrr
Xref: sparky sci.crypt:6646 alt.security.pgp:486
Newsgroups: sci.crypt,alt.security.pgp
Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!grizzle.Stanford.EDU!castor
From: cas...@grizzle.Stanford.EDU (Castor Fu)
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan11.174606.3566@leland.Stanford.EDU>
Sender: ne...@leland.Stanford.EDU (Mr News)
Organization: DSO, Stanford University
X-Newsreader: Tin 1.1 PL5
References: <930111.145154.0F0.rusnews.w165w@mantis.co.uk>
Date: Mon, 11 Jan 93 17:46:06 GMT
Lines: 10
Whatever "academician" means, it probably doesn't mean "member of the
Soviet Academy of Sciences." I just went to our library, and looked through
the list of members of the Soviet Academy, and there was no V.M. Sidelnikov.
This was a pretty recent list, (1991).
Unless you choose to believe that there is a "secret list" this casts
some doubt on the rest of the article.
--
Castor Fu, (f...@leland.stanford.edu)
Xref: sparky sci.crypt:6677 alt.security.pgp:489
Newsgroups: sci.crypt,alt.security.pgp
Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!wupost!csus.edu!
netcom.com!strnlght
From: strn...@netcom.com (David Sternlight)
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <1993Jan12.015235.18648@netcom.com>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <930111.145154.0F0.rusnews.w165w@mantis.co.uk>
<1993Jan11.174606.3566@leland.Stanford.EDU>
Date: Tue, 12 Jan 1993 01:52:35 GMT
Lines: 24
In response to Castor Fu, who has gone to some trouble to id
Sidelnikov, as I've said in my e-mail to him (dunno if I've posted
this or not), I received e-mail from a Russian at one of the most
reputable U.S. Universities whose bona fides seem genuine, who says he
knows Sidelnikov, has met him in Moscow, and he is who he says he is.
Whether the Sidelnikov message is a spoof or not isn't known, but the
history of its posting (first to an internal Russian network, then
forwarded by a Latvian to us) seems to suggest Sidelnikov's bona fides
had ample opportunity to be questioned in Russia and Latvia, and
apparently were not.
Unless you think the Latvian poster made it all up.
Well, there's no point in arguing about it--the warning is there and
may be ignored, accepted, or used as a tip to attempt independent
verification of the claims.
David
--
David Sternlight
RIPEM Public Key on server -- Consider it an envelope for your e-mail
Xref: sparky sci.crypt:6727 alt.security.pgp:492
Newsgroups: sci.crypt,alt.security.pgp
Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!emory!rsiatl!jgd
From: j...@dixie.com (John De Armond)
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Message-ID: <!q5rnkk@dixie.com>
Date: Tue, 12 Jan 93 22:50:51 GMT
Organization: Dixie Communications Public Access. The Mouth of the South.
References: <1993Jan12.015235.18648@netcom.com>
Lines: 84
strn...@netcom.com (David Sternlight) writes:
>In response to Castor Fu, who has gone to some trouble to id
>Sidelnikov, as I've said in my e-mail to him (dunno if I've posted
>this or not), I received e-mail from a Russian at one of the most
>reputable U.S. Universities whose bona fides seem genuine, who says he
>knows Sidelnikov, has met him in Moscow, and he is who he says he is.
>Whether the Sidelnikov message is a spoof or not isn't known, but the
>history of its posting (first to an internal Russian network, then
>forwarded by a Latvian to us) seems to suggest Sidelnikov's bona fides
>had ample opportunity to be questioned in Russia and Latvia, and
>apparently were not.
>Unless you think the Latvian poster made it all up.
>Well, there's no point in arguing about it--the warning is there and
>may be ignored, accepted, or used as a tip to attempt independent
>verification of the claims.
Dave, do you see that little glow in the corner of your eye? That's
your credibility dissipation light glowing brightly. (to steal from
some movie or the other.) Your unrestrained and illogical campaigning
for PKP is now costing you credibility on an issue people should be
paying attention to.
My contacts with ex-soviet nuclear colleagues also indicates Dr. Sidelnilov
is who he says he is. I have sent old-fashioned paper mail to someone
in Russia who will absolutely confirm or deny Dr. Sidelnilov's credentials
but the answer will likely come too late for this debate. As to the
claim that if Dr. Sidelnilov was part of the old Soviet government, he
would not be talking, that is complete rubbish. As a nuke who is active
on the net and who helped through private channels during Chernobyl,
I have been contacted by people in the ex-Soviet weapons programs who I only
knew by reputation in the literature, offering just about anything I
wanted in return for money and/or US employment. Anyone who thinks high
level military information from the ex-SU is not available to just about
anyone is fooling themselves. It feels strange to be able to know more
about Soviet atomic weapons than I do about my own country's.
My position on PGP and the private use of crypto technology should be
quite clear to the reader from my past sparring with Sternglass and
ilk. Nontheless, the display of kneejerking I've read in this
thread has been most dismaying. Dr. Sidelnilov has been attacked for
for the imperfect English translation, for criticizing the sacred PGP,
for not entering into a debate in this forum even though it was quite
clear that the posting was a translation from a local SU net and various
and sundry other items.
What I have NOT read is anyone taking his analysis and trying to confirm
or deny its validity. The messenger has been attacked but not the
message. Is this really what science had degenerated to? Namecalling?
Where is the philosophy that any crypto system should be suspected
until exhaustively proven secure in the state of the art environment
that exists at the moment? Is the thought of sticking it in the eye
of the NSA, PKP and Commerce Department so overwhelmingly appealing
that all consideration of PGP's weaknesses are buried? For that matter,
how do we know for sure that IDEA or even PGP itself is not a flawed
product of the intelligence community, planted as an underground product
to ensure its use by those most likely to do something of interest
by the government? Saying you know Zimmerman or whomever does not
count, of course. If one is going to use crypto for something where
it really matters that the materials be kept secret, one must
address these questions.
I'm not a crypto expert and so must rely on others who are for the analysis
of PGP and other schemes. My reading of Dr Sidelnilov's analysis is
that what he says is reasonable. Whether it is correct or not must
come from someone else, someone who I hope will forget the personal
attacks and analyze the problem. At this point what he says makes
AT LEAST as much sense as the so-far unsubstantiated claims that NSA
weakened DES intentionally.
Could we for a moment quit worrying about credentials and take a look
at the issue?
Thanks,
John
--
John De Armond, WD4OQC |Interested in high performance mobility?
Performance Engineering Magazine(TM) | Interested in high tech and computers?
Marietta, Ga | Send ur snail-mail address to
j...@dixie.com | per...@dixie.com for a free sample mag
Need Usenet public Access in Atlanta? Write Me for info on Dixie.com.