aboutsummaryrefslogtreecommitdiffstats
path: root/resource/help/docu_concepts.es.html
diff options
context:
space:
mode:
Diffstat (limited to 'resource/help/docu_concepts.es.html')
-rw-r--r--resource/help/docu_concepts.es.html122
1 files changed, 0 insertions, 122 deletions
diff --git a/resource/help/docu_concepts.es.html b/resource/help/docu_concepts.es.html
deleted file mode 100644
index 5657e90c..00000000
--- a/resource/help/docu_concepts.es.html
+++ /dev/null
@@ -1,122 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
-
-<head>
-<title>gpg4usb - Documentacion</title>
-<link rel="stylesheet" type="text/css" href="css/style.css" media="screen" />
-<link rel="stylesheet" type="text/css" href="css/print.css" media="print" />
-</head>
-
-<body>
-
-<div style="width:800px;text-align:center;float:center">
-<a href="docu.html">Principal</a> | Siguiente: <a href="docu_keygen.html">Generando una Llave</a>
-<hr/>
-
-<div id="content">
-
-<H2><A NAME="GPG-Minihowto-Concept"></A> <A NAME="s1">1.</A>Conceptos</H2>
-<H2><A NAME="ss1.1">1.1</A> Cifrado con LLave Publica
-</H2>
-<P>Los metodos clasicos de cifrado solo usan una llave para el cifrado. El
-remitente cifra el mensaje con esa llave. Para poder descifrarlo, el destinatario
-necesita tener esa misma llave. Esta llave se le debe dar al destinatario de forma
-que otras personas no puedan conseguirla. Si alguien consigue la llave, este metodo
-de cifrado es inutil.</P>
-<P>El uso de las llamadas LLaves Publicas puede resolver este problema. La LLave Publica
-es un concepto que utiliza dos llaves. Una llave es una LLave Publica que se puede
-difundir a traves de cualquier medio y que puede ser conseguida por cualquiera. La
-otra llave es la LLave Privada. Esta llave es secreta y no puede ser difundida. Esta
-llave solo esta disponible para el propietario que la ha creado. Cuando el sistema esta
-bien implementado, la llave secreta no puede averiguar desde la llave publica. Ahora,
-el remitente cifrara el mensaje con la llave publica del destinatario.
-El descifrado se hara con la llave secreta del destinatario.</P>
-<P>En este concepto, es crucial que la llave secreta permanezca secreta y no deberia
-darse o estar disponible para nadie, salvo el propietario de esta llave. NO ENVIE ESTA
-LLAVA POR INTERNET. También es muy aconsejable usar GnuPG con <CODE>telnet</CODE>
-(usted deberia considerar no usar nunca telnet debido a los altos riesgos de seguridadad).</P>
-<H2><A NAME="ss1.2">1.2</A> Firmas Digitales
-</H2>
-<P>Con el fin de probar que un mensaje ha sido realmente enviado por su remitente, se
-invento el concepto de Firmas Digitales. Como el nombre dice, un mensaje es firmado
-digitalmente por el remitente. Con esta firma, usted puede comprobar la autenticidad de
-un mensaje. Usando esto se reducira el riesgo de "Caballos de Troya" (un mensaje que dice ser
-un parche para un cierto problema pero que realmente contiene un virus o hace algo perjudicial
-para los datos en su computador). Tambien se pueden verificar informaciones o datos como
-procedentes de una fuente legitima y, de esta forma, pueden ser considerados como verdaderos.
-</P>
-<P>Una firma digital se hace a traves de una combinacion de la llave secreta y el texto. Usando
-la llave publica del remitente, se puede verificar el mensaje. No solo se podra comprobar si
-procede del remitente correcto sino tambien el texto enviado. Asi, usted sabe que el mensaje
-viene de su remitente y que no ha sido modificado durante el proceso de envio.
-</P>
-<H2><A NAME="ss1.3">1.3</A> Red de Confianza
-</H2>
-<P>Un punto debil de los algoritmos tipo Llave Publica es la difusion de las llaves publicas.
-Un usuario podria poner en circulacion una llave publica con una falsa ID de usuario. Si se
-escriben mensajes con esta llave particular, el intruso puede descifrar y leer esos mensajes.
-Si el intruso pasa despues ese mensaje codificado con una llave publica genuina al destinatario
-real, este ataque pasaria desapercibido.</P>
-<P>La solucion PGP (y por tanto la solucion GnuPG) estriba en firmar las llaves. Una llave
-publica puede ser firmada por otra persona. Esta firma asegura que la llave usada por el UID
-(Identificacion de Usuario) realmente pertenece a la persona que dice ser. Le corresponde
-entonces al usuario del GnuPG establecer en que medida confia en esa firma. Usted puede
-considerar una llave totalmente fiable cuando usted confia en el remitente de la llave y sabe con
-seguridad que la llave realmente pertenece a esa persona. Solo cuando usted confia en la llave
-del firmante, usted puede confiar en la firma. Para estar absolutamente seguros de que la llave
-es correcta, usted tiene que comparar la huella digital por medio de canales seguros antes de
-otorgar una certeza absoluta..</P>
-<H2><A NAME="ss1.4">1.4</A> Limites de la Seguridad
-</H2>
-<P>Si usted tiene datos que le gustaria que permanecieran confidenciales, esto es algo mas que
-simplemente determinar que algoritmo de cifrado hay que usar. Usted deberia pensar en su sistema
-de seguridad en general. Basicamente, consideramos que el PGP es seguro y, cuando escribo este
-documento, no se conocen casos de ruptura del PGP. Pero eso no significa que todo su cifrado
-sea seguro (por ejemplo, la NSA no me notificaria si ellos han crakeado alguna vez el PGP, ni
-tampoco otras personas que lo hayan hecho por motivos maliciosos). Pero, aun en el caso de que
-el PGP sea totalmente "inhackeable", se pueden usar otros medios para atacar la seguridad. A
-primeros de Febrero de 1999, se habia encontrado un "Caballo de Troya" que buscaba llaves secretas
-PGP en el disco duro y las enviaba fuera por FTP. Si la password se ha escogido mal, la llave
-secreta se puede descifrar facilmente.</P>
-<P>Otra posibilidad tecnica (aunque mas dificil) de ruptura PGP es un "Caballo de Troya" que copie
-las pulsaciones del teclado. Tambien es posible (pero muy dificil) copiar el contenido de una
-pantalla. En estos casos, no es necesario romper el codigo de mensajes cifrados. Por todos estos
-riesgos, se necesita tener un buen y bien pensado plan de seguridad que se ponga en practica..</P>
-<P>No se trata de crear una paranoia entre la gente, sino mostrar que hay que hacer mucho para
-ser mas seguro. Lo mas importante es darse cuenta de que el cifrado es solo un paso de seguridad y
-no la solucion total. Los "Caballos de Troya" que aparecieron en 1999 en los virus "Melissa"
-demostraron que la mayoria de las empresas no estaban preparadas para esto.</P>
-
-<hr>
-
-<p>
-Renuncia de responsabilidad: el original de este capitulo esta en <a href="http://www.gnupg.org/documentation/howtos.html">GnuPG MiniHOWTO</a>
-</p>
-<p>
-Copyright © 1999 Brenno J.S.A.A.F. de Winter (version inglesa) Copyright © 1999
-Michael Fischer v. Mollard (version original alemana) Copyright © 2002 Arjen Baart
-(version holandesa) Copyright © 2004 Baris Cicek (version turca)
-</p><p>
-Este documento es una documentacion libre y usted puede distribuirla y/o modificarla bajo
-los terminos de la GNU Library General Public License, tal como la publica la Free Software
-Foundation; tanto en su version 2 de Licencia o (en su opinion) cualquier version
-posterior.
-</p><p>
-Esta libreria se distribuye con la esperanza de que sera util, pero SIN NINGUNA GARANTIA;
-incluso sin la garantia implicita de COMERCIALIZACION o IDONEIDAD PARA UN PROPOSITO PARTICULAR.
-Vea la GNU Library General Public License para mas detalles.
-</p><p>
-Usted deberia haber recibido una copia de la GNU Library General Public License junto con esta
-libreria; si no la tiene, escriba a la Free Software Foundation, Inc., 59 Temple Place
-- Suite 330, Boston, MA 02111-1307, USA.
-</p>
-</hr>
-
-</div>
-<hr/>
-<a href="docu.html">Principal</a> | Siguiente: <a href="docu_keygen.html">Generando una Llave</a>
-</div>
-</body>
-</html>
-