From wmeikle en telematica.com.uy Tue Jan 29 22:09:09 2008 From: wmeikle en telematica.com.uy (William Meikle) Date: Tue, 29 Jan 2008 18:09:09 -0300 Subject: gpg pgp gpgsm openssl Message-ID: Buenas para todos ! Despues de haber echo una gran cantidad de pruebas en base a la documentación encontrada en todos lados, recurro a esta lista como la ultima de mis posibilidades. Lo que me estan pidiendo que haga es generacion de certificados p12 con las claves pub/pri a través de openssl; pero ademas requiero poder importar esas claves en pgp y/o gpg. si importo el p12 desde pgp 6.5.8 de windows no tengo problemas y puedo obtener a partir del p12 las claves. pero no he logrado hacer esa importacion en gpg de linux. Desde ya muchas gracias por su tiempo. ----------------------------------- William Meikle Telemática S.R.L. Eduardo Acevedo 1622 Tel./Fax: (598)2 408 2837 - 024596 ----------------------------------- Si este mensaje responde una consulta técnica, la solución propuesta no debe ser considerada como única ni descartar otras soluciones alternativas a su problema. From daniel.banobre.dopico en gmail.com Wed Jan 30 13:45:51 2008 From: daniel.banobre.dopico en gmail.com (Daniel =?ISO-8859-1?Q?Ba=F1obre?= Dopico) Date: Wed, 30 Jan 2008 13:45:51 +0100 Subject: Riesgos de cifrar una clave =?ISO-8859-1?Q?p=FAblica?= Message-ID: <1201697151.5897.16.camel@melucos> Estoy empezando a trabajar en un proyecto que emplearía GnuPG para realizar diálogos http cifrados de forma transparente al usuario. Nada que ver con S-HTTP. Se implementaría a nivel de aplicación web en el lado del servidor y el soporte a los navegadores se proporcionaría mediante plugins o complementos. La idea es ofrecer una alternativa a http sobre ssl a nivel de transmisión de peticiones y ficheros. Parte de la idea original implica el envio recíproco de las claves públicas por medio de diferentes canales. Este paso es delicado pues, de no establecerse medios para evitarlo, resulta vulnerable a un ataque de M'n'M con spoofing de claves. En este momento estoy intentando diseñar el/los mecanismos que dificulten este ataque. He de proteger el intercambio de claves entre las dos partes de la comunicación. Si consigo que la primera clave se entregue por un canal seguro, la segunda clave podría viajar ya encriptada y firmada, de forma que no sería interceptable. Mi duda es: en principio, cifrar un documento públicamente conocido, cuanto más largo, supone un riesgo a nivel de que proporciona muchos datos que podrían facilitar el ataque a la clave privada por parte de terceros. La clave pública que se intercambia entre las dos partes de la comunicación es, por definición, pública, con lo que hacerla viajar de forma cifrada podría suponer un riesgo para la confidencialidad de la clave privada de la parte que cifra, especialmente si se trata del servidor web. ¿Hasta qué punto es GnuPG sensible a este tipo de problemas?. ¿Merece la pena considerar este hecho o el cifrado que ofrece GnuPG está exento de este riesgo?. Gracias por su tiempo y su esfuerzo. -- Daniel Bañobre Dopico _o) GNU/Linux num. 416887 /\\ http://counter.li.org \_V ------------ próxima parte ------------ A non-text attachment was scrubbed... Name: no disponible Type: application/pgp-signature Size: 189 bytes Desc: Esta·é·unha·parte·de·mensaxe·asinada·dixitalmente URL: From sergi en calcurco.cat Wed Jan 30 15:14:04 2008 From: sergi en calcurco.cat (Sergi Blanch i =?utf-8?q?Torn=C3=A9?=) Date: Wed, 30 Jan 2008 15:14:04 +0100 Subject: Riesgos de cifrar una clave =?utf-8?q?p=C3=BAblica?= In-Reply-To: <1201697151.5897.16.camel@melucos> References: <1201697151.5897.16.camel@melucos> Message-ID: <200801301514.16160.sergi@calcurco.cat> On Wednesday 30 January 2008 13:45:51 Daniel Bañobre Dopico wrote: > Estoy empezando a trabajar en un proyecto que emplearía GnuPG para > realizar diálogos http cifrados de forma transparente al usuario. Nada > que ver con S-HTTP. Se implementaría a nivel de aplicación web en el > lado del servidor y el soporte a los navegadores se proporcionaría > mediante plugins o complementos. La idea es ofrecer una alternativa a > http sobre ssl a nivel de transmisión de peticiones y ficheros. > > Parte de la idea original implica el envio recíproco de las claves > públicas por medio de diferentes canales. Este paso es delicado pues, de > no establecerse medios para evitarlo, resulta vulnerable a un ataque de > M'n'M con spoofing de claves. > > En este momento estoy intentando diseñar el/los mecanismos que > dificulten este ataque. He de proteger el intercambio de claves entre > las dos partes de la comunicación. Si consigo que la primera clave se > entregue por un canal seguro, la segunda clave podría viajar ya > encriptada y firmada, de forma que no sería interceptable. La segunda clave pública, con que vaya firmada por la clave privada de la primera habrá suficiente (no hace falta cifrar, es pública). Después con la clave pública que dices enviar por un canal seguro verificarías esa firma y sabrías que no proviene de otro. Lo que no veo es como quieres enviar la primera clave. Y lo de siempre, sí tienes un canal seguro, para que quieres el resto. > Mi duda es: en principio, cifrar un documento públicamente conocido, > cuanto más largo, supone un riesgo a nivel de que proporciona muchos > datos que podrían facilitar el ataque a la clave privada por parte de > terceros. La clave pública que se intercambia entre las dos partes de la > comunicación es, por definición, pública, con lo que hacerla viajar de > forma cifrada podría suponer un riesgo para la confidencialidad de la > clave privada de la parte que cifra, especialmente si se trata del > servidor web. ¿Hasta qué punto es GnuPG sensible a este tipo de > problemas?. ¿Merece la pena considerar este hecho o el cifrado que > ofrece GnuPG está exento de este riesgo?. Creo que no entiendo tu idea. Debes tener en cuenta que en prácticamente todos los programas de cifrado se usan sistemas híbridos. El texto largo que quieres cifrar, será cifrado por un sistema simétrico (AES256 por ejemplo) y esa clave simétrica es la que será cifrada con la clave pública (que es asimétrica). Luego el destinatario recibirá todo empaquetado, recuperará la clave simétrica con su clave secreta y recuperará tu documento largo. Visto así, el texto plano cifrado por sistema asimétrico siempre es corto. Y es a partir de esto que me hago un lío con lo que quieres hacer. Enviar la clave pública sin cifrar, es lo normal, por ejemplo cuando la subes a un servidor de claves. Lo no muy habitual sería cifrarla, ¿no? /Sergi. ------------ próxima parte ------------ A non-text attachment was scrubbed... Name: no disponible Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From daniel.banobre.dopico en gmail.com Thu Jan 31 10:42:12 2008 From: daniel.banobre.dopico en gmail.com (=?ISO-8859-1?Q?Daniel_Ba=F1obre_Dopico?=) Date: Thu, 31 Jan 2008 10:42:12 +0100 Subject: =?ISO-8859-1?Q?Re:_Riesgos_de_cifrar_una_clave_p=FAblica?= In-Reply-To: <200801301514.16160.sergi@calcurco.cat> References: <1201697151.5897.16.camel@melucos> <200801301514.16160.sergi@calcurco.cat> Message-ID: <38ced3890801310142i6f9bd11dp460bd1da9af89d4d@mail.gmail.com> El día 30/01/08, Sergi Blanch i Torné escribió: > > On Wednesday 30 January 2008 13:45:51 Daniel Bañobre Dopico wrote: > > Estoy empezando a trabajar en un proyecto que emplearía GnuPG para > > realizar diálogos http cifrados de forma transparente al usuario. Nada > > que ver con S-HTTP. Se implementaría a nivel de aplicación web en el > > lado del servidor y el soporte a los navegadores se proporcionaría > > mediante plugins o complementos. La idea es ofrecer una alternativa a > > http sobre ssl a nivel de transmisión de peticiones y ficheros. > [...] Dame unos dias para responder a tu correo. Ando liado y necesito hacer unos esquemas y plantear de forma adecuada lo que planeo hacer para que sea fácilmente comprensible y quede claro. Gracias por tu respuesta. ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From sergi en calcurco.cat Thu Jan 31 11:49:54 2008 From: sergi en calcurco.cat (Sergi Blanch i =?iso-8859-1?q?Torn=E9?=) Date: Thu, 31 Jan 2008 11:49:54 +0100 Subject: gpg pgp gpgsm openssl In-Reply-To: References: Message-ID: <200801311150.06220.sergi@calcurco.cat> Hola, Veo que nadie ha respondido a tu pregunta a la lista en castellano. No se si deberías llevar tu consulta a la lista de usuarios en inglés. Lo único que se me ocurre es preguntarte que versión del gpg utilizas y que comandos utilizas tanto para generar desde openssl hasta como no consigues importar en el gpg. /Sergi. On Tuesday 29 January 2008 22:09:09 you wrote: > Buenas para todos ! > > Despues de haber echo una gran cantidad de pruebas en base a la > documentación encontrada en todos lados, recurro a esta lista como la > ultima de mis posibilidades. > > Lo que me estan pidiendo que haga es generacion de certificados p12 con las > claves pub/pri a través de openssl; pero ademas requiero poder importar > esas claves en pgp y/o gpg. si importo el p12 desde pgp 6.5.8 de windows no > tengo problemas y puedo obtener a partir del p12 las claves. pero no he > logrado hacer esa importacion en gpg de linux. > > Desde ya muchas gracias por su tiempo. > ----------------------------------- > William Meikle > Telemática S.R.L. > Eduardo Acevedo 1622 > Tel./Fax: (598)2 408 2837 - 024596 > ----------------------------------- > Si este mensaje responde una consulta técnica, la > solución propuesta no debe ser considerada como única ni descartar otras > soluciones alternativas a su problema. > > > _______________________________________________ > Gnupg-es mailing list > Gnupg-es en gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-es ------------ próxima parte ------------ A non-text attachment was scrubbed... Name: no disponible Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From wmeikle en telematica.com.uy Thu Jan 31 14:24:44 2008 From: wmeikle en telematica.com.uy (William Meikle) Date: Thu, 31 Jan 2008 10:24:44 -0300 Subject: gpg pgp gpgsm openssl Message-ID: Se ha borrado un adjunto en formato HTML... URL: ------------ próxima parte ------------ A non-text attachment was scrubbed... Name: signature.asc Type: application/octet-stream Size: 213 bytes Desc: no disponible URL: