En muchas ocasiones, como cuando se hacen túneles SSH, es más cómodo mantener una conexión abierta que no se cierre por timeout. Una manera de hacerlo es mediante las políticas del servidor SSH, pero otra manera más sencilla es hacerlo por cada conexión desde el cliente.

Comúnmente en los clientes SSH en Unix están las opciones TCPKeepAlive y ServerAliveInterval. La primera indica que se quiere mandar un paquete SSL por TCP hacia el servidor para mantener la actividad y la otra indica el intervalo en segundos en el cual se van a mandar los paquetes. Un ejemplo de uso sería el siguiente:

ssh -o TCPKeepAlive=yes -o ServerAliveInterval=5 usuario@servidor

Así ya podrán mantener sus sesiones de SSH abiertas todo el tiempo que quieran y no olviden cerrarlas cuando las dejen de usar.

Que puedo decirles no estoy a favor de que Apple se olvide de los Power Users pero en fin…

Necesitaba hoy de un tag cloud sencillo en php y encontré muchos ejemplos que no se me hicieron muy buenos, así que programé uno. Se los dejo para que lo usen:

/**
$wordlist en la forma array('palabra1' => array('numero' => 5), 'palabra2' => array('numero' => 3))
*/
function tagCloud($wordlist, $fmax) {
	//esto sive para que el tamaño minimo de la letra sea 10px
	if($fmax < 20) {
            $fmax = 10;
 	} else {
	     $fmax -= 10;
        }
        //primera recorrida para obtener el maximo y el minimo
        $tmin = 0;
        $tmax = 0;
        foreach($wordlist as $key => $value) {
		if($value['numero'] > $tmax || $tmax == 0)
			$tmax = $value['numero'];
		if($value['numero'] < $tmin || $tmin == 0)
                        $tmin = $value['numero'];
         }
         foreach($wordlist as $key => $value) {
		if($value['numero'] > $tmin) {
                        $si = ceil(($fmax * ($value['numero'] - $tmin) / ($tmax - $tmin)))+10;
                } else {
			$si = 10;
		}
		$wordlist[$key]['size'] = $si;
	}
	return $wordlist;
}

Su uso es bastante sencillo. Tenemos que meter todos los elementos a un array de la siguiente forma:

$wordlist = array('palabra1' => array('numero' => 5), 'palabra2' => array('numero' => 3));
//30 es el tamaño máximo de la letra
$wordlist = tagCloud($wordlist, 30);
foreach($wordlist as $key => $value) {
     echo '<span style="font-size: '.$value['size'].'px;">'.$key.'</span> ';
}

Nótese que en el array podemos meter los valores que queramos y que necesitemos, sólo debe estar presente la llave llamada numero.

Me basé en el artículo de wikipedia: http://en.wikipedia.org/wiki/Tag_cloud

Protocolos de conocimiento cero (ZKP)

Sabemos que sin un esquema de cifrado de llave pública es trivial para un atacante interceptar la información que se envía entre el cliente y el servidor, pero el sistema debe tener alguna manera de autenticar a los usuarios del sistema. Necesitamos enviar algo que si un atacante intercepta no pueda utilizar para autenticarse. Esto se conoce como un protocolo de conocimiento cero (Zero-knowledge proof), y en palabras coloquiales significa: “probar que poseemos cierta información sin revelar esa información”.

Como comúnmente la única información que queremos “probar que poseemos pero no queremos revelar” es la contraseña, voy a explicar el esquema que usa MySQL para implementar su autenticación de usuarios. Los detalles no están explicados de manera formal en la documentación de MySQL pero alguien se tomó el tiempo de leer el código fuente y explicar cómo funciona (MySQL 4.1.x authentication internals).

¿Cómo se almacenan las contraseñas?

Lo primero que hay que tener en cuenta es que, siguiendo los principios básicos de almacenamiento seguro de contraseñas, éstas se almacenan en el sistema sólo como un hash criptográfico. Que tiene la propiedad de ser prácticamente irreversible y prácticamente único. Por lo que esta es la primera parte del ZKP, ya que sólo quien conozca la contraseña podrá generar el hash criptográfico que le pertenece.

