Cambios en el paquete gnupg2 de Debian Jessie

vie 16 enero 2015
Por Javier Cantero

En Debian.

etiq.: gnupg

Ayer entró en Debian Jessie la versión 2.0.26-4 del paquete gnupg2 y, mirando el changelog me dí cuenta que no era una mera versión para corregir algún bug de última hora, sino que parecía contener importantes cambios a tener en cuenta. En concreto esta era la entrada del changelog que me llamó la atención (eliminando la parte referente a las traducciones que no nos importan):

gnupg2 (2.0.26-4) unstable; urgency=medium

  ...

  [ Daniel Kahn Gillmor ]
  * bugfix and cryptographic safety changes imported from upstream:
   - Avoid regression when adding subkeys with strong s2k algorithms
     (Closes: #772780) Thanks, NIIBE Yutaka
   - Allow french translation to work when prompting for passphrase.
   - add build and runtime support for larger RSA keys (Closes: #739424)
   - fix runtime errors on bad input (Closes: #771987)
   - deprecate insecure one-argument variant for gpg --verify of detached
     signatures (Closes: #771992)
   - initialize trustdb before trying to clear it (Closes: #735363)
   - default to issuing SHA256 signatures for RSA
   - avoid relying on MD5 signatures
   - show v3 key fingerprints as all zero (OpenPGPv3 is deprecated)

 -- Daniel Kahn Gillmor <dkg@fifthhorseman.net>  Sun, 04 Jan 2015 17:17:00 -0500

En concreto las que me llamaron la atención fueron éstas:

  • Soporte para claves RSA grandes (>4096 bits)
  • Por defecto las signaturas se realizarán con SHA256 para RSA
  • Descontinuada la versión de gpg --verify con un único argumento

Veamos qué significa cada una de ellas.

Soporte para claves RSA grandes (>4096 bits)

Si intentáis generar una clave RSA, os pide un tamaño de clave entre 1024 y 4096 bits. Dado que no hay que usar claves RSA de 1024 bits o menos, y que lo recomendable hoy en día es usar 4096, no es tan descabellado que alguno se haya generado o quiera generarse una clave con más de 4096 bits. El cambio en cuestión dice lo siguiente:

Some older implementations built and used RSA keys up to 16Kib, but
the larger secret keys now fail when used by more recent GnuPG, due to
secure memory limitations.

Building with ./configure --enable-large-secmem will make gpg
capable of working with those secret keys, as well as permitting the
use of a new gpg option --enable-large-rsa, which let gpg generate RSA
keys up to 8Kib when used with --batch --gen-key.

Es decir, podemos manejar claves antiguas de hasta 16384 bits, e incluso generarnos una clave propia de hasta 8192 bits usando el comando gpg2 --enable-large-rsa --batch --gen-key. Por desgracia, esta opción no funciona cuando generamos interactivamente la clave (supongo que porque no quieren promocionar activamente el uso de claves tan disparatadamente grandes ahora que el salto a ECC está cerca).

Signaturas RSA con SHA256

Si habéis leído y aplicado las recomendaciones descritas en OpenPGP Best Practices, este cambio no os afecta, puesto que ya tenéis configurada esa opción (o una incluso mejor). Si no, esta versión lo empezará a aplicar ella misma por defecto.

gpg --verify con un único argumento

A primera vista me había mosqueado que descontinuaran esta opción, ya que se usa habitual y abundantemente para comprobar todo tipo de ficheros. Pero es que hay que leer la "letra pequeña", Javier:

Allowing to use the abbreviated form for detached signatures is a long
standing bug which has only been noticed by the public with the
release of 2.1.0.  :-(

What we do is to remove the ability to check detached signature in
--batch using the one file abbreviated mode.  This should exhibit
problems in scripts which use this insecure practice.  We also print a
warning if a matching data file exists but was not considered because
the detached signature was actually a standard signature:

  gpgv: Good signature from "Werner Koch (dist sig)"
  gpgv: WARNING: not a detached signature; \
  file 'gnupg-2.1.0.tar.bz2' was NOT verified!

We can only print a warning because it is possible that a standard
signature is indeed to be verified but by coincidence a file with a
matching name is stored alongside the standard signature.

Es un cambio que sólo afecta a operaciones automatizadas/scripts que usen --batch, así que realmente es un cambio menor que no creo que afecte a casi nadie.

:wq

blogroll

social