Hace pocas horas Mozilla ha liberado una nueva versión de Firefox en la que destacan la integración con GTK3 en Linux, mejoras en las seguridad del compilador JS en tiempo real, cambios en WebRTC y nuevas funcionalidades para Android e iOS.

Después de varios meses de pruebas y desarrollo, finalmente GTK3 ha sido incluido para la versión en Linux. Esto permitirá reducir la dependencia de las versiones antiguas del servidor X11, compatibilidad mejorada con HiDPI y sobre todo una mejor integración con los temas.

 El nuevo navegador también mejora la seguridad del compilador de JavaScript Just in Time (JIT) de SpiderMonkey. La idea es influir en el código RWX (lectura – escritura – ejecución), que a veces provoca un riesgo. Inicialmente representa una excepción a las reglas del sistema operativo, especialmente el almacenamiento de datos en un área de memoria donde pueden ser ejecutados (leer), pero no escribirse.

Para remediar este problema, Mozilla he empleado un mecanismo denominado W^X. Su función es la de prohibir la escritura de JavaScript en áreas de memoria que contienen el código JIT. Este cambio será a expensas de un ligero descenso en el rendimiento, que se calcula de acuerdo con el editor en un rango de 1% a 4%. Por otra parte, se invita a los creadores de algunas extensiones para probar la compatibilidad de su código de tratar con este mecanismo.

También se ha mejorado el rendimiento y la fiabilidad de las conexiones de WebRTC, y permite el uso del módulo de descifrado de contenido para el contenido H.264 y AAC cuando sea posible. Mientras tanto, para los desarrolladores contamos con nuevas herramientas que ahora pueden emplear en sus trabajos, en este artículo publicado en el blog de Labs podrás conocer más al respecto.

Novedades en Android

  • El Historial y los Marcadores se han añadido al menú.
  • La instalación de complementos no verificados será cancelada.
  • Las página almacenadas en la caché ahora son mostradas cuando estamos sin conexión.
  • Las notificaciones sobre las pestañas abiertas en segundo plano ahora muestran la URL.
  • Firefox pedirá permisos para acceder a ciertos permisos en tiempo de ejecución y no al instalar la aplicación (Android 6.0 o superiores).
  • Durante el autocompletamiento mientras escribes una dirección ahora se incluye el dominio para hacer más fácil tu navegación.

Firefox para iOS

  • Añadida la localización en danés [da].
  • Los sitios sugeridos por defecto ahora pueden ser eliminados.
  • Los 5 primeros sitios del ranking de Alexa son mostrados a los nuevos usuarios.
  • Mejorado el manejo por parte del navegador de vínculos a Apple Maps y otras aplicaciones de terceros como Twitter.

Si prefieres ver la lista completa de novedades, puedes llegarte hasta las notas de lanzamiento (en inglés).

En estos momentos ya debes haber recibido esta actualización, pero si todavía no te ha aparecido la advertencia, puedes ir al menú “Acerca de” y hacer clic en el botón “Buscar actualizaciones”. Mientras que Firefox para Android puedes instalarlo desde Google Play.

Visto en Mozilla hispano.

Leer más

Un poco de historia

Google, como sabemos es el buscador mas grande que existe a la hora de econtrar cualquier tipo de info.

Buscando una imagen llegue hasta una ruta muy parecida a esta:

``` http://www.dominio.com/wp-content/plugins/el-plugin/inc/img/nombre-de-la-imagen.png ```
Entonces, se me ocurrio que quizas podia listar el directorio completo y ciertamente fue asi y encontre algo como esto: ![Listado de directorio](/images/print_faill_plugin.png) Si, realmente no es tan grave que se pueda listar un directorio, lo que si es grave el contenido de ese archivo que ven ahi llamado `data.log` La gravedad del asunto. ----------------------- El archivo `data.log` contiene/contenia informacion delicada sobre las api key del servicio de pago, y especialmente la informacion de una transaccion realizada donde se podia encontrar el num de TDC, la fecha de vencimiento y el cod CCV. Todo esto me lleva a la siguiente pregunta: ¿A quien le corresponde estar pendiente que no se puedan listar los directorios del Wordpress? ---------------------------------------------------------------------------------------------- Nota: Antes de escribir este post fue notificado al dueño del dominio el problema y ya fue solventado.