Desde MySQL 4.1 las contraseñas de usuario están almacenadas en la tabla “mysql.user” en la columna “Password” de la siguiente manera: . Donde es el hash criptográfico SHA-1.

La transmisión

Si cada vez que el cliente se quiera autenticar sólo transmitiera , cumpliría con el principio de no revelar la contraseña, pero un atacante podría capturar y enviar después para autenticarse exitosamente aún sin conocer la contraseña. Por lo que necesitamos agregar más cosas al protocolo para que la información que transmite el cliente sólo sea útil para un intento de autenticación.

Este sería el esquema cliente-servidor para la transmisión:

1. Se inicia el intento de autenticación
2. El servidor genera una cadena aleatoria y se la transmite al cliente.
3. El cliente calcula , y (aqui significa concatenación).
4. Finalmente el cliente transmite . (aquí significa bitwise XOR)

Autenticación

El servidor sólo conoce , que está almacenado en la tabla de usuarios, y . Para autenticar hace lo siguiente:

1. Calcula .
2. Calcula .
3. Calcula .
4. Sólo si la autenticación es exitosa.

Observaciones

Nunca se transmite ni , por lo que la fortaleza está en que este ZKP verifica que el cliente conoce y pero sin revelar esa información, y que sería casi imposible que un atacante poseyera sin conocer .

También hay que observar que es una cadena única por cada intento de autenticación, o sea que esa cadena siempre está cambiando.

Implementación

Próximamente trabajaremos en una implementación de este esquema para aplicaciones web usando JavaScript y PHP, que publicaremos bajo licencia LGPL.

El método de cifrado de One-Time Pad, que fue inventado en 1917 por el Mayor Joseph Mauborgne y Gilbert Vernam de AT&T. Claude Shannon, 25 años después, se encargó de demostrar con la teoría de la información que este cifrado cumple con ser un secreto perfecto, lo que quiere decir que el contenido del mensaje no puede aportar nada de información a un atacante.

Es un método que sin importar el poder computacional que se tenga o si se haya inventado la computadora cuántica o si los extraterrestres de Andrómeda vengan a la tierra con sus métodos computacionales inimaginables, aún asi será seguro.

Preliminares

Necesitamos una llave de la misma longitud que el mensaje, la cual deberá ser de verdad aleatoria y no pseudo aleatoria. Además esta llave se supone que las dos partes la deben conocer (problema de intercambio de llaves) y cuando una parte cifre el mensaje debe destruir esa llave de alguna forma que no pueda recuperarse y luego enviar el mensaje cifrado, luego la otra parte va a descifrarlo y al terminar de hacerlo debe destruir la llave de nuevo.

Es primordial que no se vuelva a usar la misma llave dos veces pues un criptoanalista podría romper el cifrado sabiendo dos mensajes diferentes que se encriptaron con la misma llave.

¿Cómo funciona?

Es algo muy simple de entender, teniendo el texto:

Teniendo la llave:

El texto cifrado sería:

Porque:

A + R mod 26 = S
M + F mod 26 = S
A + T mod 26 = U


Suponiendo que A vale 1 y R vale 17: 1+17 = 18 y 18 / 26 nos daría como residuo 18, entonces el 18 corresponde a la letra S.

Es importante ver que no puede romperse incluso si pudieramos calcular todas las posibilidades y buscar mensajes coherentes, pues al decifrarlo podría decir SIVOY como NOVOY entonces es imposible saber cual es el mensaje cifrado sin saber la llave. Según dicen, los Rusos cifraron algunos mensajes con este método y siguen hasta la fecha sin poderse descifrar, y así seguirán para siempre.

El problema con este método y en general con cualquier método de cifrado simétrico es el intercambio de llaves, pues ¿cómo podrías intercambiar la clave del One Time Pad de una manera segura?

Fin

Si quieren profundizar más en el tema podrían leer en la página 15 del libro Applied Cryptography escrito por Bruce Schneier que explica con un poco más de detalle este algoritmo.

