/usr/share/doc/gnupg-doc/GNU_Privacy_Handbook/es/html/c511.htm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Uso diario de GnuPG</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="Guía de ``GNU Privacy Guard''"
HREF="book1.htm"><LINK
REL="PREVIOUS"
TITLE="Distribución de claves"
HREF="x487.htm"><LINK
REL="NEXT"
TITLE="Construcción del anillo de confianza"
HREF="x577.htm"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Guía de ``GNU Privacy Guard''</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x487.htm"
ACCESSKEY="P"
>Anterior</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x577.htm"
ACCESSKEY="N"
>Siguiente</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="WISE"
></A
>Capítulo 4. Uso diario de GnuPG</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Tabla de contenidos</B
></DT
><DT
><A
HREF="c511.htm#AEN517"
>Definiendo los requerimientos en seguridad</A
></DT
><DT
><A
HREF="x577.htm"
>Construcción del anillo de confianza</A
></DT
><DT
><A
HREF="x588.htm"
>Uso legal de GnuPG</A
></DT
></DL
></DIV
><P
>GnuPG es una compleja herramienta que no está exenta de polémica técnica,
social y legal.
En el plano técnico, ha sido diseñada para su uso en situaciones con diversos
requerimientos de seguridad.
Esto complica la gestión de claves.
En el plano social, el uso de GnuPG no es estricatamente una decisión de
tipo personal.
Para que su uso tenga efectividad, GnuPG requiere que todas las partes en
una comunicación sean usuarios del programa.
En el plano legal, desde 1.999, las leyes que contemplan el uso de productos
informáticos criptológicos, y en particular si el uso de GnuPG es legal,
son diferentes según los países y están siendo actualmente debatidas por
muchos gobiernos.</P
><P
>Este capítulo tratará sobre estos temas.
Se intentará dar consejos prácticos sobre el uso de GnuPG de cara a los
requerimientos de seguridad del usuario.
También se sugerirán vías para promocionar el uso de GnuPG con vistas a la
comunicación segura entre el usuario y las personas con las que éste se
comunique, aun cuando éstos no sean usuarios de GnuPG.
Finalmente, se resaltará el estado legal de GnuPG conforme con el estado
actual de las leyes sobre criptología y cifrado en el mundo.</P
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN517"
>Definiendo los requerimientos en seguridad</A
></H1
><P
>GnuPG es una herramienta que utiliza el usuario para proteger su
privacidad.
La protección existe sólo si el usuario puede comunicarse con otros sin
«escuchas» que puedan leer los mensajes.</P
><P
>El modo en que se deba usar GnuPG dependerá de la determinación y de los
recursos de aquéllos que intenten, o puedan intentar, leer los mensajes
cifrados del usuario.
Un «escucha» podría ser un administrador de sistemas sin
escrúpulos, que se encuentre, «por casualidad», escaneando el
correo del usuario, o podría ser un espía industrial que intentara acceder a
los secretos de una compañía, o incluso podría ser un organismo legal que
quisiera llevarnos a juicio.
El uso de GnuPG para protegernos contra «intromisiones
casuales», será diferente de su uso para protegernos contra un
adversario determinado.
Nuestro fin último debe ser el de que el conseguir los datos no cifrados
resulte más caro que el valor de los datos en sí.</P
><P
>La personalización del uso de GnuPG se basa en los siguientes aspectos:
<P
></P
><UL
COMPACT="COMPACT"
><LI
><P
>la elección del tamaño del par de claves público y privado.</P
></LI
><LI
><P
>la protección de la clave privada,</P
></LI
><LI
><P
>la selección de la fecha de caducidad y el uso de subclaves, y</P
></LI
><LI
><P
>la gestión del anillo de confianza.</P
></LI
></UL
>