Leer más

Asegúrate de estar recibiendo regularmente actualizaciones de las llaves

Si no refrescas regularmente tus llaves públicas implica que no recibas a tiempo la información sobre las llaves que han expirado o las revocaciones, lo cual es muy importante.

Si realizas un simple “gpg –refresh-keys”, revelas a cualquiera y al operador de servidor de llaves todo el conjunto de llaves que te interesa refrescar.

Para evitar esto puedes hacer actualizaciones regulares de llaves usando Parcimonie para refrescar tu llavero. Parcimonie es un daemon que refresca lentamente tu llavero desde un servidor de llaves a través de Tor. El propósito es hacer más difícil para un atacante correlacionar las actualizaciones de las llaves con tu llavero. Parcimonie es un paquete que se encuentra en Debian y Ubuntu.

También puedes usar un simple cronjob, como el siguiente para refrescar tus llaves, esto requiere que tu computadora este conectada a la red a la 1am, y potencialmente revela al mundo todas las llaves que estés actualizando en tu llavero.

No uses pgp.mit.edu

El servidor de llaves pgp.mit.edu ha estado sin funcionar adecuadamente por años, especialmente para cierto tipo de actualizaciones de llaves.

Depender específicamente de un único servidor de llaves te hace vulnerable a las posibles fallas de ese servidor de llaves, si el servidor de llaves se queda fuera de la piscina principal por cualquier razón, puede que nunca lleguen las actualizaciones al resto de la piscina. Utilizar la piscina es más robusto que usar un único servidor de llaves.

Considera mejor utilizar sks keyservers pool . En gpg.conf:

keyserver hkp://pool.sks-keyservers.net

La transición a una llave primaria más fuerte

Muchas personas siguen teniendo llaves DSA de 1024-bit. Debes considerar hacer la transición a un algoritmo de función hash más fuerte y de más bits. Ahora se sabe que este tamaño está dentro de lo que Well Funded Organizations pueden llegar a vulnerar. Este algoritmo de función hash ya está también envejeciendo.

Se recomienda hacer una llave 4096bit RSA con el algoritmo de función hash SHA512, realizando un aviso de transición que esté firmado por ambas llaves y hacerlo del conocimiento de todos. Este es un buen documento (EN) que detalla exactamente los pasos para que generes una llave así, asegurándose de obtener al algoritmo de función de digest adecuado.

Considera hacer que tu servidor de llaves por defecto use un servidor de llaves que tenga transporte HKPS

En lugar de un hkp sin cifrado por defecto puedes usar hkps. Esto hace menos evidente tu mapa de relaciones sociales de cualquiera que pueda estar fisgoneando el tráfico de tus datos por la red. Si realizas un gpg –refresh-keys en un servidor de llaves que es sólo hkp, entonces alguien monitoreando tu tráfico vera cada una de las llaves que tienes en tu llavero cuando pidas las actualizaciones de las llaves.

Nota: para poder utilizar el paquete hkps usuarios Debian/Ubuntu necesitarán instalar el paquete gnupg-curl

Puedes usar hkps.pool.sks-keyservers.net como tu servidor de llaves por defecto, este es un servidor piscina que contiene los servidores disponibles que usan hkps. Esta piscina contiene únicamente servidores que han sido certificados por sks-keyservers.net CA. Puede ser usado mediante los siguientes parámetros en gpg.conf:

~/.gnupg/gpg.conf:
 keyserver hkps://hkps.pool.sks-keyservers.net
 keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

Además, hkps:/keys.indymedia.org, hkps://keys.mayfirst.org and hkps://keys.riseup.net ofrecen esto (aunque es recomendable que mejor utilices la piscina).

Finalmente, si optas por designar la piscina como tu servidor de llaves, debes también agregar la siguiente opción:

~/.gnupg/gpg.conf:
 keyserver-options no-honor-keyserver-url