Con este código en javascript podríamos obtenerlo:

var charCodeCero = ("A".charCodeAt(0))-1;
function oneTimePad(mensaje, llave) {
	mensaje = mensaje.toUpperCase();
	llave = llave.toUpperCase();
	var cifrado = "";
        for(var i = 0; i < mensaje.length; i++) {
		cifrado += String.fromCharCode((( mensaje.charCodeAt(i) - charCodeCero +
                                                 llave.charCodeAt(i) - charCodeCero
                                                 ) % 26) + charCodeCero);
	}
	return cifrado;
}

El NIST, la agencia encargada de definir los estándares tecnológicos para las agencias federales de EEUU, establece que la información con vigencia menor a 2010 debe usar al menos 1024 bits, con vigencia menor a 2030 deberá usar al menos 2048 bits y con vigencia mayor a 2030 deberá usar 3072.

Bruce Scheiner por otro lado en 2002 ratificó una tabla publicada anteriormente por él mismo en donde establece los bits recomendados según seas un individuo, una corporación o el gobierno. Ahí estipula que para 2005 los individuos ya deberían usar llaves de 1280 bits, y el gobierno ya debería estar usando 2048 bits.

Algunos más “inteligentes” que los anteriores, dicen que todos exageran, y recomiendan 1025 bits, razonando superfluamente que eso duplica la complejidad de la factorización. Ese razonamieto surge de pensar que el mejor algoritmo de factorización es por “fuerza bruta” sobre los posibles factores, probando todos los números entre y para factorizar un módulo de 1024 bits, pues sus factores primos son de 512 bits.

La realidad es otra, y desde hace tiempo, desde Fermat de hecho, existen métodos sublineales de factorización de enteros respecto al tamaño del entero y los mismos algoritmos son subexponenciales respecto al número de bits del entero. Por lo que aumentar un bit la llave no es tan drástico como aumentarlo en otros algoritmos como AES, como no es tan drástico multiplicar por dos el tamaño del entero, pues eso no duplicaría el tiempo necesariamente. ¿Pero qué tanto aumenta el tiempo un bit más?

Criba General de Campos Numéricos (GNFS)

GNFS es el mejor algoritmo de factorización de enteros, conocido a la fecha, para enteros de 130 digitos al menos (que son aproximadamente 432 bits). En 2005 el algoritmo se utilizó para romper el récord de factorización RSA para un entero de 640 bits, hazaña que fue llevada acabo por un equipo de investigación alemán. Lo interesante de este algoritmo es su complejidad, y en base a ella voy a realizar algunos cálculos para esclarecer qué tan fuerte es aumentar un bit más a un módulo RSA.

La complejidad del algoritmo está dada por

donde es una constante dada por la heurística utilizada en el algoritmo y es el número a factorizar (no los bits del número). Carl Pomerance, creador del segundo mejor método de factorización, indica que en este caso . Por otro lado tenemos que es una función asintótica que tiende a cero, por lo que para los cálculos se va a considerar como cero, pues Pomerance así lo toma.

Teniendo eso, lo que se puede hacer ahora es calcular el tiempo del algoritmo para factorizar un número de 1024 bits y comprarlo respecto al tiempo para factorizar uno de 1025 bits. Por lo que vamos a denotar al tiempo de 1024 bits y al tiempo de 1025 bits.

Sabemos que un número de 1024 bits se aproxima a y uno de 1025 bits a , por lo que se van a tomar esas aproximaciones para simplificar la exponenciación. Tenemos entonces que

donde es la constante de la notación asintótica.

Por lo tanto tenemos que

Que es muy poco. Pues si el gobierno de algún país contara con los recursos para romper un módulo de 1024 bits en 24 semanas (6 meses), entonces romper uno de 1025 bits les llevaría casi 25 semanas. Esto en el mejor caso, puesto que la complejidad del algoritmo está dada en notación O, así que el algoritmo podría comportarse aún mejor de lo estimado y ser más rápido.

