home *** CD-ROM | disk | FTP | other *** search
- 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: mrr@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 (mvanheyn@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
-