Cuando se genera una llave, los usuarios pueden designar un servidor de llaves específico desde el cual se pueden descargar sus llaves. La opción de arriba va a omitir esa especificación y utilizará la piscina, lo cual es útil porque (1) previene que alguien designe un método inseguro para que podamos bajar su llave y (2) si el servidor designado usa hkps, refrescar las llaves no funcionará porque el ca-cert no va a coincidir y por lo tanto las llaves no se van a refrescar.

Asigna una fecha de vencimiento si no tienes una

Las personas suelen preferir que sus llaves no expiren, pero tú sí debes querer que expiren. ¿Porqué? Porque siempre podrás extender su fecha de vencimiento, aún después de que hayan expirado. Este “vencimiento” es de hecho una válvula de seguridad o un “sistema de seguridad de hombre-muerto” que automáticamente se activará en algún momento. Si tienes acceso a los datos secretos de tus llaves lo puedes desactivar. El objetivo es implementar algo que deshabilite tu llave en caso de que pierdas acceso a ella y que no tengas certificado de revocación.

Asignar una fecha de vencimiento significa que necesitarás extender esa fecha en algún punto del futuro. Es una pequeña tarea que necesitarás recordar hacer.

Puedes pensar que es molesto y que no quieres tener que lidiar con ello, pero de hecho es bueno hacerlo regularmente. Indica a los usuarios que su llave sigue estando activa, y que el propietario de la llave la utiliza. Además, mucha gente no firmará una llave que no tenga fecha de vencimiento.

Para asignar una fecha de vencimiento a tu llave, simplemente necesitas ejecutar:

gpg --edit-key <fingerprint>

Ahora selecciona la sub-llave a la que quieres asignar una fecha de vencimiento (por ejemplo, la primera), o ninguna para asignar el vencimiento en tu llave primaria y luego ejecuta el comando “expire”

gpg> key 1
gpg> expire

Ahora asigna un valor razonable, (por ejemplo, 2 años) guarda la llave y salga:

Key is valid for? (0) 2y
gpg> save

Ahora debes enviar tu llave a los servidores de llaves para publicar este cambio:

gpg --send-key

Agenda un evento en el calendario para recordarte sobre la fecha de vencimiento de tu llave

No lo vas a recordar, así que lo mejor es pedir un recordatorio. Agenda una alerta un mes o más antes de la fecha para que puedas hacer el cambio con algo de tiempo. No quieres tener que apresurarte cuando tengas que manejar tus llaves.

Siempre puedes extender la fecha de expiración (aún cuando la llave ya expiro), así que no necesitas generar una nueva llave cada vez, sólo necesitas extender a fecha de vencimiento para después.

¿Tienes un certificado de revocación?

Si llegas a olvidar tu frase de contraseña o si tu llave privada queda comprometida o la pierdes, la única esperanza que te queda es esperar a que expire la llave (esto no es una buena solución), o activar tu certificado de revocación publicándolo a los servidores de llaves. Al hacer esto notificarás a otros que esta llave ha sido revocada.

Una llave revocada puede seguir utilizándose para verificar firmas anteriores o descifrar datos (si es que sigues teniendo acceso a la llave privada), pero no puede ser usada para cifrar nuevos mensajes para ti.

Para saber como generar y utilizar el certificado haz clic aquí.

Utiliza únicamente tu llave primaria para certificación (y tal vez también firmar). Ten una subllave por separado para cifrar.*

(extra) Ten una subllave por separado para firmar y mantén tu llave primaria completamente fuera de linea.

En este escenario, tu llave primaria es utilizada solo para certificación, lo que no sucede con frecuencia.

No confíes en el ID de la llave

Los IDs de llaves que son cortas, por ejemplo 0x2861A790, son de 32 bits. Hemos visto que son fácilmente falsificadas por otra llave con el mismo ID. Las OpenPGP IDs largas (por ejemplo 0xA1E6148633874A3D) son de 64 bits. Son fáciles para un ataque de colisión (trivially collidable) (EN), lo que es potencialmente un serio problema (EN).

Si quieres tratar con un identificador criptográficamente fuerte para una llave, debes usar la huella digital completa. Nunca debes confiar en la ID corta de la llave.

Probablemente deberías al menos tener:

