[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