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