keyid-format 0xlong y with-fingerprint en las opciones gpg.conf para incrementar el tamaño en el que se muestra el ID de la llave a 64-bit bajo uso regular y para mostrar siempre la huella digital.

Asegúrate de que tu llave es OpenPGPv4

De acuerdo con el RFC4880 Las llaves V3 están ya desaprobadas, contienen 3 vulnerabilidades. Primero, es relativamente fácil construir una llave V3 que tenga el mismo ID que otra llave porque el ID de la llave son simplemente los 64 bits del módulo público. Segundo porque la huella digital de una llave V3 hace las funciones de digest del material de la llave pero no de su extensión, por lo que hay una mayor oportunidad para colisiones de huellas digitales. Tercero, hay puntos débiles en el algoritmo MD5 que hace que los desarrolladores prefieran otros algoritmos. Ver abajo la discusión sobre ID’s de llaves y huellas digitales.

Para determinar si tu llave es una llave V3 puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets |grep version

Las llaves primarias deben ser DSA-2 o RSA de 4096 bits o más. (RSA de preferencia)

Para revisar si estás utilizando DSA-2 o RSA puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 '^:public key packet:$' | grep algo

Si el algoritmo reportado es 1, quiere decir que estas usando RSA. Si es 17 entonces es DSA y necesitarás confirmar que las siguientes revisiones reporten un tamaño de llave mayor a 1024, de otro modo no estás utilizando DSA-2.

Si el algoritmo reportado es 19, estás usando ECDSA, si es 18 es ECC. En ese caso la siguiente comprobación del tamaño de bits de la llave no es un criterio apropiado para este tipo de llaves ya que los tamaños de llave se reducirán significativamente.

Para revisar el tamaño de bits de la llave primaria puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 'public key' | grep 'pkey\[0\]:'

Las auto-firmas no deben usar MD5, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 1,'

Si ves que se genera algún resultado ‘digest algo 1’, entonces tienes algunas auto-firmas que están usando MD5, ya que el algoritmo digest 1 es MD5. Ve el OpenPGP RFC 4880, section 9.4 (EN) que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las auto-firmas no deben usar SHA1, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 2,'

Si obtienes cualquier resultado ‘digest algo 2’ quiere decir que tienes algunas auto-firmas que están utilizando SHA1, ya que el algoritmo digest 2 es SHA1.

Ve el OpenPGP RFC 4880, section 9.4 que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las preferencias del algoritmo digest deben incluir al menos un miembro de la familia SHA-2 con una prioridad más alta que las MD5 y SHA1 juntas

Puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'pref-hash-algos'

e inspeccionar los resultados. El orden de preferencia está basado en cuál número está primero de izquierda a derecha. Si ves un número ‘3’, ‘2’, o ‘1’ antes del ‘11’, ‘10’, ‘9’ u ‘8’, quiere decir que has especificado en tus preferencias preferir un algoritmo digest más débil.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Las llaves primarias deben tener una fecha de vencimiento razonable (no más de 2 años en el futuro) Puedes revisar cuáles son las fechas de vencimiento de tus llaves haciendo lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'key expires after'

Después inspecciona visualmente cuáles son los resultados para confirmarlo, la fecha en la lista será relativa a la creación de la llave lo cual puede ser difícil de interpretar.

Otro modo de revisar el vencimiento es simplemente:

gpg --list-keys <fingerprint>

Lo cual debe mostrar las fechas de creación y vencimiento de la llave primaria y de cada sub-llave asociada. Si no ves nada que mencione “expires” en este resultado, quiere decir entonces que no designaste una fecha de vencimiento apropiadamente.

Para corregirlo:

gpg --edit-key <fingerprint>
 gpg> expire
 ...
 gpg> save

Actualiza tu configuración GPG por defecto

Si estás utilizando GnuPG, asegúrate de tener las configuraciones optimas en gpg.conf, para esto puedes utilizar el siguiente script.

No incluyas un “comentario” en tu ID de usuario

Si crees que necesitas un lugar para un “comentario” en tu OpenPGP User ID piénsalo bien dos veces lee más sobre esto (EN). Probablemente no lo necesites ni lo quieras. Tener un espacio para un comentario dificulta a mucha gente saber qué es lo que están certificando.

