Original release date: May 30, 2000<BR>
Last Revised: --<BR>
Source: CERT/CC<BR>

<P>A complete revision history is at the end of this file.

<A NAME="affected">
<H3>Systems Affected</H3>

<UL>
<LI>
UNIX systems having a <i>/dev/random</i> device running any version of PGP
5.0, including U.S. Commercial, U.S. Freeware, and International versions
</li>
<li>Keys created non-interactively on such a system</li>
<li>Documents encrypted with such a key</li>
<li>Signatures generated with such a key
</UL>
<H2>Overview</H2>

<P>
Under certain circumstances, PGP v5.0 generates keys that are not
sufficiently random, which may allow an attacker to predict keys and,
hence, recover information encrypted with that key. 


<A NAME="description">
<H2>I. Description</H2>

<p>In order to generate cryptographically secure keys, PGP (and other
products) need to use random numbers as part of the input to the key
generation process. Generating truly random numbers is a difficult
problem. PGP has traditionally solved that problem by prompting the
user to type some random characters or to move the mouse in a random
manner, measuring the time between keystrokes and using this as a
source of random data. Additionally, PGP uses a file (usually called
<i>randseed.bin</i>) as a source of randomness. 

However, PGP also provides the ability to generate keys
non-interactively (useful, for example, if you need to generate a
large number of keys simultaneously or provide a script to generate a
key). When generating keys non-interactively, PGP needs a source of
random numbers; on some systems PGP v5.0 uses the <i>/dev/random</i>
device to provide the required random numbers.

<p>PGP v5.0, including U.S. Commercial, U.S. Freeware, and
International versions, contains a flaw in reading the information
provided by <i>/dev/random.</i> This is not a flaw in
<i>/dev/random</i> but instead is the result of a flaw in how PGP
processes the information returned from <i>/dev/random.</i>

Thus, when a key is generated non-interactively using a command such
as

<dd>
<dl><b>pgpk -g </b><<i>DSS or RSA</i>> <<i>key-length</i>> <<i>user-id</i>> <<i>timeout</i>>
<<i>pass-phrase</i>>
</dl>
</dd>

<p> it does not contain sufficient randomness to prevent an attacker
from guessing the key. If such a command were issued on a system with
no available <i>randseed.bin</i> file, then the resulting key may
be predictable. 


<p>This problem was discovered and analyzed by Germano Caronni
&lt;gec@acm.org&gt;, and verified by Thomas Roessler &lt;roessler@guug.de&gt;
and Marcel Waldvogel &lt;mwa@arl.wustl.edu&gt;. A copy of their analysis can
be 
found at

<dd>
<dl> 
<A HREF="http://www.securityfocus.com/templates/archive.pike?list=1&msg=20000523141323.A28431@olymp.org">
http://www.securityfocus.com/templates/ archive.pike?list=1&msg=20000523141323.A28431@olymp.org</a>



<A NAME="impact">
<H2>II. Impact</H2> 

<p>Keys produced non-interactively with PGP v5.0 on a system with a
<i>/dev/random</i> device may be predictable, especially those
produced in an environment without a pre-existing <i>randseed.bin</i>
file. 

<p>Documents encrypted with a vulnerable key may recoverable by an
attacker. Additionally, an attacker may be able to forge a digital
signature corresponding to a vulnerable key.

<P>Signatures produced using a vulnerable key, including signatures in
certificates, may be untrustworthy. 

<A NAME="solution">
<H2>III. Solution</H2>
<p>If your PGP key was generated non-interactively using any version of
PGP v5.0 on a system with a <i>/dev/random</i> device, you may wish to
revoke it. 

<p>Documents encrypted with a predictable key may need to be
re-encrypted with a non-vulnerable key, if your particular
circumstances warrant it; that is, if the information still needs to
be encrypted.

<p>You may need to resign documents signed with a vulnerable key if
your circumstances warrant it.

<H2>Appendix A Vendor Information</H2>

<H3>Network Associates</H3>


Network Associates Security Advisory<br>
Date: May 30, 2000<br>
Author: PGP Engineering<br>

<p>Background:

<p>A security issue has been discovered in the following PGP products:

 <li>PGP 5.0 for Linux, US Commercial and Freeware editions
 <li>PGP 5.0 for Linux, Source code book (basis for PGP 5.0i for Linux)
</ul>

<p>The following PGP products are NOT affected by this issue:

<ul>
 <li>PGP 1.x products
 <li>PGP 2.x products
 <li>PGP 4.x products
 <li>All other PGP 5.x products
 <li>PGP 6.x products
 <li>PGP 7.x products
</ul>

<p>Synopsis:

<p>During a recent review of our published PGP 5.0 for Linux source 
code, researchers discovered that under specific, rare circumstances 
PGP 5.0 for Linux will generate weak, predictable public/private
keypairs.  These keys can only be created under the following 
circumstances:
<ul>

 <li>Keys are generated using PGP's command line option for unattended
   batch key generation, with no user interaction for entropy 
   (random data) collection

 <li>No keys were generated interactively on this system previously
   (e.g., a PGP random seed file is not present on this system
    prior to unattended batch key generation)

 <li>PGP is able to access the UNIX /dev/random service to gather
   entropy during unattended batch key generation
</ul>

<p>PGP 5.0 for Linux does not process the data read from /dev/random
appropriately, and therefore does not gather enough entropy required 
to generate strong public/private keypairs.  This issue affects
both RSA and Diffie-Hellman public/private keypairs, regardless of
keysize.  Network Associates has verified that this issue does not 
exist in any other version of PGP.

<p>Solution:

<p>Users who generated keys in the manner described above are strongly 
urged to do the following:
<ul>

  <li> Revoke and no longer use keys suspected to have this problem

  <li>Generate new public/private keypairs with entropy collected
    from users' typing and/or mouse movements

  <li>Re-encrypt any data with the newly generated keypairs that is
    currently encrypted with keys suspected to have this problem

  <li> Re-sign any data with the newly generated keypairs, if required
</ul>

<p>Users are also urged to upgrade to the latest releases of PGP, 
as PGP 5.0 products have not been officially supported by Network
Associates since early 1999, or distributed by Network Associates
since June 1998.

<p>Additional Information:

<p>US commercial and freeware versions of PGP 5.0 for Linux were 
released in September 1997 by PGP, Inc., a company founded by 
Phil Zimmermann.  Source code for the PGP 5.0 product family was 
published in September 1997.  PGP, Inc. was acquired by Network
Associates in December 1997.

<p>Acknowledgements:

<p>PGP appreciates the efforts of Germano Caronni, Thomas Roessler and 
Marcel Waldvogel in identifying this issue and bringing it to our 
attention.



<P>A <A HREF="CA-2000-09/pgp.asc">pgp signed</A> version of this
statement is also available at 

<dl>
<dd>
<A
HREF="http://www.cert.org/advisories/CA-2000-09/pgp.asc">http://www.cert.org/advisories/CA-2000-09/pgp.asc</a>
</dd>
</dl>

<HR NOSHADE>

<P>The CERT Coordination Center thanks Germano Caronni, Thomas
Roessler, and Marcel Waldvogel for initially discovering and reporting
this vulnerability, and for their help in developing this
advisory. Additionally we thank Brett Thomas for his insights.

<P></P>

<HR NOSHADE>

<P>Shawn Hernan was the primary author of this document.

<P></P>

<!--#include virtual="/include/footer_nocopyright.html" -->

<P>Copyright 2000 Carnegie Mellon University.</P>

<P>Revision History
<PRE>
May 30, 2000:  initial release
</PRE>