The patch v10 should now cover all change requests from Werner as documented in
the cover-letter.

However, I am not fully sure about the interface yet: the GCRY_DRBG_REINIT is
now solely limited to normal DRBG use. I do not see how that can be merged to
existing random interfaces.

The CAVS test interface is now isolated to the control value 75 similarly to the
X9.31 testing approach. However, the current approach triggers a compile time
warning about the undefined enum 75.

See [1] in libgcrypt/test/ for a test application that uses the DRBG in normal
mode and in CAVS test mode -- search for gcry_control.

Tested:

• 32 / 64 bit
• CAVS testing on both arches
• brief stess testing by creating 200 MB of data and checking it with ent to see

that the output function is not broken

[1] http://www.chronox.de/drbg/drbg-20140907.tar.bz2

D216: 500_v10-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

Thanks.

re: indent: You mixed prototype and functions and thus by quickly browsing the
source I noticed the prototype - which are correct.

re: API it is a bit hard to check from just the patches. Thus I suggest that I
apply your next patch and then look again at it.

re: reregssion test: We can use a secret API for that so that it is not part of
the stable ABI. See for example tests/fipsdrv.c:init_external_rng_test

Please do not use C99 feature like // and struct init using symbols. I am
willing to fix that, though.

re GPL: will do

re one patch: will do

I will make also the requested code changes. Though, the indentation makes me
wonder. As I am not used to this indentation, I used the help of indent wit the
following command as specified on the GNU home page: indent -nbad -bap -nbc -bbo
-bl -bli2 -bls -ncdb -nce -cp1 -cs -di2 -ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs
-psl -nsc -nsob. Now, what is wrong with the indentation?

Re reusing the API: I am wondering where I do not reuse the API? The normal
usage is via the gcry_randomize function. The external hook is used for:

1. changing the type of DRBG (note, the code implements many random number

generators)

2. allowing the use of the personalization string / additional info string (I

would not know how to use that with gcry_randomize.

3. allow the CAVS testing to be performed.

If you have suggestions on how to cover that using existing APIs, I would be
very much interested in it.

One last thing: Libcrypt is under the LGPLv2+ but your alternative license is
under an unspecified version of the GPL. Can you change the alternative license
to the "GNU Lesser General Public License as published by the Free Software
Foundation; either version 2.1 of the License, or (at your option) any later
version."?

I would also prefer one patch and not a set of patches.

I have alsready pushed the GCRYCTL_DRBG_REINIT constant so that the value is
reserved.

The patch needs some rework: At a first glance gcrypt.h has new strucures using
symbols not from the gcrypt name space (_gcry or gcry prefixes). I noticed
quite some other Linux specific stuff like __u8 instead of unsigned character,
different indentation, and remove of page breaks (^L).

I have not looked at the API but I wonder why you don't re-use the existing
random API. Adding new functions for your RNG is not a good idea - unless there
is a real good reason for it. Exposing internals in the API is a no-go.

Changes v9:
drbg_int2byte replaced by drbg_cpu_to_be32 and the use of be_bswap32
and be_bswap64 for converting an integer into a character string.
Besides performance increase, it fixes the conversion on 32 bit machines.

Tested:

• on 64 and 32 bit

• CAVS on both arches

• sanity tests on 32 and 64 bit

D217: 497_v9-0007-User-interface-to-DRBG.patch

D218: 496_v9-0006-DRBG-specific-gcry_control-requests.patch

D219: 495_v9-0005-Function-definitions-for-gcry_control-callbacks.patch

D220: 494_v9-0004-Invoke-DRBG-from-common-libgcrypt-RNG-code.patch

D221: 493_v9-0003-Function-definitions-of-interfaces-for-random.c.patch

D222: 492_v9-0002-Compile-DRBG.patch

D223: 491_v9-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

v8 does not compile on 32 bit

Update of the entire patch set to version 8:
Fix the functions drbg_max_addtl, and drbg_max_requests to not overflow
size_t in 32 bit. Furthermore, the per-DRBG option for maximum requests,
maximum request bits and maximum length of additional information is removed
in favor of a global setting. The change only affects drbg.c

Note: only the patch 0001 is changed compared to version 7 of the patch set.

D224: 489_v8-0007-User-interface-to-DRBG.patch

D225: 488_v8-0006-DRBG-specific-gcry_control-requests.patch

D226: 487_v8-0005-Function-definitions-for-gcry_control-callbacks.patch

D227: 486_v8-0004-Invoke-DRBG-from-common-libgcrypt-RNG-code.patch

D228: 485_v8-0003-Function-definitions-of-interfaces-for-random.c.patch

D229: 484_v8-0002-Compile-DRBG.patch

D230: 483_v8-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

Meanwhile implemnted in all branches.

On 32 bit, a problem was just discovered in the kernel development branch: see
discussion in https://lkml.org/lkml/2014/8/26/59.

The base line is that the bit shift in drbg_max_addtl and drbg_max_requests are
stored in a size_t which is 32 bit on 32 bit machines. Yet, the bit shift is
larger than 32 bit. It will be fixed in the next installment of the patch.

D231: 473_v7-0007-User-interface-to-DRBG.patch

D232: 472_v7-0006-DRBG-specific-gcry_control-requests.patch

D233: 471_v7-0005-Function-definitions-for-gcry_control-callbacks.patch

D234: 470_v7-0004-Invoke-DRBG-from-common-libgcrypt-RNG-code.patch

D235: 469_v7-0003-Function-definitions-of-interfaces-for-random.c.patch

D236: 468_v7-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

D237: 467_v7-0002-Compile-DRBG.patch

To go into master.

Please send a DCO to gcrypt-devel and ask for a review of the code.

There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.

Thank you for the prompt response.

I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?

This has been discussed at gnupg-users at lengths. You need to read the OpenPGP
standard to understand some of the defaults. For the others you may start yet
another disucssion thread at gnupg-users.

re 4) The iteration count used depends on the machine.

