On 11/19/2014 10:03 AM, Philip Bellino wrote:
> Hello,
> I am currently using openssl-fips-2.0.7 and I noticed that 2.0.8 is available 
> on the website.
> Neither distribution contain a changelog, so I was wondering what changes 
> were made to 2.0.8.
> Thanks,
> Phil

The relevant differences cam be found in the "Modification History"
section of the Security Policy document. The only relevant difference
between 2.0.8 and 2.0.7 source code is the re-removal of Dual EC DRBG.

I say "re-removal" and not removal because Dual EC DRBG was originally
removed with revision 2.0.6. However, the 2.0.6 submission languished at
the CMVP for six months during which time we added additional platforms
to revision 2.0.7, using code which still included Dual EC DRBG as that
removal had not yet been approved. As it turns out both 2.0.6 and 2.0.7
were approved in the same week. We had to wait for 2.0.8 to remove Dual
EC DRBG again, hopefully permanently this time.

If you don't care about the presence of Dual EC DRBG -- which you
shouldn't be using and which isn't usable anyway due to a bug discovered
by Steve Checkoway et. al. in their analysis of Dual EC DRBG
implementations (http://dualec.org/) -- then there is no reason to
upgrade to 2.0.8 if 2.0.7 is currently working for you.

As a general rule you should use the latest available revision of the
OpenSSL FIPS Object module for all new development, as that revision
will support all tested platforms. But, there is no need to upgrade
already deployed FIPS module instances. Since we are generally not
allowed to introduce bugfixes or performance enhancements to already
validated FIPS modules, the latest revision is generally not "better" in
any significant sense than earlier revisions. In particular we are
generally unable to address vulnerabilities that we know are present in
or with the FIPS module (e.g. "Lucky 13"), so we don't. The revision
increment usually only represents the addition of specific new platforms.

The exception to that rule is the removal of Dual EC DRBG, which can be
considered a bugfix and/or enhancement. Even there the presence of
unused Dual EC DRBG code in the older revisions does not *directly*
represent a security vulnerability. I say "directly" because there is an
argument, forcefully expressed to me by several stakeholders and
interested parties, that the mere presence of latent Dual EC DRBG code
is a potential problem. I have discussed that issue in a personal blog
entry:

  http://veridicalsystems.com/blog/immutability-of-fips/

for those who care to stare into that abyss.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to