Visto en riseup.net.

Leer más

Este año se realiza nuevamente uno de los eventos tecnológicos más importantes de Latinoamérica y ahora del mundo: el FLISoL. Continuaremos construyendo una ciudad con oportunidades para acceder al conocimiento, a la tecnología, conservando al máximo tu derecho a la libertad y la privacidad.

Detalles del Evento

Este evento se realizará en Valencia VE:

  • Viernes 22 de Abril de 2016
  • De 8:00 hasta 13:00
  • Universidad José Antonio Páez (Arterial 5, San Diego 2006, Venezuela, Edificio 4, Piso 5, Salones 4504).

Registro al evento

Realmente este paso es opcional pero te invito a que le des clic aquí para que los organizadores del evento puedan llevar un control de las personas que asistan.

¿Qué es el FLISoL?

El Festival Latinoamericano de Instalación de Software Libre (FLISoL) es el evento de difusión de Software Libre más grande en Latinoamerica. Se realiza desde el año 2005 y desde el 2008 se adoptó su realización el 4to Sábado de abril de cada año. En Valencia se realizará el Viernes 22 de Abril.

Su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo.

A tal fin, las diversas comunidades locales de software libre en (/Venezuela), organizan simultáneamente eventos en los que se instala, de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

Leer más

WordPress Logo

El día mundial de traducción de WordPress es un día completo dedicado a ofrecer WordPress para más personas en todo el mundo. 24 horas de sesiones de formación en vido de WordPress en i18n y L10n.

I'm Translating at WordPress Translation Day!

Cuando?

El día mundial de traducción de WordPress se llevará a cabo el domingo, 24 de abril de 2016. Las sesiones en vivo comienzan a las 0:00 UTC y los eventos locales comienzan en diferentes momentos dependiendo de la zona horaria.

En Venezuela será el día 23 de Abril a las 19.30hrs

Qué?

sesiones en vivo sobre WordPress en diferentes idiomas aquí en este sitio. Durante los días de WordPress Traducción Global habrá más de 30 eventos que son contribuyentes organizados en más de 20 países.

Donde?

Universidad Nacional Experimental del Táchira, Avenida Universidad. Sector Paramillo., San Cristobal. Para más info clic aquí.

Por qué?

Porque amamos a WordPress y nosotros queremos que sea accesible para más personas en más idiomas! Y porque queremos mostrar cómo hacer que eso suceda.

Leer más

Leer más

Recently I had the opportunity to share stage with some brilliant internal and external colleagues advancing open source in the cloud at //build, Microsoft’s developer conference in San Francisco. Beyond having been able to talk to about 400 attendees about how we’re approaching open source in the cloud, how customers are building open source applications in Azure and much more, speaking at //build had a very special meaning for me.

Before joining Microsoft, I didn’t have a lot of exposure to the Microsoft developer ecosystem, the Microsoft subsidiaries themselves or the employees working there. I was focused in a number of open source projects such as Canaima (Venezuela’s national distro) a number of communities and expanding a small open source system integrator in the region.

Most of my interaction with Microsoft was limited to public debates, at industry events or in Congress, or to the ISO/IEC 29500 discussion back in the days (both of which I’ve covered in this blog, in Spanish) However, around 2009 or so, the company I was a CTO for and Microsoft decided to create an Open Source Interoperability Lab in Venezuela. The idea was to document common hybrid technology use cases (such as Samba-based DCs in Windows environments, or PHP and ASP.NET communicating via ESB) and transfer that knowledge to customers.

As a result of that effort, I ended up being invited to and participating in PDC09 in Los Angeles. PDC was the precursor of //build, a yearly conference aimed at Microsoft-centric developers. There are 3 things I remember clearly from PDC09: one, was the “convertible tablet PC” they offered attendees (running Windows 7 bits that rapidly became Debian bits), the second one was the PHP SDK for Azure, and the preview access to that new “cloud” thingy, and the third one was an open source roundtable led by Miguel de Icaza that mainly talked about governance and CodePlex.

While I didn’t know it back then, a lot of the things discussed in that roundtable influenced my decision, about a year later, to join Microsoft and work in open source strategy; a journey that brought me to Azure in less than 5 years. But I digress, and that whole story deserves another post.

Maybe some of the attendees then foresaw that Microsoft would end up acquiring Xamarin, or that attention would be put in non-CodePlex initiatives, like GitHub. What I really didn’t expect was that all of that new reality would converge into a PDC-like event, less than 10 years after. This year at //build it did, and then some.

For me, speaking at //build was a humbling opportunity to reconcile the many worlds increasingly pulled together by the force of open source. From the announcements to the content and all other metasignals at the conference, it was incredibly exciting to see this transformation manifesting itself within Microsoft’s developer community.

It highlights the importance of leaving no one behind when we explore new paradigms and technologies in the cloud, and how every individual in the open source community can exert change in this industry.

Leer más

Muchas personas no le dan la importancia requerida a un certificado de revocación hasta que es demasiado tarde, básicamente un certificado de revocación te permite cancelar tu llave pública en cualquier momento que pierda acceso a tu llave privada o esta se vea comprometida.

Si el certificado de revocación queda comprometido, la persona que lo comprometa podrá revocar la llave pública en circulación, sin embargo no podrá acceder a la llave secreta y tampoco podrá generar falsas firmas, descifrar mensajes o cualquier otra cosa que pueda hacer el usuario del par de llaves. Realmente lo único negativo de esto es que deshabilita el par de llaves.

Para generar el certificado de revocación solo debe ejecutar el siguiente comando:

gpg -a -o revoke.asc --gen-revoke <ID_Llave>

Para revocar la llave en caso de que haya sido comprometida solo debe ejecutar el siguiente comando:

gpg --import revoke.asc

Si se ejecuta “gpg –list-key” podrá ver que la llave ha sido cancelada, ahora solo falta subir de nuevo la llave a los servidores de llaves para que todos puedan ver que fue revocada, para esto solo hace falta ejecutar el siguiente comando:

gpg --keyserver pool.sks-keyservers.net --send-keys <ID_Llave>

Espero les sea útil, saludos…

Mas información:

Leer más

¿Qué es exactamente un grupo de firmas?

Un grupo de firmas es la forma de reunir a personas que utilizan sistemas criptográficos tipo PGP con el propósito de permitir a dichas personas el firmado mutuo. Los grupos de firmas sirven para extender la confianza por la red.

¿Qué es una llave firmada?

El firmado de llaves es el acto de firmar digitalmente una llave pública y un id asociado con dicha llave. La firma nos sirve para verificar que el id y la llave pública pertenecen realmente a la entidad que aparece en la firma que representa esa llave.

Cada uno puede firmar su propia llave pública y los id asociados a ella, en esencia, las firmas validan las llaves públicas. Es una forma de validar una llave pública y una identidad gracias a una tercera parte. Esta es la forma en la cuál las firmas crean un sistema de confianza.

¿Qué es un sistema de confianza?

Un sistema de confianza es el término utilizado para describir la relación de confianza entre un grupo de firmas. La firma es un enlace, o una ramificación, en el sistema de firmas de confianza. Estos enlaces son llamados vías de confianza (Trust Paths). Las vías de confianza pueden ser bidireccionales o de una única dirección. El ideal de un sistema de confianza es que cada uno esté conectado de forma bidireccional con los demás. De hecho, cada uno confía en que cada llave pertenece a su propietario legítimo.

¿Por qué debo firmar mi llave en grupo?

Existen tres razones principales para tener tantas firmas como se pueda.

La primera y la más importante, debes tener la mayor cantidad de firmas para expandir tus vías de confianza. Cuanto más profundo y estrechamente interconectado sea el sistema de confianza, más difícil será comprometerlo. Esto tiene un significado especial para las Comunidades de Software Libre, sean desarrolladores o usuarios. Los miembros de esta comunidad delegan sobre la tecnología criptográfica PGP la protección e integridad de sus paquetes de software, avisos de seguridad y anuncios. La fuerza y robustez del sistema de confianza es directamente proporcional a la fuerza de protección que PGP provee a la comunidad.

La segunda razón es que los grupos de firmas ayudan a otras personas a integrarse dentro de la cultura de la seguridad y les anima a adquirir conocimientos sobre PGP y otras tecnologías de criptografía. Para conseguir toda la fuerza de la criptografía la gente debe usarla y usarla correctamente.

Finalmente, los grupos de firmas ayudan a construir comunidades. Ayudan a juntar nuevos conocimientos y discusiones importantes sobre libertades civiles, cripto-derechos y regulación de internet. La discusión es importante por que no sólo es el primer paso, pero es el paso antes de la acción.

Organizando el Grupo

El Coordinador

No es difícil organizar y coordinar un grupo de firmas. Sin embargo a parte de las tareas normales de invitar a la gente, seleccionar un lugar y una fecha, el coordinador tiene otras tareas claves específicas a su responsabilidad. Eso, normalmente, incluye el suministro de una lista de llaves para cada participante y una determinación de la estructura del grupo.

¿Como debe de estar estructurado el grupo?

Hay dos formas de conducir un grupo de firmas de forma estructurada: de forma centralizada o de forma descentralizada. La mejor forma de determinar como hacerlo es dependiendo del número de participantes y la atmósfera del local donde se lleva a cabo la fiesta. Los requisitos básicos del grupo son que los participantes se verifiquen unos a otros las llaves y las identidades. Dados estos requisitos básicos el coordinador puede introducir algunas variaciones a estos dos tipos.

Un grupo centralizado es un asunto más organizado donde se trabaja bien con un grupo pequeño o medio de personas. Los participantes envían la información de sus llaves públicas al coordinador quién las anota en una lista. Cada participante, tal como van llegando al grupo, recibirá una copia de la lista, luego al estar reunidos todos, cada participante será llamado por el coordinador.

El participante comprobará que los datos son correctos respecto a la lista dada por el coordinador. Si el participante está seguro que su llave es la misma que la facilitada por el coordinador, entonces el participante leerá su huella digital ante los demás participantes para que estos puedan comprobar que sea la correcta. Si es correcta, los participantes deberán marcarlo en su hoja. Esto es necesario para evitar errores o falsedades en la hoja creada por el coordinador. Hasta que todos hayan comprobado la llave del participante, entonces el coordinador podrá llamar a otro participante y así sucesivamente.

Una vez que todas las llaves han sido verificadas, los participantes y el coordinador rogará a los participantes que formen una línea con sus identificaciones bien visibles. La persona en cabeza de la fila caminará hacia abajo de la fila comprobando los id. Si la id es correcta y se ha validado lo que se ha dicho sobre la llave al principio del encuentro, entonces se pondrá una segunda marca en su lista. Sólo la llave que tenga dos marcas será firmada.

Un grupo de firmas descentralizada es básicamente libre albedrío. Los participantes mezclan informalmente y buscarán a otros participantes cuyas llaves no hayan sido firmadas aún. Mientras duré el evento, cada uno verificará la llave y el id de cada persona, los grupos descentralizadas permiten incluir más fácilmente a gente nueva. En un grupo descentralizado, es importante que el coordinador anime a cada uno a que se asegure de que se ha reunido con todo el mundo, al menos para la validación de la llave. En este caso no es necesario hacer una lista de llaves y de huellas, aunque es una buena práctica.

Anunciando el Grupo

Si estas creando un sistema de confianza en tu comunidad, es buena idea intentar atraer a usuarios de PGP activos porque ellos son los principales interesados en mantener los grupos de firmas. La mejor forma de encontrar a la gente es hablando con aquellas personas que se encuentran en las listas de correo con firma PGP o buscando en el servidor de llaves aquellas cuentas de correo que puedan pertenecer a tu localidad. Por ejemplo, las cuentas de correo con el dominio de una universidad o una gran compañía de tu localidad.

Generando la lista de llaves

Si vas a utilizar un formato de fiesta estructurada se necesita que cada participante tenga una lista de llaves de todo el mundo, el coordinador tendrá que imprimir muchos listados o enviar la lista por correo a todos los participantes. Dichos listados suelen recopilarse en el siguiente formato:

Llave id – Propietario – Huella – Tamaño – Tipo – ¿llave válida? – ¿id válido?

Participando en el Grupo

El Participante