IIRC, there is a need to allocate a new console or something like this. It is
too long since I studied this and concluded it is too much work and English
users won't appreciate it anyway ;-)

I don't think switching the console to UTF-8 is the real problem here.

At least just using chcp is not enough. Fonts do also factor into this and this
is where it gets weird:

If you run chcp 65001 and have a raster font selected the output is garbled.
If you then switch to a truetype font the output is correctly interpreted.

Now if you run the command while already having a truetype font selected the
output is garbled again but differently.. o.O

And looking at common/utf8conf.c there is already code that tries to handle
different Console Output Codepages but appearently there is a bug somewhere in
there :) (Or that code is not used / respected)

You probably need a helper. I have no idea whether such a tool exists. Windows
System Programming should have all the details.

What is the best way to switch the console to utf mode?
Should someone use the chcp command and how?

Anyway the default behaviour is surprising for users, so from my point of view,
it should be improved somehow. A good documentation how to switch would only
be a second grade solution. A better one would be if the .exes would switch the
code page themselfs, I assume.

No, the patch is a hack which works just for you and not for other environments.

As I already explained a proper solution will be quite complicated and it won't
be the Unix way.

I like to help with the proposed 2.1 solution. However, the fastest thing to do
is to change the system to sign a manifest file. That is more flexible and
makes it easier to add additional signatures.

Any progress on this? Thank you.

Thanks for your ideas. Nonetheless, this patch is used by OBS project for years
in production so we would like to use this solution we know works fine rather
then creating something else. If you would like to see more how it works
internally, look at sign.c[0] and sign daemon[1].

Can we please get to some resolution? Please tell me whether:
1, you will accept such a patch
2, you would accept with changes
3, you don't want anything alike in gnupg for the moment

For the maintainer of gnupg in Fedora is important that we don't include
something that you would include as well, but differently. Thank you!

[0]https://github.com/openSUSE/obs-sign/blob/master/signc
[1]https://github.com/openSUSE/obs-sign/blob/master/signd

You should have said this directly ;-) IIRC, we have a similar request
in the bug tracker. The problem here is that you need to save the
internal state of the hash computation, then restore the hash on the
server and continue the hashing, and finally return the state of the
hashing to the signing box which will then finalize it. There are all
kind of complication with that (e.g. marshaling and unmarshaling the
state) so most people turned to the simple and easier to understand
solution of signing a MANIFEST file.

However, with 2.1 it is possible to implement a more elegant solution:
You run gpg on the server and gpg-agent on the client. gpg-agent
takes care of the secret key operations while gpg does the bulk data
and public key stuff. To implement that the gpg<->gpg-agent IPC needs
to be changed from local sockets to TCP over some encrypted tunnel. I
have not checked whether ssh is already able to proxy a local socket -
but if it can do so, you have an instant solution.

Hi,
I see no progress on this RFE report, therefore I want to clarify it more verbosely.
In T1646 (wk on Jun 16 2014, 08:29 AM / Roundup) you asked, why we could not use:

ssh REMOTE 'cd DIR && sha256sum *dat' | gpg -s >files.sig

We could not use this because this will create sign the checksum - not the
payload of this checksum. In other words:
sha256sum create digest, then gpg2 internally create digest of this digest and
will create signature.
What we want to achieve is to bypass creating of digest in gpg2 and accept it as
parameter.

We have 'package build server' and normal signing process means:

1. copy data to signing server
2. gpg2 -sb
3. copy signature back
4. pass signature to rpmsign

But if the data is some iso/docker image or rpm package several gigabytes big,
then we have bottleneck problem. So we
changed the work-flow to:

1. make digest of the data
2. copy digest to signing server
3. gpg2 -sb --digest-algo <algo> --file-is-digest <digest>
4. copy signature back
5. pass signature to rpmsign

If we would do in step 3:

echo <signature> |gpg2 -bs

it would not be signature of header+payload which we want to sign and the
signature would not match.

To sum it up - we want to bypass computation of digest inside of gpg2. As digest
computation is in fact not secret and
it can be delegated somewhere else. Of course you have to trust those
environment which compute that digest. Which we do.
It allows separation of signing server apart from building server and allows us
to secure private keys even more, while
it allows no degradation of performance.

I hope that this clarify it little bit.

PKIX is entirely broken. Even the most expensive SSL certificate does not get
you any assurance. To avoid man-in-the-middle threats, please check the OpenPGP
signature with an existing version of gpg4win or compare the published
SHA-1checksums with those from the announcement mails.

Done for 2.1 with commit 03018ef

Fic for master with commit c434de4. However decryptyed files are not subject to
this because that would for sure breakk too man applications.

Just for my information, do you have done some tests for GnuPG2 on boot (because existant script are based on gpg) ?

okay.

Hello Werner,

Applied to master and 2.0.

I'll apply the patch. Thanks.

I don't think that it is worth the trouble. A pinpad reader make most sense on
desktop machines and there we have 2.x. 1.4 is maintained for use on servers
where card support is anyway hard to operate.

I can confirm to you as I've write last time, but this time with new gnupg2 (2.0.24)
and gnupg (1.4.16) version, than Vega reader works fine with gpg-agent, but failed without it.

It seems that you missed the patch attached to the original submission, which
has all the required info: vendor ID is VENDOR_GEMPC (0x08e6), product ID is
0x3437, and the change to be applied indeed is in the internal CCID driver.

The reader is supported by PC/SC-lite, which never uses non-null NADs.

In 2.1.x (development), scdaemon and its pinpad support has been improved
(including name change from "keypad" support), and it's backported to 2.0.x.

However, it is not backported to 1.4.x. For gpg of 1.4.x, it only works when
you use gpg-agent and scdaemon of 2.?.x.

Some fixes (such as PC/SC support for MacOS) are backported to 1.4.x, though.

For Covadis Vega-Alpha, we would need to backport pinpad support improvement, as
well as CCID driver support improvement (for no auto configuration feature).

Changes are not trivial to merge, I don't know if it's worth for 1.4.x.

Could you please give more information, such as its USB vendor ID and product ID?
I assume that you are using GnuPG's internal CCID driver.
If you have a patch, please attach it here.
Is the reader supported by PC/SC-lite? If so, we could see how it is handled.