En ciencias de la computación se dice que una función o expresión tiene efecto colateral, efecto de lado o efecto secundario si esta, además de retornar un valor, modifica el estado de su entorno. Por ejemplo, una función puede modificar una variable global o estática, modificar uno de sus argumentos, escribir datos a la pantalla o a un archivo, o leer datos de otras funciones que tienen efecto secundario. Los efectos secundarios frecuentemente hacen que el comportamiento de un programa sea más difícil de predecir.

La programación imperativa generalmente emplea funciones con efecto secundario para hacer que los programas funcionen, la programación funcional en cambio se caracteriza por minimizar estos efectos.

En el diseño de CPU las instrucciones con efecto colateral son aquellas instrucciones que modifican valores internos del CPU de forma no explícita – de hecho, la instrucción ADD puede o no modificar otros registros (carry, zero, overflow, etc). Esto causa un problema cuando se diseña un CPU que usa “pipeline” de instrucciones y soporta instrucciones con efecto colateral. Se debe prestar especial cuidado para evitar este riesgo.

Transparencia referencial

Que una función no tenga efecto secundario o colateral es una condición necesaria pero no suficiente para que sea transparente referencialmente. Transparencia referencial significa que una expresión (por ejemplo, una llamada a una función) puede ser reemplazada por su valor; esto requiere que la expresión no tenga efecto colateral y que sea pura, o sea, que siempre retorne el mismo resultado con la misma entrada.

Muchas veces necesitamos hacer algún script en bash donde queremos que tenga ciertas características, y muchas veces queremos que las salidas por pantalla de ese script se vean distintas para llamar la atención.

bash_colors

Pues bien, se puede usar colores para el texto en el bash de una forma sencilla.

Esta es la lista de algunos de los códigos de color para nuestro texto:

  • Negro = 0;30
  • Gris oscuro = 1;30
  • Azul = 0;34
  • Azul claro = 1;34
  • Verde = 0;32
  • Verde claro = 1;32
  • Cyan = 0;36
  • Cyan claro = 1;36
  • Rojo = 0;31
  • Rojo claro = 1;31
  • Púrpura = 0;35
  • Púrpura claro = 1;35
  • Café = 0;33
  • Amarillo = 1;33
  • Gris = 0;37
  • Blanco = 1;37

El comando echo se debe de ejecutar con el parámetro -e haciendo que bash interprete el comando \e (o sea el escape) de esta manera:

echo -e ‘Esto es \e[0;31mrojo\e[0m y esto es \e[1;34mazul resaltado\e[0m’

Resultado: Esto es rojo y esto es azul

echo -e ‘Así se escribe \e[1;34mG\e[0m\e[1;31mo\e[0m\e[1;33mo\e[0m\e[1;34mg\e[0m\e[1;32ml\e[0m\e[1;31me\e[0m’

Resultado: Así se escribe Google

En resumen para poder utilizarlo solo hay que poner los caracteres que quieras que tengan color entre los caracteres de escape de esta manera:

‘\e[CODIGOm(texto)\e[0m’ (el texto sin los paréntesis)

Colores de fondo

De la misma forma podemos cambiar el color de fondo mediante los siguientes valores:

  • Negro = 40
  • Rojo = 41
  • Verde = 42
  • Amarillo = 43
  • Azul = 44
  • Rosa = 45
  • Cyan = 46
  • Blanco = 47

Para utilizarlo solo debemos seguir la siguiente sintaxis:

echo -e "\e[42mMuestra\e[49m"

Como se puede apreciar en la imagen que acompaña este post las combinaciones pueden ser bastante grandes y solo hace falta un poco de creatividad para crear resultados llamativos. Cabe destacar que el código \e[49m regresa el color de fondo al original.

A veces no podemos utilizar nuestro servidor principal, ya que estamos cambiándolo, actualizándolo, peleándonos con dependencias o trabajando en configuración o plug-ins. Por lo que necesitamos algo para reemplazarlo momentáneamente.

Tampoco se quiere algo demasiado grande porque es para un apaño. Tal vez no tengamos nodeJs instalado, o python en los que nos podemos crear un servidor web con pocas líneas. Y tampoco queremos tener que instalar demasiadas cosas.

Como alternativa ligera podemos usar netcat el cual viene instalado por defecto en muchas distribuciones.

Sólo tenemos que ejecutar lo siguiente:

$ sudo -c sh 'while true; do nc -l -p 80 < respuesta.html; done'

Sin sudo y con usuario root si no disponemos de él en el sistema. Con esto, vamos a poner constantemente en escucha el puerto 80 y procesando todas las peticiones de la misma forma, devolviendo los contenidos de respuesta.html.

Las pruebas pueden realizarse como un usuario normal (no root) si utilizamos un puerto mayor de 1024, por ejemplo el 8000, 8080, 1234, etc:

$ while true; do nc -l -p 8000 < respuesta.html; done

Como la respuesta debe ser muy rápida, en principio no tenemos necesidad de algo más complicado (esperemos que no vengan demasiadas visitas mientras trabajamos). Pero este sistema no soportará usuarios concurrentes, recordemos que es sólo un servidor temporal y puede que a algún usuario le dé algún problema en conectar. Podemos guardar un registro de todo lo que ha pasado con:

$ sudo -c sh 'while true; do nc -l -p 80 < respuesta.html; done > log'

o como usuario:

$ while true; do nc -l -p 8000 < respuesta.html; done > log

Creando respuesta.html

Como habrás podido ver respuesta.html no es un archivo HTML normal, en realidad aquí hay que poner toda la respuesta completa (con cabeceras incluidas), podemos hacer algo sencillo primero:

HTTP/1.1 200 OK
Server: LittleServer
Content-Type: text/html;charset=UTF-8<html>
<body>
<h1>Lo sentimos, estamos de mantenimiento</h1>
Disculpe las molestias, en un momento estaremos con usted.

&lt;/body&gt;
&lt;/html&gt;

La página a partir de la etiqueta <html>, podemos poner el código HTML que queramos. Aunque ahora estaremos contestando con un código de salida exitoso, lo que significa que los usuarios no se cabrearán (bueno sí, pero al menos verán una explicación), pero los buscadores y robots sí que la tomarán con nosotros, porque se creerán que ésta es la página buena, es más todas las páginas del servidor responderán lo mismo.

Respondiendo para que los buscadores no nos tengan en cuenta

Para ello tenemos que poner en nuestra cabecera un error 503 (Servicio no disponible). Esto será bueno porque no devolveremos un 200 (OK) para las páginas temporales, ni devolveremos un 404 (Not found / No encontrado) para el resto de páginas que no estén en nuestro servidor pero si deberán estar y el buscador de turno lo sabe (esto último sería horrible para nuestro posicionamiento, porque el buscador se creería que esas páginas ya no existen y las desindexará).

Para ello, nuestro archivo de respuesta.html será el siguiente:

HTTP/1.1 503 Service Unavailable
Server: Maintenance
Retry-After: 3600
Content-Type: text/html;charset=UTF-8&lt;html&gt;
&lt;body&gt;
<h1>Lo sentimos, estamos de mantenimiento</h1>
Disculpe las molestias, en un momento estaremos con usted.

&lt;/body&gt;
&lt;/html&gt;

Además, añadiremos Retry-After para que vuelvan dentro de un rato a ver si todo está bien. No se garantiza que los buscadores vuelvan dentro de una hora (3600 segundos), pero es normal que vuelvan cuando tengan un rato después de una hora.

Queremos complicarnos la vida

Si has llegado hasta aquí, eres de los que le gustan complicarse la vida e inventar cosas, así que, para dejar un poco a la imaginación y para hacer un servidor web un poco más completo.

Vamos a crear un script que procesará la petición HTTP que se realice (tenemos que recordar que cuantas más cosas metamos, más vulnerable será nuestro sistema, y un script aquí es tremendamente vulnerable).

dispatcher.sh

#!/bin/bash
I=0
while read RAWINPUT; do
if [ ${#RAWINPUT} -le 1 ]
then
break
fi
INPUT[$I]=$RAWINPUT
I=$(($I+1))
doneread -a FIRSTLINE <<< ${INPUT[0]}
METHOD=${FIRSTLINE[0]}
REQUEST=${FIRSTLINE[1]}
HTTPVER=${FIRSTLINE[2]}

echo $HTTPVER 503 Service Unavailable
echo "Retry-After: 3600"
echo "Server: Bash-Maintenance"
case "$REQUEST" in
"/logo.jpg")
FILE="my-logo-file.jpg"
echo "Content-Type: image/jpeg"
echo "Content-Length: "$(stat -c%s "$FILE")
echo
cat $FILE
;;
"/fortune")
CONTENT=$(fortune)
echo "Content-Type: text/html; charset=utf-8"
echo "Content-Length: "${#CONTENT}
echo
echo $CONTENT
;;
*)
FILE="respuesta.html"
echo "Content-Type: text/html; charset=utf-8"
echo "Content-Length: "$(stat -c%s "$FILE")
echo
cat $FILE
;;
esac

Ahora tenemos 3 respuestas posibles:

  • Una para una imagen que llamaremos a través de http://nuestroservidor/logo.jpg y que llamará a la imagen my-logo-file.jpg
  • Otra que llamará al programa fortune, para que nos devuelva una frase aleatoria.
  • Otra que atenderá todas las demás peticiones (*) y servirá el archivo respuesta.html.

Para hacer que netcat utilice este archivo, depende de la versión, por un lado podemos llamar a:

$ sudo sh -c 'while true; do nc -v -l -p 80 -c dispatcher.sh; done'

como usuario:

$ while true; do nc -v -l -p 8000 -c dispatcher.sh; done

Aunque en muchas versiones de GNU/Linux viene otra versión instalada que no soporta -c, pero no todo está perdido:

$ rm /tmp/bashwebtmp; mkfifo /tmp/bashwebtmp; sudo -c sh 'while true; do cat /tmp/f | bash dispatcher.sh | nc -v -l -p 80 > /tmp/f; done';

como usuario:

$ rm /tmp/bashwebtmp; mkfifo /tmp/bashwebtmp; while true; do cat /tmp/f | bash dispatcher.sh | nc -v -l -p 8000 > /tmp/f; done;

No debemos olvidar borrar la pipe /tmp/bashwebtmp cuando terminemos de usar el programa.

Una cosa más, no debemos abusar de este script y no debemos enviar contenidos muy grandes, por ejemplo, no abusar de las imágenes, como decía antes, sólo soporta una conexión, si hacemos que esta conexión se extienda en el tiempo perderemos capacidad de atender más conexiones.

Visto en: Poesía Binaria

Tras 6 semanas de estar en fase beta, en el día de ayer fue liberada una nueva versión de Firefox, por lo que es tiempo de actualizar. En este lanzamiento sobresale el empleo de Google’s Widevine CDM para reproducir contenido a través del plugin Silverlight que contenga protección DRM, la posibilidad de visualizar y buscar fácilmente las pestañas sincronizadas en otros dispositivos, importantes cambios relacionados con los complementos, mejoras en la seguridad y mucho más.

¿Qué hay de nuevo?

Google Widevine CDM

El año pasado Mozilla introdujo en Firefox la posibilidad de reproducir contenidos protegidos bajo DRM a través de Adobe’s Primetime CDM y ahora se ha añadido Google Widevine CDM en Windows y Mac. Widevine es una alternativa para la para la transmisión de los servicios que en la actualidad se basan en Silverlight y son protegidos por DRM. Es válido recordar que Widevine se activará cuando los usuarios interactúen por primera vez con un sitio web que requiera Widevine.

Widevine CDM se ejecuta en un entorno seguro y abierto en Firefox, permitiendo mejor seguridad que los plugins NPAPI y a su vez significa un importante paso en los planes de Mozilla para eliminar los plugins NPAPI. Algunas páginas web utilizan un tipo de DRM que no admiten los módulos de cifrado de contenido de Adobe Primetime ni de Google Widevine. Para poder verlo, quizás necesites un plugin NPAPI de terceros, como Microsoft Silverlight.

Pestañas sincronizadas a la vista

Desde la inclusión de Sync en el navegador puedes compartir tu información y preferencias (como marcadores, contraseñas, pestañas abiertas, lista de lectura y complementos instalados) con todos tus dispositivos para mantenerte actualizado y no perderte nada.

Con este lanzamiento, ver las pestañas abiertas en otros dispositivos será mucho más fácil e intuitivo pues al sincronizar inmediatamente se mostrará el botón tabs en la barra de herramientas, el cual te permite acceder mediante un panel a estas páginas en tu equipo con tan solo un clic. También, mientras busques en la barra de direcciones, las pestañas serán mostradas en la lista desplegable.

Barra lateral que muestra las pestañas abiertas en otros dispositivos

Barra lateral que muestra las pestañas abiertas en otros dispositivos

Si nunca has configurado Sync y deseas hacerlo, puedes leer este artículo. ¡Es muy fácil y rápido!

De videos y otros temas

La decodificación del códec VP9 ha sido habilitada solo para usuarios que cuenten con máquinas rápidas y los videos embebidos de YouTube ahora se reproducen a través de HTML5 si Flash no esta instalado. Esto significa que los videos se reproducirán de una forma más fluida, empleando menos ancho de banda y extendiendo la vida útil de tu batería.

El idioma Latgalu ha sido incorporado y se suma a la larga lista de lenguas soportadas por el panda rojo.

Cambios en los complementos

FUEL (Firefox User Extension Library) ha sido eliminada y debido a ello, los complementos que la incorporen no funcionarán más en el navegador, a menos que sus desarrolladores actualicen su código.

La lista blanca para ejecutar plugins fue suprimida, por lo que todos los plugins estarán inhabilitados por defecto para ejecutarse y debemos permitir según su nivel de confianza u otro aspecto personal.

Por otra parte, la preferencia browser.sessionstore.restore_on_demand ha sido establecida a su valor original (true) para evitar problemas de rendimiento en e10s.

Novedades en Android

  • Adicionada la opción “Mostrar/Ocultar fuentes web” en la configuración avanzada para reducir datos y mejorar el ancha de banda.
  • Esta será la última versión con soporte para Android 2.3.x (Gingerbread).
  • La opción “Abrir múltiples enlaces” en General, ha sido renombrada y ahora se llama “Pestañas en cola”.
  • Eliminado el soporte para Android web runtime (WebRT).
  • Eliminados los favicons de las páginas para prevenir engaños HTTPS.

Lo nuevo para desarrolladores

Si deseas conocer más detalles de las novedades para desarrolladores puedes leer este artículo publicado en el blog de Labs de Mozilla Hispano donde abordan más el tema.

  • Cambios en la compatibilidad de complementos.
  • Ahora podemos comenzar, parar y depurar los Service Workers registrados.
  • Simulación de la inserción de mensajes en la herramienta Service Workers.
  • En la vista de diseño adaptable se puede personalizar el User Agent a utilizar.
  • Añadido el soporte para la suites criptográficas ChaCha20/Poly1305.
  • Entradas multi-líneas inteligentes en la Consola Web.
  • WebCrypto: PBKDF2 ahora soporta los algoritmos de suma SHA-2.
  • WebCrypto: añadido el soporte a las firmas RSA-PSS.

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.

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.

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.

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:

¿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…

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

El día mundial por las copias de seguridad es una iniciativa privada sin ánimo de lucro que pretenden concienciar a los usuarios sobre la importancia de hacer copias de seguridad de su sistema. El 31 de marzo fue el escogido para que los usuarios de todo el mundo fueran conscientes de los riesgos de no contar con un “backup” de sus datos.

Mas información: