* cipher/rsa.c (secret_core_crt): Blind secret D with randomized
nonce R for mpi_powm computation.
--
Backport of libgcrypt 8725c99ffa41778f382ca97233183bcd687bb0ce.
Signed-off-by: Marcus Brinkmann <mb@g10code.com>
* cipher/random.c (mix_pool): Store the first hash at the end of the
pool.
--
This fixes a long standing bug (since 1998) in Libgcrypt and GnuPG.
An attacker who obtains 580 bytes of the random number from the
standard RNG can trivially predict the next 20 bytes of output.
This bug does not affect the default generation of
keys because running gpg for key creation creates at most 2 keys from
the pool: For a single 4096 bit RSA key 512 byte of random are
required and thus for the second key (encryption subkey), 20 bytes
could be predicted from the the first key. However, the security of
an OpenPGP key depends on the primary key (which was generated first)
and thus the 20 predictable bytes should not be a problem. For the
default key length of 2048 bit nothing will be predictable.
For the former default of DSA+Elgamal key it is complicate to give an
answer: For 2048 bit keys a pool of 30 non-secret candidate primes of
about 300 bits each are first created. This reads at least 1140 bytes
from the pool and thus parts could be predicted. At some point a 256
bit secret is read from the pool; which in the worst case might be
partly predictable.
The bug was found and reported by Felix Dörre and Vladimir Klebanov,
Karlsruhe Institute of Technology. A paper describing the problem in
detail will shortly be published.
CVE-id: CVE-2016-6313
Signed-off-by: Werner Koch <wk@gnupg.org>
* README, cipher/cipher.c, cipher/pubkey.c, doc/gpg.texi: replace
"allow to" with clearer text
In standard English, the normal construction is "${XXX} allows ${YYY}
to" -- that is, the subject (${XXX}) of the sentence is allowing the
object (${YYY}) to do something. When the object is missing, the
phrasing sounds awkward, even if the object is implied by context.
There's almost always a better construction that isn't as awkward.
These changes should make the language a bit clearer.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* checks/armor.test, cipher/des.c, g10/ccid-driver.c, g10/pkclist.c,
util/regcomp.c, util/regex_internal.c: correct the spelling of
"occured" to "occurred"
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* cipher/rndunix.c [HAVE_STDINT_H]: Include stdint.h.
(start_gatherer): Detect misbehaving sysconf.
--
See
GnuPG-bug-id: 1778
for the reason of this patch. There is no concrete bug report but this
chnage should not harm.
Signed-off-by: Werner Koch <wk@gnupg.org>
* cipher/rsa.c (rsa_sign): Verify after sign.
* g10/gpg.c (opts): Make --no-sig-create-check a NOP.
* g10/options.h (opt): Remove field "no_sig_create_check".
* g10/sign.c (do_sign): Do check only for DSA.
Signed-off-by: Werner Koch <wk@gnupg.org>
* cipher/elgamal.c (USE_BLINDING): New.
(decrypt): Rewrite to use ciphertext blinding.
--
CVE-id: CVE-2014-3591
As a countermeasure to a new side-channel attacks on sliding windows
exponentiation we blind the ciphertext for Elgamal decryption. This
is similar to what we are doing with RSA.
Unfortunately, the performance impact of Elgamal blinding is quite
noticeable: For a 3072 bit Elgamal key the decryption used to take
13ms; with the blinding it takes 24ms. This has been measured using
time(1), calling gpg with a 100 byte message, and having gpg modified
to run the pubkey_decrypt function 100 times and finally scale the
result (using an i5-2410M CPU @ 2.30GHz TP 220).
* cipher/rndlinux.c (rndlinux_gather_random): Check fd before using
FD_SET.
--
If on systems where the maximum number of fds may be dynamically
configured to a value of FD_MAXSIZE or higher and the RNG is first
used after more than FD_SETSIZE-1 descriptors are in use, we disable
the progress messages from the RNG. A better solution would be too
use poll but that requires more tests.
The same problem exists in rndunix.c - however this rng is only used
on old Unices and I assume that they don't feature dynamically
configured maximum fd sizes.
(from Libgcrypt commit 9487099071af4478d2882e633a0ade805801d6fa)
This may fix
GnuPG-bug-id: 1818
* cipher/rsa.c (secret): Normalize the INPUT.
(rsa_decrypt): Pass reduced data to secret.
* cipher/elgamal.c (decrypt): Normalize A and B.
* cipher/dsa.c (sign): Normalize HASH.
--
mpi_normalize is in general not required because extra leading zeroes
do not harm the computation. However, adding extra all zero limbs or
padding with multiples of N may be useful in side-channel attacks. In
particular they are used by the acoustic crypt-analysis. This is an
extra pre-caution which alone would not be sufficient to mitigate the
described attack.
CVE-id: CVE-2013-4576
Signed-off-by: Werner Koch <wk@gnupg.org>
* cipher/random.c (randomize_mpi): New.
* g10/gpgv.c (randomize_mpi): New stub.
* cipher/rsa.c (USE_BLINDING): Define macro.
(secret): Implement blinding.
--
GPG 1.x has never used any protection against timing attacks on the
RSA secret operation. The rationale for this has been that there was
no way to mount a remote timing attack on GnuPG. With the turning up
of Acoustic Cryptanalysis (http://cs.tau.ac.il/~tromer/acoustic) this
assumption no longer holds true and thus we need to do do something
about it. Blinding seems to be a suitable mitigation to the threat of
key extraction. It does not help against distinguishing used keys,
though.
Note that GPG 2.x uses Libgcrypt which does blinding by default.
The performance penalty is negligible: Modifying the core pubkey_sign
or pubkey_decrypt function to run 100 times in a loop, the entire
execution times for signing or decrypting a small message using a 4K
RSA key on a Thinkpad X220 are
Without blinding: 5.2s (8.9s)
With blinding: 5.6s (9.3s)
The numbers in parentheses give the values without the recently
implemented k-ary exponentiation code. Thus for the next release the
user will actually experience faster signing and decryption. A
drawback of blinding is that we need random numbers even for
decryption (albeit at low quality).
Signed-off-by: Werner Koch <wk@gnupg.org>
CVE-id: CVE-2013-4576
* cipher/idea.c: New. Take from Libgcrypt master and adjust for
direct use in GnuPG.
* cipher/idea-stub.c: Remove.
* cipher/Makefile.am: Add idea.c and remove idea-stub.c rules.
* configure.ac: Remove idea-stub code.
* g10/gpg.c (check_permissions): Remove code path for ITEM==2.
(main): Make --load-extension a dummy option.
* g10/keygen.c (keygen_set_std_prefs): Include IDEA only in PGP2
compatibility mode.
* g10/misc.c (idea_cipher_warn): Remove. Also remove all callers.
* g10/seckey-cert.c (do_check): Remove emitting of STATUS_RSA_OR_IDEA.
* g10/status.c (get_status_string): Remove STATUS_RSA_OR_IDEA.
* g10/status.h (STATUS_RSA_OR_IDEA): Remove.
--
To keep the number of actually used algorithms low, we support IDEA
only in a basically read-only way (unless --pgp2 is used during key
generation). It does not make sense to suggest the use of this old 64
bit blocksize algorithm. However, there is old data available where
it might be helpful to have IDEA available.
* cipher/random.c (read_seed_file): Distinguish between errors and
short reads.
--
This should help to avoid program aborts due to races. Nevertheless a
better and cross-platform locking would be a more solid solution.
GnuPG-bug-id: 1439
* configure.ac (AH_BOTTOM): Add GNUPG_GCC_VERSION macro.
* util/estream-printf.c (pr_float): Use new gcc pragma to ignore a
warning about a non-literal format.
* util/miscutil.c (asctimestamp): Ditto.
* cipher/md.c (md_stop_debug): Use new gcc pragme to ignore a warning
* about a set but unused variable.
rather than '#ifdef' BIG_ENDIAN_HOST. Harmless as we explicitly
define BIG_ENDIAN_HOST to 1 when we need it, but needed for OSX fat
builds when we define BIG_ENDIAN_HOST to another macro.
Dario Niedermann