Una buena elección del tamaño de la clave nos protegerá contra ataques de
fuerza bruta en los mensajes cifrados.
La protección de nuestra clave privada ayudará a prevenir que un atacante
pueda llegar a usarla para descifrar mensajes o firmar mensajes en nuestro
nombre.
Una gestión correcta de nuestro anillo de confianza, ayudará a evitar que
cualquier atacante pueda hacerse pasar por una persona de nuestra confianza.
La consecución de estos aspectos según las necesidades de nuestra propia
seguiridad, es el modo de equilibrar el trabajo extra que se requiere para
usar GnuPG con la privacidad que ofrece.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN531"
>Selección del tamaño de la clave</A
></H2
><P
>La selección del tamaño de la clave depende de la clave en sí.
En OpenPGP, un par de claves pública y privada contienen generaralmente
claves múltiples.
Como mínimo tiene una clave de firmado maestra, y probablemente una o más
subclaves de cifrado adicionales.
Si usamos para la generación de claves los parámetros por defecto en GnuPG,
la clave maestra será una clave DSA, y las subclaves serán claves ElGamal.</P
><P
>DSA nos permite un tamaño de clave de hasta 1024 bits.
Dada la tecnología de factorización de hoy en día, esto no es demasiado
bueno, pero es lo que especifica el estándar.
Sin duda alguna, debemos usar claves DSA de 1024 bits.</P
><P
>Por otra parte, las claves ElGamal pueden ser de cualquier tamaño.
Ya que GnuPG es un sistema de clave pública híbrido, la clave pública se
usa para cifrar una clave de sesión de 128 bits, y la clave privada se usa
para descifrarla.
Sin embargo el tamaño de la clave afecta a la velocidad del cifrado y
descifrado, ya que el valor de estos algoritmos lleva como exponente el
tamaño de la clave.
Una clave de mayor tamaño también tarda más en ser generada, y ocupa más
espacio.
Además, cuanto mayor tamaño tenga una clave, la seguridad extra que nos
ofrece, aumenta pero con una marcha decreciente.
También hay que tener en cuenta que un «escucha» que se encuentre
con una clave lo suficientemente grande como para resistir un ataque de
fuerza bruta, se limitará a cambiar de método para poder obtener los datos no
cifrados.
Por lo tanto, 1024 bits es el tamaño de clave recomendado.
Si nuestros requerimientos de seguridad fueran tan grandes como para
necesitar claves de gran tamaño, entonces deberíamos consultar a un experto
en seguridad de datos.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN536"
>Protección de la clave privada</A
></H2
><P
>La protección de la clave privada es la parte más importante en el uso de
GnuPG.
Si alguien obtuviera nuestra clave privada, todos los datos que hubieran sido
cifrados para esa clave podrían ser descifrados y se podría firmar documentos
bajo nuestro nombre.
Si perdiéramos la clave privada, ya no podríamos descifrar los documentos
cifrados que nos hubieran enviado o que nos enviaran en un futuro, y no
podríamos firmar los documentos.
La pérdida de posesión de nuestra clave privada podría ser una catástofre.</P
><P
>Sea cual fuere el uso que hagamos de GnuPG, deberíamos guardar siempre un
<A
HREF="c14.htm#REVOCATION"
>certificado de revocación</A
> de nuestras
claves públicas, y una copia de seguridad de nuestra clave privada en un
disco protegido contra la escritura, y en un lugar seguro.
Por ejemplo, podríamos grabarlo en un CD-ROM y guardar éste en un cofre de
depósito de un banco, dentro de un sobre sellado.
Alternativamente, podríamos guardarlo en un disquete y esconderlo en nuestra
casa.
Hagamos lo que hagamos, los certificados de revocación de las claves
públicas y las copias de seguridad de la clave privada deberíamos tenerlos
guardados en un medio lo suficientemente seguro, mucho más que la clave
privada que utilizamos a diario.</P
><P
>Como medida de seguridad, GnuPG no guarda nuestra clave privada «en
bruto» en el disco duro, sino que la cifra mediante un algoritmo de
cifrado simétrico.
Por esta razón, para acceder a nuestra clave, necesitamos una contraseña.
Por lo tanto, existen dos barreras que un atacante debe cruzar para poder
acceder a nuestra clave privada:  (1) debe conseguir la clave;  (2) debe
ser capaz de descifrarla.</P
><P
>Esconder nuestra clave privada en un sitio seguro es importante, pero todo
tiene un precio.
Lo ideal sería que guardáramos la clave en un disco que fuera portátil y que
tuviera protección contra la escritura, como un disquete, y que sólo lo
usáramos en una máquina con un solo usuario que no estuviera conectada a una
red.
Esto puede que no sea convenient o posible para nosotros.
Por ejemplo, es posible que no tengamos nuestra propia máquina, y que debamos
usar la de la universidad o la de la oficina, o puede significar que para
ello tengamos que desconectar el modem cada vez que queramos usar GnuPG.</P
><P
>Esto no quiere decir que no podamos o no debamos usar GnuPG.
Tan sólo significa que debemos decidir si los datos que estamos protegiendo
son lo suficientemente importantes para cifrarlos, pero no tan importantes
como para tomar medidas extra de seguridad.
La elección es nuestra.</P
><P
>Una buena contraseña es absolutamente crítica para el uso de GnuPG.
Cualquier atacante que logre acceder a nuestra clave privada, deberá
sobrepasar el cifrado de nuestra clave privada.
En lugar de usar un ataque de fuerza bruta, es casi seguro que un
atacante intentará adivinar la contraseña.</P
><P
>El motivo por el que intentaría adivinarla, es que la mayoría de personas
escogen contraseñas que son más fáciles de adivinar que de sobrepasar una
clave aleatoria de 128 bits.
Si la contraseña es una palabra ("password"), es mucho más fácil
probar con todas las palabras existentes en los diccionarios de todas las
lenguas del mundo.
Aun cuando la palabra sea permutada, v.g. k3wldood, será más fácil probar
palabras de diccionario con un catálogo de permutaciones.
Lo mismo ocurre con las citas.
Aunque sea una contraseña formada por frases ("passphrase"), si
ésta tiene como base un lenguaje natural, será una contraseña débil, ya que
existirá poca aleatoriedad y muchas redundancias.
Si es posible, debemos evitar contraseñas basadas en lenguajes naturales.</P
><P
>Una buena contraseña es aquélla que podemos recordar, pero que es difícli que
otro pueda adivinar.
Debería incluir todos los carácteres imprimibles de nuestro teclado posibles.
Esto incluye carácteres alfabéticos en mayúsculas y minúsculas, números, y
carácteres especiales como <TT
CLASS="LITERAL"
>&rcub;</TT
> o
<TT
CLASS="LITERAL"
>&brvbar;</TT
>.
Debemos ser creativos y perder un poco de tiempo inventando una contraseña;
una buena elección es importante para asegurar nuestra privacidad.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN549"
>Selección de las fechas de caducidad y uso de subclaves</A
></H2
><P
>Por defecto, una clave de firmado maestra DSA y una subclave de cifrado
ElGamal son generadas al crear un nuevo par de claves.
Esto es conveniente porque cada clave juega un papel diferente, y por lo
tanto es posible que necesitemos que las claves tengan fechas de caducidad
diferentes.
La clave de firmado maestra se usa para las firmas digitales, y también
recolectan las firmas de otras personas que hayan confirmado nuestra
identidad.
La clave de cifrado se usa sólo para descifrar los documentos cifrados que
nos hayan enviado.
Por lo general, una firma digital tiene una larga vida, v.g., para siempre, y
tampoco queremos perder las firmas que tanto nos ha costado recolectar en
nuestra clave.
Por otra parte, la subclave de cifrado puede cambiar periódicamente por
cuestiones de seguridad, ya que si una clave de cifrado es descifrada, el
atacante puede leer todos los documentos que sean cifrados para esa clave.</P
><P
>Suele ocurrir que no queramos que nuestra clave maestra caduque.
Existen dos razones por las que debamos escoger una fecha de caducidad.
La primera es que tengamos la intención de que la clave tenga una vida
limitada.
Por ejemplo, si la usamos para una campaña política y no nos será útil una
vez pasada la campaña.
La segunda es que si perdemos el control de la clave, y no tenemos un
certificado de revocación con el que revocarla, una fecha de caducidad sobre
la clave maestra asegura que la clave caerá finalmente en desuso.</P
><P
>Cambiar las subclaves de cifrado puede ser sencillo, pero puede que no sea
del todo conveniente.
Si generamos un nuevo par de claves con una fecha de caducidad en la
subclave, ésta caducará en su momento.
Poco antes de la caducidad añadiremos una nueva subclave y publicaremos
nuestra clave pública actualizada.
Una vez que la subclave haya caducado, aquellos que deseen comunicarse con
nosotros deberán encontrar antes la clave actualizada, pues ya no podrán
enviar datos cifrados para esa clave.
El inconveniente depende de cómo distribuyamos la clave.
Por fortuna, no es necesario firmas extras ya que la nueva clave habrá sido
firmada con con nuestra clave de firmado maestra, la cual ya había sido
validada por nuestros corresponsales.</P
><P
>Todo depende de que queramos o no tener una seguridad extra.
Al igual que nosotros, un atacante todavía podrá leer todos los documentos
que hayan sido cifrados para una clave caducada.
Cambiar las subclaves sólo protege los futuros documentos.
Para poder leer documentos cifrados para la nueva subclave, el atacante
necesitaría organizar un nuevo ataque, usando cualquier técnica que hubiera
usado la primera vez.</P
><P
>Al final sólo tiene sentido tener una sola subclave de cifrado en un anillo
de claves.
No hay se gana seguridad adicional teniendo dos o más subclaves activas.
Por supuesto, puede existir cualquier número de claves caducadas en un anillo
de claves, para que los datos que hubieran sido cifrados en el pasado puedan
todavía ser descifrados, pero sólo es necesario activar una sola subclave en
un momento dado.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN556"
>Gestión del anillo de confianza</A
></H2
><P
>Al igual que con la protección de nuestra clave privada, la gestión de
nuestro anillo de confianza es otro aspecto del uso de GnuPG que requiere
equilibrar la seguridad y la facilidad de uso.
Si estamos usando GnuPG para protegernos contra la posibilidad de una
simple interceptación casual o de una falsificación, entonces nos podemos
permitir ser algo confiados con las firmas de otros.
Si, por el contrario, nos preocupa que pueda haber un atacante determinado
interesado en invadir nuestra privacidad, entonces deberíamos confiar mucho
menos en otras firmas, e invertir más tiempo en verificarlas.</P
><P
>Aparte de nuestras propias necesidades de seguridad, deberíamos tener
<I
CLASS="EMPHASIS"
>siempre cuidado</I
> al firmar las claves de otras personas.
Firmar una clave sin el suficiente grado de confianza en la validez de la
clave, sólo para satisfacer nuestras propias necesidades de seguridad, es una
actitud egoísta.
Otros, con otras necesidades de seguridad más grandes, podrían fiarse de
una clave que llevara nuestra firma.
Si no pueden confiar en nosotros, entonces se debilita el anillo de confianza
y se hace más difícil la comunicación para todos los usuarios de GnuPG.
Así pues, debemos poner el mismo cuidado al firmar una clave que el que nos
gustaría que pusieran otras personas cuando dependamos de sus firmas.</P
><P
>En la práctica, la gestión de nuestro anillo de claves evita el tener que
ajustar las opciones
<CODE
CLASS="OPTION"
>--marginals-needed</CODE
>
y 
<CODE
CLASS="OPTION"
>--completes-needed</CODE
>.
Cualquier clave que firmemos personalmente será considerada válida, pero con
la excepción de grupos reducidos, no es práctico firmar la clave de cada
persona con la que nos comuniquemos.
Por lo tanto, tendremos que dejar que otros asignen el nivel de confianza.</P
><P
>Es aconsejable ser precisos cuando asignemos el nivel de confianza y cuando
usemos las opciones para configurar el cuidado con que GnuPG debe ir con la
validación de claves.
Por ejemplo, es posible que tengamos plena confianza con unos pocos amigos
íntimos, que sabemos que serán lo suficientemente cuidadosos cuando firmen
una clave, y que otorguemos un nivel de confianza marginal al resto en
nuestro anillo de claves.
Desde esta perspectiva, podemos tener <CODE
CLASS="OPTION"
>--completes-needed</CODE
>
como <TT
CLASS="LITERAL"
>1</TT
> y <CODE
CLASS="OPTION"
>--marginals-needed</CODE
> como
<TT
CLASS="LITERAL"
>2</TT
>.
Si estuviéramos más preocupados por la seguridad, podríamos escoger valores
de <TT
CLASS="LITERAL"
>1</TT
> y <TT
CLASS="LITERAL"
>3</TT
>, o <TT
CLASS="LITERAL"
>2</TT
> y
<TT
CLASS="LITERAL"
>3</TT
> respectivamente.
Pero si no estamos tan preocupados por los posibles ataques sobre la
privacidad, y simplemente queremos una fiabilidad razonable sobre la validez,
escogeremos los valores <TT
CLASS="LITERAL"
>1</TT
> y <TT
CLASS="LITERAL"
>1</TT
>.
Por regla general, los números más altos para estas opciones suponen que
sería necesario que hubiera más gente conspirando contra nosotros para poder
validar una clave que no pertenezca a la persona que nosotros creemos.</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x487.htm"
ACCESSKEY="P"
>Anterior</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
ACCESSKEY="H"
>Inicio</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x577.htm"
ACCESSKEY="N"
>Siguiente</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Distribución de claves</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Construcción del anillo de confianza</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
gnupg-doc 2003.04.06+dak1-1ubuntu1 / usr / share / doc / gnupg-doc / GNU_Privacy_Handbook / es / html / c511.htm