Esta es una lista de los pasos que debe seguir cada participante del grupo:

  • Generar un par de llaves.
  • Enviar la llave pública al servidor de llaves.
  • Enviar los detalles de tu llave pública al coordinador.
  • Ir al grupo de firmas.
  • Verificar los detalles de su llave.
  • Verificar los detalles de la llave de los demás.
  • Verificar la identidad para los id que se va a firmar.
  • Firmar todos aquellos id y llaves que se hayan verificado.
  • Enviar todas las llaves que se han firmado al servidor de llaves.

¿Qué hay que llevar a el Grupo?

  • Dos identificaciones con foto.
  • Detalles de las llaves de su propiedad: id, Tipo, Huella y Tamaño.
  • Un bolígrafo o lápiz.

¿Qué no hay que llevar?

  • Un ordenador.

¿Por qué no se debe llevar un ordenador?

No se deben llevar ordenadores a los grupos porque los programas pueden haber sido alterados de tal forma que comprometan la seguridad del PGP. Si alguien llevase un ordenador y todos utilizaran ese ordenador para firmar las llaves, nadie sabría si en dicho ordenador hay un grabador de teclas (KeyLogger) activo, o la versión del GPG ha sido modificada o incluso el Kernel de Linux, o que el teclado está especialmente modificado, cualquiera de estas cosas pueden capturar las llaves secretas de aquellos que utilicen el ordenador.

Firmando otras llaves

Obtener un copia de la llave

Normalmente se obtiene de los servidores de llaves, sin embargo si la llave no está disponible en el servidor puedes importarla utilizando gpg –import. Si trabajas con servidores de llaves, el siguiente comando te servirá para descargar la llave publica e incorporarla en tu anillo público.

gpg --keyserver <servidor> --recv-keys <ID_Llave>

Huella y verificado de llave

gpg --fingerprint <ID_Llave>

GPG imprimirá la huella del usuario <ID_Llave> Comprobamos la huella con la que tenemos en el listado del grupo de firmas.

Nota: No compruebes la huella de tu listado contra la huella que aparece en la web del servidor, ya que puede no haberte enviado la misma llave.

Firmar una llave

gpg --sign-key <Key_ID>

Si tienes múltiples llaves privadas, debes especificar cuál de todas tu llaves privadas es la que va a firmar la llave pública, este es el comando:

gpg --default-key <ID_a_usar> --sign-key <ID_Llave>

Si tienes problemas con llaves tipo RSA es por que probablemente estés utilizando una versión antigua de GnuPg. Versiones anteriores a la 1.0.3 no incluye compatibilidad con RSA.

Nota: Debes desinstalar la versión antigua, para comprobar que versión estas utilizando usa el siguiente comando:

gpg --version

Devolver o subir la llave firmada

Si estas trabajando con una entidad que no quiere que su llave esté en un servidor público, deberás devolver la llave pública firmada a su propietario por el método que él elija (normalmente cifrada). No debes enviar la llave pública firmada al servidor sin el permiso de su propietario. Publicar una llave reduce levemente la seguridad del par de llaves, por lo tanto está mal visto publicar una llave si su propietario no lo desea.

Pero normalmente trabajarás con servidores de llaves. Si es el caso, deberás enviar la llave pública firmada de vuelta al servidor con el siguiente comando:

gpg --keyserver <servidor> --send-key <ID_Llave>

Verás un mensaje de éxito como este:

gpg: success sending to <servidor> (status=200)

Felicidades, el firmado de llave pública ha terminado y tu firma ha sido incluida en su llave pública. Se han establecido las vías de confianza. Saludos…

Leer más

Frikosfera

DERECHOSLECTORESDIGITALES

Los lectores clásicos dicen que un libro electrónico jamás podrá reemplazar el sentimiento ni el olor de los libros en papel, otros, los más modernos afirman que leer libros digitales es más ecológico. Sea cual sea nuestro punto de vista siempre encontramos algún libro que nos llama la atención sus críticas o reseñas y no lo encontramos en la librería local, es por esto que siempre es conveniente tener una lista de algunas paginas web que distribuyen libros.

Ver la entrada original 219 palabras más

Leer más