[PATCH 0/2] SP800-90A DRBG

Werner Koch wk at gnupg.org
Mon Feb 22 08:36:17 CET 2016


On Fri, 19 Feb 2016 16:47, smueller at chronox.de said:

>> all algorithms except that SHA384 is not anymore accessible (does that
>> make sense at all?)
>
> It probably does not make sense for libgcrypt, you are right.

OTOH, it would be just one extra line in the flags parser table.

> I only now have the question whether this change is visible to the API/ABI 
> because people were in need of the DRBG for libgcrypt: The DRBG is out in the 
> wild for quite some time now. RHEL and SLES use the DRBG code base in 

You mean, they use Libgcrypt with your patch?  That would of course be a
problem (for them).  I recall that we agreed quite some time ago to add
the GCRYCTL_DRBG_REINIT constant but we did not agree on any semantic.
I guess that the introduction of the guard argumennt (last arg must be
NULL) will catch most usages of the patched version of DRBG_REINIT.

OTOH, 1.7 has not been officially released and if a vendor is using a
patched version based on 1.6 they will run into ABI numbering problems:

 1.5 uses      C19/A8/Rx  (.so.11.8.x  (for most Linux based OS))
 1.6 uses      C20/A0/Rx  (.so.20.0.x)
 1.7 will/uses C21/A1/R0  (.so.21.1.0)

The LT version number for 1.7 is however already in use by at least
anyone using Curve25519 (ECDH) and thus we can't change the LT version
for 1.6 anymore.  I doubt that it would be justified to change the major
SO number for Libgcrypt 1.7 due to an unofficial and no-coordinated ABI
change by one vendor.

> Thank you. I offer to perform a full CAVS test on your code changes. Where can 
> I find your patch set?

Given that we want to release 1.7 soonish I have pushed that to master.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Gcrypt-devel mailing list