Si hacemos lo mismo y comparamos un módulo de 1024 respecto a uno de 1280, tenemos que . Que es bastante decente, y suponiendo que se pudiera factorizar el módulo de 1024 en una semana, entonces tardarían 8 años y medio en factorizar el de 1280; lo que le da bastante más confiabilidad a ese módulo que a uno de 1025. Aunque un cálculo más correcto sería considerando una ecuación diferencial porque la capacidad de cálculo no va a permanecer 8 años igual, va a ir aumentando.

Pragmáticamente hablando

Seguramente alguno va a desconfiar de este análisis, y necesitará una prueba más terrenal, sin tanta matemática. En ese caso lo invito a bajar un paquete que tenga implementado el algoritmo y factorice un número de unos 450 bits, que se puede hacer en un tiempo bastante decente (unos minutos) y vaya aumentando de bit en bit, para comparar los tiempos. Implementaciones hay varias y se pueden encontrar en la página de la wikipedia sobre GNFS.

Quienes usen mucho la terminal en Leopard se habrán dado cuenta que toda tiene el mismo color, a lo mucho se pueden poner temas pero sigue siendo siempre un solo color para el texto y otro para el background, y en linux, en cambio, tiene diferentes colores para los directorios, archivos ejecutables y demás.

La solución sin instalar absolutamente ningun programa extra es abrir la Terminal y escribir esto:

nano .profile

Lo cual nos abrirá un archivo existente si intenta crear uno nuevo quiere decir que algo salió mal, ahora al final del archivo agregamos las líneas:

alias ls='/bin/ls -G'
export LSCOLORS=ExGxExGxCxGxDxhbHbacEh

Guardamos el archivo:
Presionamos Ctrl + X, nos preguntará si queremos guardar y le decimos que si presionando Y, luego presionamos enter y listo.

Cerramos la Terminal y al volverla a abrir aparecerán los nuevos colores.

Esos colores estan pensados para verse bien con el tema Homebrew y sin iguales a los default de debian, si quieren hacer sus propias combinaciones:
La primera letra representa el color del texto y la segunda el color de fondo:

a black
b red
c green
d brown
e blue
f magenta
g cyan
h light grey
A bold black, usually shows up as dark grey
B bold red
C bold green
D bold brown, usually shows up as yellow
E bold blue
F bold magenta
G bold cyan
H bold light grey; looks like bright white
x default foreground or background


Y la combinación es la siguiente:

Pair 1 (ex) - directories
Pair 2 (fx) - symbolic links
Pair 3 (cx) - sockets
Pair 4 (dx) - pipes
Pair 5 (bx) - executable files
Pair 6 (eg) - block special
Pair 7 (ed) - character special
Pair 8 (ab) - executable with setuid bit set
Pair 9 (ag) - executable with setgid bit set
Pair 10 (ac) - directory writable to others, with sticky bit
Pair 11 (ad) - directory writable to others, without sticky bit


Pueden ver más información en el foro de discusión de apple en la última respuesta

Hace ya varios meses al estar desarrollando un software bastante complejo, que requería una base de datos muy grande, nos enfrentamos al problema de cómo poder visualizar un diagrama entidad-relacion de la forma más legible posible. Intentamos con MySQL Workbench, el cual nos dibujó las tablas con sus relaciones pero desgraciadamente todas juntas y teníamos que acomodarlas a mano; lo cual además de llevar tiempo, es difícil, pues llegar a un modelo que tenga el menor número de cruces y sea fácil de entender es una tarea casi imposible. Así que buscamos en Google un programa que pudiera dibujar de una forma estética nuestra base de datos, y aunque algunos lo prometían ninguno lo hacía.

Historia

Buscamos un algoritmo que se encargara de distribuir gráficas con el menor número de cruces, lo que se conoce como aplanamiento de gráficas y encontramos uno llamado dibujado ortogonal, que nos pareció el más estético para dibujar un digrama EER. Encontramos gran cantidad de documentos de investigación que hacían alusión a un algoritmo publicado por Kandinsky, pero en ninguna parte pudimos encontrar el pseudo código o algún documento más detallado de ese algoritmo. Seguimos buscando y encontramos otros programas que servían para acomodar diagramas UML y algunos con el menor número de cruces. Notamos que muchos usaban un formato de archivo llamado GML y encontramos su especificación. GML significa Graphics Modeling Language y fue un poco difícil de encontrar porque hay otro formato de archivo con el mismo nombre que siginifica Geographic Modeling Language.

Después de un día de búsqueda encontramos un framework para diferentes tipos de dibujado de gráficas llamado OGDF, librería escrita en C++ y de código abierto. Para nuestra sorpresa esa librería recibe un archivo GML para procesarlo y devuelve otro de igual formato procesado.

Idea

Al ver que no había un programa que te hiciera todo el proceso completo, desde conectarse a la base de datos, obtener su estructura, procesarla, graficarla con el menor número de cruces y presentarla tuvimos una idea:

¿Por qué no hacer un programa que obtenga la estructura de la base de datos junto con sus relaciones, genere un archivo .GML y lo pase a un programa que use la librería OGDF, luego lea el archivo procesado y dibuje las tablas en la posición adecuada?

Nuestra solución

- Java
Inicialmente lo solucionamos haciendo un programa escrito en Java, que se conectara a la base de datos MySQL, obtuviera su estructura mediante SHOW TABLES, DESCRIBE tabla, y con el código de creación de la tabla obtuviera las llaves foráneas y se encargara de relacionar las tablas y generar un archivo GML válido con la estructura y las relaciones.

- C++
Ahora mirando en OGDF notamos que había un How To, lo copiamos, modificamos un poco y compilamos, generando un binario que lee dos parámetros, el archivo fuente y la ruta del archivo GML a donde queremos guardar el procesamiento.

- Conectar Java y C++
Nos dispusimos a conectar los dos programas, llamando al binario de OGDF desde nuestro programa en Java y luego nuevamente leer el GML, parsearlo y relacionar con las tablas que estaban en memoria.

Hasta este punto ya teníamos solucionado todo, ahora solo faltaba dibujarlo.

Dibujarlo
Pensamos en un momento dibujarlo en Java, el problema iba a ser que Java no es exactamente lo más amigable para dibujar, y había otro problema, a lo largo del desarrollo del programa pensamos que sería una buena idea liberarlo bajo la GPL y poner el código a disposición de todos y fue cuando se nos ocurrió una idea: ¿porqué no volver todo este programa una aplicación web y abrirla al público?, pero ¿cómo podríamos solucionarlo?

- PHP y Flash
Pensamos que era fácil simplemente crear un formulario que pidiera el acceso a la base de datos, llamara del lado del servidor a nuestro programa en Java y así podríamos generar un XML que leyera una aplicación en Flash, además por medio de Actionscript lo dibujara y agregara comportamientos como arrastrar que hiciera más facil la interacción del usuario.

- Conectar Java, C++, PHP, Flash
Lo hicimos, y nuestro programa en Java después de haber leido y parseado el GML generó un XML con la estructura y coordenadas, que luego Flash leería mediante Actionscript y dibujaría obteniendo una representación interactiva de la base de datos como se muestra en la imagen.

Código Abierto
Después de algunos ajustes liberamos el código de Java, C++, Flash, PHP y Actionscript bajo la GPL y siendo nuestro primer programa que liberamos bajo esa licencia nos sentimos muy felices. Para mi fue como un logro que desde hace tiempo quería hacer, pues siempre nos ha ayudado enormemente el código abierto y nunca habíamos regresado el favor.

Ahora tenemos pensado liberar otros algoritmos y scripts que tenemos guardados bajo GPL, y creamos una sección para todo ese Software en nuestra página, que según tenemos pleaneado irá creciendo poco a poco.

Nos sentimos muy bien de poder colaborar con la Open Software Foundation, e invitamos a otras compañías que tienen mucho software detenido que lo liberen y aporten algo a la comunidad.

La versión en línea de nuestro programa se encuentra disponible al público y esperemos que lo aprovechen.

Con este software nuevo esperamos que este año que apenas comienza aportemos mucho más a la comunidad del software libre.

¡ Feliz año 2009 !

Si creían que Photoshop ya era la octava maravilla, quizá ahora lo sea aún más pues Adobe ha contratado a un colaborador de una nueva investigación sobre escalamiento de imágenes ALUCINANTE: el Dr. Shai Avidan.

El algoritmo fue presentado en la SIGGRAPH 2007 por dos Doctores israelíes en Ciencias de la Computación: Ariel Shamir y Shai Avidan.

Lo que logra este algoritmo es el escalamiento de imágenes con la mínima pérdida de calidad en las regiones más relevantes, detectando éstas de manera automática en un mapa y con la posibilidad de definirlas manualmente. Aquí pueden ver un video con una muestra de su trabajo (vale la pena verlo todo):

Es impresionante, sobre todo al final, cuando eliminan a una persona de la imagen con una sencillez asombrosa.

Casi inmediatamente Adobe contrató a Shai Avidan; no es muy difícil conocer las intenciones de la empresa.

Lo bueno es que su investigación es pública y cualquiera con las suficientes habilidades y conocimientos puede hacer una implementación de su trabajo. Se puede encontrar aquí el documento. Quizá por eso Adobe no perdió tiempo y lo quiere tener integrado en su aplicación puntera lo más pronto posible.

Fuente: Slashdot

En este post les voy a enseñar la maravilla de usar clases en flash, lo mucho que nos ahorran

Actionscript empezó muy parecido a javascript, pero con el tiempo ha ido evolucionando para convertirse en algo más parecido a java, de hecho el Actionscript 3.0 necesita iniciar la máquina virtual de Java para poder correr una pelicula, eso es lo que nos espera lo cual me parece algo muy bueno.

Algo interesante que poca gente usa en flash son las clases, y se pierden de lo útil que puedan ser.

En flash hay veces en que queremos que algún movieclip haga algo al principio, por ejemplo haga fadeIn, o sea vaya apareciendo, para esto es fácil hacerlo con clases y es muy tardado hacer uno por uno.

Tenemos que crear un archivo llamado FadeIn.as, para eso tenemos que seleccionar un nuevo documento de actionscript:

En ese documento ponemos el siguiente código

class FadeIn extends MovieClip {
     private var velocidad:Number = 5;
     /** Constructor **/
     function FadeIn() {
          this._alpha = 0; //el alpha inicia en cero
     }
     /**
     * Esta función hará que cada
     * que pase un frame ejecute el código
     */
     function onEnterFrame() {
          if(this._alpha >= 100) {
              //quitamos la funcion onEnterFrame para que se detenga
              this.onEnterFrame = null;
              //tenemos que asegurarnos que quede en 100,
              //pues hay veces que queda 100.9 u algún otro número
              this._alpha = 100;
          } else {
              //le sumamos la velocidad al alpha
              this._alpha += velocidad;
          }
     }
}

Ya teniendo este archivo debemos de guardarlo en una carpeta llamada clases y con el nombre FadeIn.as

El siguiente paso es hacer que este disponible para lo que necesitemos y para el flash que necesitemos, asi que nos vamos a preferencias del flash y seleccionamos “Actionscript”, hacemos click en el botón “Actionscript 2.0 settings” y agregamos la carpeta clases que acabamos de crear, aceptamos y guardamos los cambios, ahora el efecto estará disponible para cualquier archivo en la parte donde este de nuestra computadora.

Después abrimos cualquier documento de flash y creamos un nuevo MovieClip, haciendo click en “Convert to symbol” y en el botón de advanced, seleccionamos y llenamos tal y como se muestra en la imagen:

Aceptamos y listo ese movieclip cuando exportemos ese movieclip hará fadeIn cuando aparezca en la pantalla.

En el siguiente ejemplo se muestra sólamente como es que todos desde un simbolo al crearse hacen fadeIn: