Archivar por marzo, 2010

Un poco de todo: Google, iPad, JB permanente, Ley “Sinde”, pwn2own…

Share on Google+Share on FacebookTweet about this on Twitter

Unos días atareado y sin mucho tiempo para terminar los temas de seguridad o algunas noticias de interés, así que vamos a hacer un pequeño repaso de lo que ha sido estos días:

 

Por un lado tenemos la sentencia absolutoria a una famosa web de descargas en la que se enlazaba contenido P2P tipo Torrent y búsquedas eMule. La SGAE lleva muchos años denunciando por la vía penal a usuarios/organizaciones que supuestamente hacían un uso indebido de las redes P2P, dado que a su juicio estaban violando la propiedad intelectual. En cambio, el 100% de todos esos juicios habían (y han sido) ganados por los usuarios, teniendo encima que pagar SGAE y otros las costas de los procedimientos y por supuesto perjudicar aun más su imagen. Las sentencias de los jueves eran siempre las mismas: Si no hay un ánimo de lucro, no es delito, el derecho a copia privada nos legitima para ello, por eso pagamos TODOS el llamado canon digital.Tan solo “ganaron” un juicio, aunque realmente no fue una victoria, dado que el afectado decidió llegar a un acuerdo ante la amenaza de la SGAE a un pleito por la vía civil y no penal.

Con los años la SGAE comprendió que la vía Penal no llegaba a ningún sitio. Resumiendo mucho y para que la mayoría lo comprenda (aunque esto no es cierto), digamos que la vía penal es un juicio en toda regla en la que el culpable se expone a prisión por unos actos delictivos, mientras que la vía civil el juicio es algo así como una exposición de los echos para al final llegar a un acuerdo al que obliga el juez, y por ello las resoluciones son casi siempre multas o pagos de dinero. Pues bien, dado que la SGAE no era capaz de “cazar” a estos (según ellos) infractores, cambiaron el modus operante y comenzaron a intentarlo por la vía civil. Este juicio que hacemos eco fue el primero que fue llevado íntegramente por esta vía. Por desgracia de la SGAE imperó el sentido común una vez más, y el juez de nuevo sentenció lo mismo: El uso de una tecnología no puede ser un delito, el derecho de copia privada siempre que no implique un lucro es completamente LICITO. Es decir, de nuevo se pone de manifiesto que descargar contenido audio-visual tanto de redes P2P como de descargas directas es completamente LEGAL en españa, repito, siempre que no exista un lucro. Por ello, las web que alojen material para indexar, buscar… contenidos audio-visuales son igualmente LEGALES.

 

Continuando con las noticias y enlazado con la noticia anterior, el viernes pasado se aprobó la conocida como “Ley Sinde”. Evidentemente es una ley que tan solo afecta a nuestros amigos Españoles. Esta ley a tenido gran revuelo dado que se creará una supuesta “sociedad de control de contenidos” que estará destinada para buscar aquellas páginas web en las que se vulnere la propiedad intelectual. En realidad este comité o sociedad no tiene ningún poder legislativo como los más alarmistas quieren hacer creer, pero tampoco quiere decir que este comité sea una hermanita de la caridad. El cometido de este nuevo comité será como hemos dicho identificar aquellas web que estén violando las leyes intelectuales y remitirlas a un juez de instrucción para poder así agilizar una tarea que de otro modo tardaría meses, con la idea de poder cerrar webs incluso en un período no superior a 4-5 días desde que es detectada la irregularidad. Pero como todo, no es fácil enterarse bien de como será o funcionará, dado que cada sector dice cosas completamente dispares.

De cara a los más extremistas, de llevarse a cabo y funcionar completamente esta nueva ley, no se van a cerrar así como así cualquier web ni muchísimo menos, ni tampoco se va a prescindir de la autoridad de un juez para tomar tales decisiones. Esto no quiere decir que esté de acuerdo, nada más lejos!! tan solo me gustaría aclarar ciertas cuestiones. Como hemos visto en el párrafo anterior, hay que matizar muy bien que podemos entender como una web que vulnere los derechos de propiedad intelectual. Es evidente que de cara a SGAE una web que vulnere estos derechos es prácticamente cualquier web, incluso cualquiera que pueda hablar mal de ellos. La realidad es que las web que realmente podrían ser clausuradas corresponderían a un porcentaje muy pequeño, web que obtienen un beneficio económico (ya sea por registro o por publicidad o por…) gracias a tener en sus web contenido sujeto a la propiedad intelectual.

De cara a los menos alarmistas, me parece una desfachatez increíble que se pueda aprobar una ley como la que nos encontramos. En realidad no por su finalidad, sino por su forma. Está todo demasiado politizado, y tanto unos como otros en el gobierno están más preocupados por ellos mismos que por los ciudadanos. El gobierno central por un lado más centrado en el que dirán y defendiéndose de la oposición que simplemente gobernando. Y la oposición peor aun… lo único que saben hacer es criticar y hacer demagogia de todo. El canon lo impuso el PP hace algunos años… ahora dice que lo quiere eliminar. Existe una realidad… es cierto que encontrar un equilibrio o una ley que satisfaga a todos en este tipo de materias es imposible. Por un lado las sociedades de gestión que lo único que les sucede es que no dejan de llorar porque ahora no ganan los millones y millones que ganaban antes, así como las discográficas… cuando los artistas a día de hoy están ganando más que nunca!!. Por otro lado aquí en españa las personas están acostumbradas a que ley o no ley se hace lo que le da la gana a uno sin importar el otro. Y señores… no es ni lo uno ni lo otro.

Como decía… y terminando con la polémica ley Sinde, me parece una broma de mal gusto por parte del gobierno el conformar una supuesta comisión que estará casi seguro constituida por marionetas de SGAE y asociados, y que intentarán por todos los medios cerrar web tras web por medio de esta ley. ¿Que sucederá? Es complicado… por un lado la última palabra la tiene un juez y teniendo en cuenta las decisiones pasadas no me creo que a estas alturas un juez de el visto bueno para cerrar una web que sea legal. Más que nada porque a la segunda web que cierren rápidamente veremos sentencias en el constitucional y apelaciones. Por otro lado es cuestionable si una ley así es constitucional o no, dado que está cercenando el derecho de expresión (sea cual sea), es volver a la censura. Es decir, me temo que antes o después es muy posible que la ley sinde si se queda tal cual está acabe en el constitucional, de lo contrario apenas tendrá efecto en las web.

Queda otro punto a tratar, y dice mucho sobre la posible efectividad de la ley. Imaginar que efectivamente una web está violando de forma descarada las leyes de propiedad intelectual… la web en cambio lo más seguro es que no esté alojada en españa, ni siquiera el dominio sea español, luego nuestras leyes no pueden ser aplicadas. Es más, las pocas web que pudiesen verse afectadas ante esta ley es solo cuestión de tiempo que simplemente cambien el dominio o el hosting a otra compañía, tan sencillo como eso.

 

En otro orden del día tenemos el iPad de Apple. Supuestamente arrancó con fuerzas pese a todos los pronósticos. Esto en realidad no es así. De nuevo las estadísticas se manejan como uno quiere. Supuestamente vendieron 120.000 unidades el primer día, pero esto no es cierto. Esta cifra fue sacada realizando un seguimiento a un número determinado de supuestas ventas en un período corto de tiempo, creo que fue de una hora o dos horas. El resultado obtenido fue extrapolado indistintamente al resto de las 24 horas del día. Es decir, pongamos por ejemplo que durante 60 minutos podemos conocer el número de ventas exactamente del iPad en su fecha de lanzamiento. Pongamos que en esa hora se logran vender 5000 unidades. Lo que se hizo fue simplemente extrapolar las ventas a las 24 horas que tiene un día. Si en 1 hora se venden 5000 unidades en 24 horas se venden 120.000. Evidentemente no hay que ser un genio para darse cuenta el fallo de este método. Para empezar se está dando por echo que para bien o para mal la hora en la que se ha llevado a cabo la captura de datos no será jamás igual a otras horas. Si la hora muestreada es las 10.00 de la mañana habrá más ventas que si es las 03.00 de noche, e igualmente si los datos son tomados a las 03.00 de la noche no podrían ser comparables a las ventas registradas a las 12.00 del medio día.

De nuevo aparece lo que conocemos como márketing. Muchas veces no se trata de mentir, sino de mirar bien la letra pequeña. En realidad el dato es cierto según ciertas premisas. Cuando se publicó el estudio REAL se indicaba perfectamente como se había llevado a acabo esta estadística. En cambio lo que llega prácticamente a TODA LA PRENSA es otro dato. Se omite todo y tan solo se dice que es un éxito de ventas. A lo que yo me pregunto… ¿Es que nadie se pregunta como o de donde salen dichas cifrar?¿Las personas creen de verdad que es un dato que hace público Apple? Es un estudio realizado por una empresa y posiblemente incluso la captura de datos durante esos 60 minutos es realmente discutible. ¿Conclusión? De nuevo vemos lo que es la desinformación y de como se manipula la información para hacer creer lo que no es. ¿Es posible que se alcanzaran dichas ventas? Claro que sí, no he dicho en ningún momento lo contrario. Pudieron ser 120.000 y pudieron ser 240.000, pero también pudieron ser 50.000 ó 20.000. El único que tiene el dato real sobre esto es Apple, y evidentemente no va a hacer público este dato en mucho tiempo.

 

Por otro lado tenemos que hablar sin falta de Google. Por un lado tenemos que el sistema Android continúa la escalada, y más del 70% de los desarolladores de iPhone estarían comenzando la migración a Android. Por otro lado no hay que olvidar los nuevos problemas legales que va a tener Google debido a que el registro de “Nexus One” estaba ya cogido. Sinceramente estoy muy en desacuerdo con las compañías. ¿Tan complicado resulta conocer si dicho nombre está registrado o no? Es muy simple, pero las grandes empresas se aprovechan de su “poder” para pasar por alto por otras empresas. A google le ha sucedido con Nexus One, pero a Apple con el iPad le pasó por partida doble incluso!! y anteriormente también con el iPhone. Señores, más seriedad, me parece una práctica despreciable.

Pero sin duda alguna la noticia de mayor calado estos días dentro de Google es lo que ha sucedido en China. Para quien no lo sepa, el régimen comunista de Chine tiene implantados por ley fuertes filtrados de contenidos. Obliga a buscadores y otros filtrar todo contenido que pueda ser inapropiado para su pais. En realidad eso de “inapropiado” podríamos matizarlo. En realidad China filtra cualquier contenido que pueda hacer pensar a los chinos por si mismos y ocultar las barbaridades que ha cometido el gobierno chino. Supongo que la matanza de Tiananmen es el mejor ejemplo de ello y de la represión China. El gobierno chino piensa que si la información no está disponible para sus ciudadanos, es equivalente a decir que dichos echos jamás sucedieron.

Pues bien, debido a los últimos ataques sufridos por Google en Enero (de los cuales todo apunta que pudo ser el propio gobierno chino quien los llevó a cabo) Google anunció que por su parte la censura acabaría en China y no filtraría más sus contenidos. El gobierno Chino fue claro, si Google no acataba las leyes Chinas, que se fuese del país (lo cual es completamente lógico). Despues de algunos meses de diálogo ninguno a dado el brazo a torcer, y hace ya unos días que Google dejó de filtrar los resultados en su web www.google.cn. A partir de dicho momento, cualquiera que acudía a dicha web era dirigido a la web a www.google.com.hk, la cual está alojada en Hong Kong. Hong Kong pertenece a china pero es una colonia independiente, en la que los buscadores en realidad no tiene por qué filtrar los contenidos. Evidentemente solo era cuestión de tiempo que el gobierno chino comenzara a bloquear y filtrar el contenido de dicha web también.

No obstante, sea como sea, si todos tomasen el ejemplo de Google quizás las cosas podrían ser diferentes. La censura es algo retrógrado y que atenta con cualquier principio o derecho fundamental humano desde mi punto de vista. Tan solo celebrar la decisión de Google y esperanza que otras grandes empresas que realmente tienen poder y peso en otros paises tomen medidas. Efectivamente hay que acogerse a las leyes de otros paises, pero existe otra posibilidad. Irte del pais y demostrarle que tienen que cambiar. El problema es que China es un problema, dado que recordemos son más de 1500 millones de habitantes, es decir, más de un cuarto de la población mundial.

 

Dentro del iPod Touch/iPhone decir que se ha logrado el JB permanente en aquellos modelos en los que hasta la fecha no era posible, y de nuevo ha sido de la mano de George Hotz. No obstante no parece que se vaya a dar prisa en modo alguno de publicar el método. Es posible que se esté esperando que el iPad esté ya asentado para que este método afecte igualmente al iPad. Pero lo importante es que ya es posible, aunque no esté al alzance de cualquiera el poder hacerlo.

 

Para finalizar, tan solo hacer un par de noticias curiosas de estos días en la concurso pwn2own, en el que se reunen hackers y expertos de seguridad para llevarse suculentos premios en metálico al lograr el acceso a ciertos recursos por medios de exploits. Como es costumbre, los primeros sistemas en caer fueron los de Apple, tanto MAC OS Snow Leopard como el mismo iPhone, ambos completamente actualizados. En el caso de Snow Leopard exploits tanto de Safari como del OS mismo que permiten el control total del sistema. En caso de iPhone exploit por parta de Safari que permitió a los hacker extraer la agenda y los SMS del usuario simplemente cuando este visitó una web maliciosamente creada. Más tarde le llegaría el turno a IE 8, Chrome y también Firefox. En este caso los que han salido mejor parado (aunque no intacto) han sido Windows 7 y Opera. Una vez más resultados relativamente esperados. Dejo algunas conclusiones:

“Here’s one more piece of evidence that the Mac isn’t the secure, locked-down system that its proponents claim. The organizer of the Pwn2Own hacking contest says that Windows 7 is more secure than Snow Leopard, and that Safari will be the first browser to fall victim in the upcoming hacking contest.

“Safari will be the first to go. [Safari will] be on Snow Leopard, which isn’t on the same level as Windows 7.”

Last year at the contest, it took only five seconds for a security researcher to hijack a Mac by hacking in through Safari. The year previous, it took less than two minutes to hack in to a Macbook Air — and once again, Safari proved to be the security hole.

Resumiendo? Básicamente se dice que aunque por fin Apple implementó DEP en Snow Leopard (tecnología ya explicada en este blog y que ya está presente en Windows desde XP SP2) Snow Leopard continua siendo mucho más inseguro que Windows 7. Pero más aun, no solo Snow Leopard es mucho más inseguro, sino que Safari se ha consolidado como el navegador más inseguro y peligroso para usar. Parece paradógico que aquello que Apple ha intentado una y otra vez hacer creer, es todo lo contrario, y de nuevo una vez más en un concurso de seguridad informática se demuestra lo contrario, se demuestra que acceder a un sistema MAC OS es mucho más sencillo que un sistema Windows.

Seguridad: Encriptación y Autentificación. Índice (Actualizado)

Share on Google+Share on FacebookTweet about this on Twitter

Bienvenidos al tema de Hoy: Encriptación y Autentificación, la seguridad ante todo.


Hoy dejamos todo aquello del Spoofing de lado y entramos en el mundo de la encriptación y la autentificación. Dos términos muchas veces parejos, pero muy diferentes. La encriptación es la forma de modificar los datos para que estos esté protegidos, cifrados… la autentificación por el contrario no implica un cifrado, sino un reconocimiento de la identidad, al menos por parte de uno de los implicados, ya sea de un sistema, de un usuario…

En realidad este debería de haber sido el primer artículo, por encima de Spoofing. Todo lo que se vea aquí será aplicado, tratado y mencionado en cualquier otro artículo con casi total seguridad. Aquí hablaremos de las medidas tecnológicas que poseemos para evitar cualquier tipo de inseguridad en la red y por supuesto también de las herramientas disponibles para poner en jaque estas medidas tecnológicas:



Herramientas Utilizadas/Material necesario: (No todo es necesario, dependiendo de la plataforma a usar, de cada sección y de lo que a cada cual le sea más cómodo)

Seguridad: Encriptación y Autentificación. Capítulo Quinto -> Ataques y Vulnerabilidades contra la Criptografía

Share on Google+Share on FacebookTweet about this on Twitter

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Ataques y Vulnerabilidades contra la Criptografía

Para acabar con el tema de Encriptación y Autentificación, es obligado mostrar sus vulnerabilidades. Es cierto que muchos de los ataques y vulnerabilidades de la criptografía son simplemente teóricos, se conocen que son efectivos pero no es posible llevarlos a cabo por una u otra razón. No obstante, es una búsqueda constante. En el mundo existen increíbles criptólogos con una formación en matemáticas y en la creación de algoritmos seguros sin igual. Pero como todo en esta vida nada, y repito nada, está exento de posibles ropturas.

En realidad esto es importantísimo, tanto las mentes que son capaces de diseñar algoritmos como los que tenemos como aquellos que pasan horas y horas intentando lograr un ataque exitoso contra un sistema criptográfico. Porque así es la única forma real de poder construir sistemas seguros. Si nadie se dedica a estudiar estos sistemas, es posible que diversos atacantes puedan disponer de herramientas y materiales para poder llevar a cabo un acceso no autorizado a un sistema o la interceptación y descifrado de cualquier mensaje. En cambio, cuando tienes a muchísimas personas que trabajan incluso para ello, para lograr fallos de seguridad en estos sistemas, estos mismos intentos te están garantizando que el sistema es seguro, puesto que aun no se han logrado romper. No hay que olvidar por supuesto los numerosos concursos anuales de criptografía, en los que se están desafiando constantemente a organizaciones y particulares a resolver un problema dado, por ejemplo revertir un cifrado asimétrico o simétrico, revertir un Hash…

Por suerte y por desgracia, no son pocas las herramientas, método o sistemas que existen actualmente para poner en jaque la seguridad de todos los sistemas actuales. Suerte porque permite mejorar los sistemas, desgracia porque estos métodos son usados continuamente por hackers y otros para violar un sistema. Vamos a ver algunos de ellos. Podemos decir que prácticamente cualquier método “seguro” tiene un posible ataque que puede aplicarse para romper dicho sistemas:

  • Colisiones y preimagen
  • Rainbow Tables
  • Brute Force Y Diccionarios
  • Criptoanálisis
  • Ataques Side Channel

El término “Criptoanálisis”, dependiendo de la bibliografía a la que se acuda, puede ser interpretado como un término genérico que englobaría prácticamente a todos los sistemas de ataques contra la criptografía. No obstante, nosotros lo entenderemos como un conjunto de técnicas basadas en el análisis puro y duro de ciertos aspectos del cifrado para poder romperlo.

El término estrella aquí es ¿Qué es un ataque? ¿Qué se considera romper un sistema criptográfico?
Esto se dejó ver en otros capítulos. Un ataque es cualquier intento que tenga como objetivo romper un sistema criptográfico, entendiendo con “roptura” no solamente la obtención de la clave de dicho cifrado o de invertir un hash o… Una roptura criptográfica es un concepto amplio, en el que evidentemente el mejor de los casos e ideal pasa por lograr obtener la clave en caso de un cifrado simétrico o asimétrico, pero como hemos dicho, no solo se interpreta una roptura por ello. Una roptura criptográfica podría implicar:

  • Obtención de la clave simétrica (en caso de un cifrado simétrico)
  • Obtención de la clave pública (en caso de un cifrado asimétrico)
  • Obtención completa o parcial del mensaje original a partir de un mensaje cifrado sin necesidad de la clave.
  • Encontrar algoritmos capaz de rebajar en X magnitudes la probabilidad de tener éxito con fuerza bruta o colisiones.
  • Una colisión en un Hash.
  • Encontrar algoritmos capaz de rebajar en X magnitudes la capacidad de cálculo necesaria para poder solucionar las “matemáticas imposibles”
  • etc…

Esto implica que una roptura puede verse como tal desde un punto de vista práctico o teórico. Así por ejemplo si se encontrase una forma de romper AES-128 en 2100 Operaciones en vez de 2128 , constituiría una roptura desde el punto de vista teórico, pero no desde un punto de vista práctico, puesto que aun así sería “imposible” realizar un ataque para obtener una key en un tiempo razonable. Visto esto podemos comenzar a ver algunos de los ataques más usuales, algunos de los cuales ya se han visto por encima.


Colisiones y Preimage

El concepto de Colisiones fue tratado en parte en el capítulo sobre Hash. Un Hash criptográfico pretende ser una función de un único sentido, siendo por tanto imposible a priori invertirlo. Un hash por otro lado funciona como un sistema de “compresión”, dado que para cualquier tamaño de datos de entrada, la salida siempre se mantendrá con una longitud fija. Por definición propia, si la longitud del Hash es fija existirán infinitos mensajes que puedan resultar en un mismo hash. Simplemente conociendo la longitud del hash, podemos conocer a priori el número de mensajes máximos que podrán emitirse antes de que un mensaje produzca un hash repetido. Esto es una Colisión. Los Hash criptográficos intentan no obstante la imposibilidad de poder crear dos mensajes diferentes que compartan el mismo hash ó crear un mensaje diferente a otro para que compartan el mismo hash. Pero como hemos dicho, se tienen en cuenta a la hora de crear los hash para que en la práctica no sea posible, dado que en la teoría simplemente por estadística esto no es así.

Así mismo, también hablamos del problema que entrañaba la paradoja del cumpleaños, la cual hace posible que existan colisiones entre dos mensajes cuales quiera a una razón mucho menor al número total de mensajes posibles. Es decir, la probabilidad de que un mensaje coincida con otro para MD5, el cual es un hash de 128 bits, sería 1 entre 2128. No obstante, la posibilidad de que dos mensajes cualesquiera puedan producir una colisión, simplemente por la paradoja del cumpleaños, se debe de calcular.

Estadísticamente, tomados X elementos de un todo Y en el cual esos X elementos pueden ser repetidos, se tiene que para la probabilidad P, existen dos elementos de X que son él mismo, según la fórmula:

X(P,Y)= Raiz (2Y Ln (1/1-P))

MD5 = 128 bits = Y
P = 99% = 0.99 = > Nunca se puede garantizar una probabilidad del 100%

X(99%, 2128) = Raiz ( 2129 Ln (100))= Raiz (2129 * 4.6) = 265 Aproximadamente.

Pero la paradoja del cumpleaños tan solo es un reto más al que tienen que enfrentarse cualquier Hash criptográfico. Al margen de este tipo de análisis estadístico, se suele atacar al algoritmo propio, logrando en muchos casos unas reducciones increíbles en la posibilidad de encontrar una Colisión. Por suerte o desgracia, para MD5 “recientemente” se logró reducir el índice de colisión a tan solo 210. Y este índice si deja de ser un índice teórico y pasa a ser una aplicación práctica.

¿Pero que importancia tiene esto?
Si recordamos, la firma digital no es más que el cifrado asimétrico del hash del propio mensaje/certificado…. Si se produjese cualquier cambio en dicho mensaje, al comprobarse la firma el hash no coincidiría, el mensaje sería rechazado. ¿Pero que sucedería si pudiésemos construir dos mensajes diferentes que produjesen el mismo hash?. Podría malignamente enviar un mensaje A al usuario X, y esperar que este me firmase el contenido. Dado que dispongo de un mensaje B (completamente diferente a A) que satisface al mismo Hash, podría copiar la firma del mensaje A y plasmarla en mi mensaje B. Ahora podría usar mi mensaje B como si hubiese sido firmado por el usuario X.

Similarmente, es posible intentar vulnerar un hash por medio de un ataque conocido como “preimage” (preimpagen). Mientras que las colisiones buscan encontrar dos mensajes cuales que produzcan el mismo Hash, una preimagen lo que busca es encontrar un hash o un mensaje concreto. Asi, si se de lo que se pretende es de encontrar un mensaje X que satisfaga un Hash dado estaríamos ante un “Primer Ataque de Preimagen” (Se denomina así). No obstante, si lo que se quiere lograr es encontrar un segundo menseje Y (diferente a X) que satisfaga el hash del mensaje X, estaríamos ante un ataque conocido como “Segundo Ataque de Preimagen“.

En la actualidad no existe ningún ataque de preimagen factible a ningún Hash. Así por ejemplo, el Hash MD4 (128 bits) posee un ataque de preimagen que puede llevarse a cabo en 264, pero aun así, 264 no es computacionalmente factible, teniendo en cuenta que MD4 está prácticamente en desuso. Si es computacionalmente posible realizarlo de cara a que puede ser posible llevarlo a cabo, pero de ninguna manera en un entorno real.

Tanto las Colisiones como los ataques de preimagen, suponen un riesgo continuo a los hash criptográficos. Es la razón por la que los viejos Hash van dejando paso a los nuevos Hash. MD2, MD4… MD5 ya ha comenzado a dejarse de usar en muchos lugares, imponiéndose de forma mayoritaria SHA-1, para el cual lo mejro que se ha logrado es una colisión con u índice de 251, siendo poco práctico su aplicación. A todo ello hay que sumarle que pronto estará disponible SHA-3, que sustituirá definitivamente SHA-1 y SHA-2 (este último posee índices de colisión menores que SHA-1)

 

Rainbow Tables

La idea de las tablas Rainbow es imitar las tablas lookup, es decir, usar espacio en disco para ahorrar tiempo de cálculo. En programación, las tablas lookup son una herramienta fundamental para agilizar muchísimas tareas que de otro modo consumirían muchísimo tiempo de ejecución de un programa. A groso modos, son tablas precalculadas que serán usadas posteriormente, sin que sea necesario realizar el cálculo que llevó el crearlas. El ejemplo más simple quizás sea en de las operaciones trigonométricas.

Si tenemos un programa que tenga que calcular en algún momento alguna operación trigonométrica, simplemente podría ser realizada con la función especifica para ella: Sin(X), Cos(Y).. operación que se realiza en tiempo de ejecución por el procesador, y que son operaciones normalmente costosas. Si nuestro programa debe de realizar una operación trigonométrica de forma aislada no importa, pero imaginar que el programa tiene que ejecutar operaciones trigonométricas a matrices inmensas (por poner un ejemplo). El tiempo invertido en calcular constantemente dichas funciones puede ser solventado usando una tabla. Simplemente, en tiempo de programación, el programador creó una tabla con por ejemplo 360 elementos, y a cada uno de ellos le calculó el Coseno. Dicha tabla estática la implementa en su programa como una constante. Si no requiere una precisión mayor a un grado, el programador cada vez que necesita conocer una razón trigonométrica podría simplemente redondear a la unidad más cercana y usar dicho valor como índice de la tabla. Tendría el valor de la razón trigonométrica al instante sin necesidad de calcularlo.

El concepto de una Tabla Rainbow es el mismo. Por tanto, la tabla Rainbow más simple (e idílica) sería precalcular TODOS los posibles Hash de todas las combinaciones posibles de un alfabeto dado de un número de caracteres dados. Es decir, si nuestro alfabeto son tan solo los números 0-9 y se permite una longitud máxima de 5 elementos, la tabla Rainbow contendría el Hash de 1 millón de elementos, desde el 0 hasa el 999.999. De este modo, si se quisiese conocer en cualquier momento el hash de cualquier número comprendido entre 0-999999 sería instantanio, sin necesidad de calcular el Hash de dicho número. Pero en el caso de los Hash la utilidad es doble. La utilidad es dotar a la función Hash de un camino inverso. En nuestro caso, si sabemos que el dato buscado es un número comprendido entre 0-999.999 no tendríamos que realizar 1 millón de operaciones, tan solo realizar una búsqueda en la tabla para encontrar la equivalencia.

El problema de esta tabla Rainbow de ejemplo es que no es útil. en este caso, para 5 elementos y un alfabeto de 10 elementos (0,1,2,3,4,5,6,7,8,9) tendríamos una tabla con un millón de elementos. Si por ejemplo el Hash calculado fuese MD5, sería 128 bits por hash, es decir, el Hash ocuparía 16 Bytes por cada celda del array (de la tabla). En el mejor de los casos (en este caso concreto), podríamos usar el mismo número buscado como índice de la tabla, con lo que no sería necesario otra celda de al menos 4 Bytes. Es decir, en este casi tan simple tendríamos: 1 millón de elementos * 16 Bytes = 15.26MB aprox. Es decir, en este caso tan simple sería necesaria la friolera de 15MB de espacio en disco. Esto es una cantidad irrisoria en los días de hoy, pero también es cierto que los elementos y el alfabeto seleccionado es de lo más trivial. Si pensásemos en un alfabeto comprendido entre 0-9, a-z (sin contar carácteres en mayúscula) y con una longitud de 8 elementos tendríamos la nada despreciable cantidad de 2.821.109.907.456 posibilidades, o lo que es lo mismo, aproximadamente una tabla de 328 TeraBytes. Es evidente que no es factible.

La solución a este problema llega con “Divide y Vencerás”. Se crean tablas muy grandes, pero para salvaguardar tamaños tan extensos se aplican diferentes técnicas que logran reducir el tamaño a costa evidentemente de tener que realizar ciertas operaciones. El problema siempre será el mismo, llegar a un compromiso entre velocidad-espacio en disco. A tablas más grandes, el tiempo necesario para localizar el elemento será menor, a tablas más pequeñas el tiempo empleado será mayor.

Las tablas Rainbow para lograr este compromiso, lo que realizan es aplicar una serie de transformaciones a los datos de entrada, formando una cadena desde estos (el dato de entrada) hasta un dato final. Al finalizar el proceso, la tabla tan solo contiene el elemento inicial y el final de la cadena. Para verificar si un hash se encuentra en la tabla, lo primero que se le realizará a dicho Hash es aplicar la última transformación (de reducción) que se aplicó en la cadena de la tabla hash. El resultado será buscado en los elementos finales de la tabla Hash. Si el elemento se encuentra, se partirá del elemento parejo de la tabla, al cual se le realizarán las transformaciones pertinentes que se aplicaron a la tabla originalmente, hasta encontrar en la cadena el elemento deseado. Si no se encuentra en la tabla al realizar la última transformación, se partirá de la penúltima transformación y posteriormente la última. Al terminar se vuelve a comprar si se encuentra como elemento final. Estas transformaciones se tratan fundamentalmente en partir de un texto plano cualquiera, por ejemplo la cadena “aaaaaa”. A dicha cadena se le calcula el Hash. Al Hash resultado se le aplica una función de reducción que hace que el hash sea transformado en un texto de nuevo (aunque esta función de reducción no es la función inversa del Hash). Al texto obtenido se le calcula de nuevo el hash y así continuamente, según el número de reducciones que se estén aplicando. A más reducciones menor es la tabla necesaria y más tiempo se requiere para generarlas y utilizarlas. Un ejemplo sencillo de como se construiría una tabla hash y cual sería la tabla Hash resultante final:

Texto Plano Hash Original Reducción 1 Hash 1 Reducción 2 Hash 2 Reducción 3 Texto Plano Reducción Final
aaaaaa 0B4E7A0E5FE8 0B4E7A EBC4C39A693E EBC4C3 D54E764C3A8A D54E76 aaaaaa D54E76
bbbbbb 875F26FDB1CE 875F26 B0A1E4DDF443 B0A1E4 8B701D6DA922 8B701D bbbbbb 8B701D
Administrador 2A2E9A581027 2A2E9A BC291090759A BC2910 D605381C2106 D60538 Administrador D60538
Contraseña B489B4014A83 B489B4 6BA499D1C52C 6BA499 A996250124DD A99625 Contraseña A99625

Las 7 primeras columnas de la tabla serían datos procesados para la creación de la Rainbow table. En este sencillo ejemplo se usarían solo 3 reducciones. Al texto de entrada se le aplica el hash deseado, en el ejemplo un hash MD5 truncado a los 6 primeros bytes. Una vez se ha calculado el hash este es convertido por una función de reducción a “texto plano”, en este caso la función de reducción no es más que tomar del hash los primeros 3 bytes (de ahí lo de divide y vencerás). Una vez finalizada la primera reducción se vuelve a empezar, es decir, se calcula de nuevo el hash al nuevo “texto plano” y otra reducción, después se le calcula el hash y de nuevo otra reducción. En este caso 3 reducciones, y las 3 actúan del mismo modo. La tabla Hash es constituida por tanto tan solo con los registros iniciales (el texto de inicio) y el resultado de la reducción final, formando una tabla tan solo de dos columnas.

Si un usuario quisiese atacar un hash MD5 con el ejemplo anterior, tan solo tendría que llevar a cabo una serie de comprobaciones:

a) Dado el Hash “H” de entrada se le aplica la última función de reducción. En este caso las 3 son iguales -> R (H)
b) Se realiza una búsqueda del resultado obtenido en el apartado anterior en la segunda columna. Llegados a este punto pueden suceder dos cosas. Hay una coincidencia (Saltar al paso E), no hay coincidencia (pasar al paso C)
c) De no obtener resultado, se iran realizando en cada paso una reducción anterior más, con su cálculo de Hash, de este modo, a cada paso se va recorriendo más la tabla hacia atrás. En el peor de los casos, se tendría que aplicar la reducción primera al hash H, calcular el hash a la reducción, volver a reducir, volver a calcular hash y volver a reducir.
d) De no lograr una coincidencia, la tabla rainbow a fallado y el ataque se da por fallido.
e) Si se encuentra la coincidencia, se tomará el elemento de la primera columna y se comenzará a realizar la cadena hasta que se localice la reducción que produce dicho hash. El resultado por tanto será la reducción.

Veamos esto. Imaginar que tenemos el nombre de usuario y contraseña de un usuario en este MD5 inventado, y que dichos hash son:

Usuario (U)= 2A2E9A581027
Contraseña (C)= EBC4C39A693E

2A2E9A581027 -> Red. 3 (U) = 2A2E9A -> Búsqueda en 2º columna de Tabla -> Fracaso
2A2E9A581027 -> Red. 2 (U) = 2A2E9A -> Hash = BC291090759A -> Red. 3 (Hash) = BC2910 -> Búsqueda en tabla -> Fracaso
2A2E9A581027 -> Red. 1 (U) = 2A2E9A -> Hash = BC291090759A -> Red. 2 (Hash) = BC2910 -> Hash = D605381C2106 -> Red. 3 (Hash) = D60538 -> Búsqueda en tabla -> Éxito!
Registro asociado a D60538 = Administrador
Hash (Administrador) = 2A2E9A581027 -> ¿2A2E9A581027 = 2A2E9A581027? -> Usuario (U) = Administrador

EBC4C39A693E -> Red. 3 (C) = EBC4C3 -> Búsqueda en 2º columna de Tabla -> Fracaso
EBC4C39A693E -> Red. 2 (C) = EBC4C3 -> Hash = D54E764C3A8A -> Red. 3 (Hash) = D54E76 -> Búsqueda en tabla -> Éxito!
Registro asociado a D54E76 = aaaaaa
Hash (aaaaaa) = 0B4E7A0E5FE8 -> ¿0B4E7A0E5FE8 = EBC4C39A693E? -> Fracaso
Hash (aaaaaa) = 0B4E7A0E5FE8 -> Red. 1 (Hash) = 0B4E7A -> Hash = EBC4C39A693E -> ¿EBC4C39A693E = EBC4C39A693E? -> Contraseña (C) = 0B4E7A

En este caso, todas las reducciones son iguales, pero esto normalmente no es así, y cada reducción es una función diferente. Si se recorre la tabla hash completa y se realizan todas las iteraciones sin encontrar coincidencia, la tabla Rainbow ha fallado, y con ella el ataque efectuado a dicho hash.

Este sistema es increíblemente efectivo y rápido para ser capaz cualquier atacante a revertir cualquier hash “simple”, de modo que un atacante pueda normalmente obtener el usuario o contraseña que originó dicho hash. No obstante las tablas Rainbow tiene una utilidad relativa. Primero, computar una tabla hash relativamente completa requiere de muchísimo tiempo, es por ello por lo que no es raro encontrar tablas “pequeñas” que cubren tan solo un espacio relativo, por ejemplo una tabla Rainbow que sea capaz de revertir cualquier Hash MD5 con un diccionario de a-z, A-Z de hasta 7 caracteres. Y ya no solo es el tiempo necesario para computarla, sino el espacio en disco. Dado que tanto el espacio para calcular las tablas hash, así como su tamaño en disco depende prácticamente tan solo del tamaño del diccionario, algo que tendría que tener siempre en cuenta el usuario es escoger contraseñas o nombres de usuario de una longitud relativamente larga (al menos 8 caracteres para contraseñas) y usando combinaciones de letras mayúsculas, números y signos. Esto lo comprenderemos mejor en los ataques de fuerza bruta. La idea es que aunque se requiera de un tiempo ingente necesario para precalcular las tablas Rainbow, una vez creadas estas pueden ser reutilizadas una y otra vez. Existen multitud de lugares que venden tablas rainbow ya creadas.

Otra alternativa altamente eficaz, es usar Salt. Esto es algo que ya se comentó en su momento. Salt suele ser un número determinado de bits que se añade al mensaje de entrada para conformar un hash mucho más seguro. De este modo entre otras cosas, hace que las tablas rainbow sesan completamente ineficaces. La única forma sería constituir nuevas tablas rainbow computando todas las alternativas posibles con el Salt. Dado que el Salt puede ser modificado en cualquier momento, las tablas Rainbow tendrían que ser reconstruidas cada vez. Salt suele ser un dato conocido, pero no por que sea conocido implica que el sistema sea menos eficaz. Según lo explicado con anterioridad, si se añadiese un número indeterminado de bits a nuestro mensaje original, este no podría ser revertido por la tabla hash, puesto que jamás se encontraría en ella. Normalmente se usa algo como lo siguiente:

Contraseña: Perico -> Hash (Contraseña) = 5E48C54D938DC613366C1212E5FA7349
Salt: 0A1B2C3D4E5F
Hash Seguro = Hash (Contraseña.Salt) -> Hash Seguro = Hash (Perico.0A1B2C3D4E5F) = 21208C690B7ECCF92518D8055E9B361D

El segundo Hash no sería jamás encontrado en una tabla Rainbow, a menos que se hubiese generado para tal efecto, cosa muy poco probable. Dado que la Salt suele cambiar, lo normal es que el mismo hash es transmitido con la salt, para que se sepa que Salt se ha usado, y se tenga en cuenta a la hora de verificar el usuario o la contraseña. Por ello podría enviarse la contraseña mediante un Hash con Salt como:

21208C690B7ECCF92518D8055E9B361D.0A1B2C3D4E5F

Es decir, se adjunta la Salt.

Actualmente no obstante las tablas rainbow continuan siendo bastante útiles. Por ejemplo, pensar en los nombres de usuarios y contraseñas de Windows, los cuales son almacenados con un hash conocido como Hash NT. Use o no use Salt dicho hash, ya existen tablas precomputadas increiblemente eficaces capaces de revertir casi cualquier contraseña menor a 13 caracteres, use los caracteres que use.

Para acabar, vamos a ver como es posible revertir un Hash gracias a estas tablas. Vamos a ver lo “simple” que puede ser revertir un Hash MD5 que se ha enviado desde un PC cliente a un servidor para la autentificación en un foro o a un correo electrónico. Dado el tiempo necesario para precalcular una tabla hash “completa”, vamos a crear una tabla rainbow muy pequeña. En este caso he usado el software del proyecto RainbowCrack:

Caracteres: Letras minúsculas, es decir, de ‘a’ a la ‘z’
Longitud Mínima: 1
Longitud Máxima: 7
Indice de éxito: 98% de acierto
Cantidad de Cadenas por tabla: 4.000.000
Longitud de cada Cadena: 2.400
Tablas necesarias: 6
Tiempo de cómputo de las tablas: 6 Tablas *5 minutos por tabla = 25 min
Tamaño Total de las tablas: 366 MB, 61 MB por tabla

Línea de Comando usada:

C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 0 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 1 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 2 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 3 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 4 2400 4000000 0
C:\Users\Theliel\Desktop\rtgen md5 loweralpha 1 7 5 2400 4000000 0

Una vez las tablas han sido creadas y preparadas, tan solo es necesario introducir el hash que se desea invertir. La utilidad de dividir una tabla rainbow en trozos no es otro que evitar generar un solo archivo monstruoso, de esta forma es facil crear tablas rainbow con la ayuda de muchos voluntarios, cada uno por ejemplo podría generar una sola tabla. Con las tablas generadas, deberíamos de ser capaces de invertir con un 98% de acierto cualquier hash que venga de un nombre de usuario, contrasaeña… que contenga menos de 8 caracteres y esté en minúsculas sin números ni signos. Veamos ejemplos:

Usuario: 664DA32C1BA6F93F2899FE82C73DBFAF
Contraseña: B67885AB956F9D8F8946768F2E362E92

C:\Users\Theliel\rcrack *.rt -h 664DA32C1BA6F93F2899FE82C73DBFAF
traversing rt group #0 for 1 hash (remain = 0, traversed = 0, skipped = 0)
traversing rt group #1 for 1 hash (remain = 0, traversed = 0, skipped = 0)
disk: md5_loweralpha#1-7_0_2400x4000000_0.rt: 64000000 bytes read
searching for 1 hash…
disk: md5_loweralpha#1-7_1_2400x4000000_0.rt: 64000000 bytes read
searching for 1 hash…
plaintext of 664da32c1ba6f93f2899fe82c73dbfaf is theliel
disk: thread aborted

statistics
——————————————————-
plaintext found: 1 of 1
total time: 1.78 s
time of chain traverse: 0.41 s
time of alarm check: 0.11 s
time of wait: 1.15 s
time of other operation: 0.11 s
time of disk read: 1.67 s
hash & reduce calculation of chain traverse: 5752802
hash & reduce calculation of alarm check: 1171435
number of alarm: 1662
speed of chain traverse: 14.17 million/s
speed of alarm check: 10.65 million/s

result
——————————————————-
664da32c1ba6f93f2899fe82c73dbfaf theliel hex:7468656c69656c

C:\Users\Theliel\Desktop\rcrack *.rt -h B67885AB956F9D8F8946768F2E362E92
traversing rt group #0 for 1 hash (remain = 0, traversed = 0, skipped = 0)
disk: md5_loweralpha#1-7_0_2400x4000000_0.rt: 64000000 bytes read
disk: md5_loweralpha#1-7_1_2400x4000000_0.rt: 64000000 bytes read
searching for 1 hash…
traversing rt group #1 for 1 hash (remain = 0, traversed = 0, skipped = 0)
searching for 1 hash…
plaintext of b67885ab956f9d8f8946768f2e362e92 is talento
disk: md5_loweralpha#1-7_2_2400x4000000_0.rt: 64000000 bytes read
disk: thread aborted

statistics
——————————————————-
plaintext found: 1 of 1
total time: 0.76 s
time of chain traverse: 0.45 s
time of alarm check: 0.08 s
time of wait: 0.22 s
time of other operation: 0.02 s
time of disk read: 0.75 s
hash & reduce calculation of chain traverse: 5752802
hash & reduce calculation of alarm check: 1124940
number of alarm: 1624
speed of chain traverse: 12.73 million/s
speed of alarm check: 14.42 million/s

result
——————————————————-
b67885ab956f9d8f8946768f2e362e92 talento hex:74616c656e746f

 

Increíble, ¿cierto? En un par de segundos el hash ha sido invertido. Estas tablas podrían ser reutilizadas cada vez que se necesitase, aunque es evidente que las tablas creadas son limitadas. Imaginar el proceso con tablas mucho más completas. A día de hoy es posible invertir cualquier hash cuyo mensaje original sea menor a a unos 13 caracteres simples. Queda una incógnita por cubrir… en realidad infinitos mensajes de entrada pueden producir el mismo hash en la salida. Esto implica que en una misma tabla hash podrían ocurrir colisiones, en las que dos mensajes tienen el mismo hash. Lo normal en estos casos sería listar todas las posibilidades encontradas, el sentido común haría el resto.

¿Conclusión? Usar siempre contraseñas seguras, contraseñas de longitud nunca menor a 8 caracteres y usando combinaciones de letras mayusculas y minusculas, números y símbolos. De cara a un programador, jamás usar Hash sin salt. Las tablas Rainbow son un recurso poderosísimo como hemos podido ver, capaz de romper casi al instante un hash. La siguiente pregunta podría ser como puede un atacante obtener un hash, pero esto está indicado en el tema sobre Sniffing.

 

Brute Force y Diccionarios

Hasta ahora todo lo que hemos visto es como atacar a un Hash. Ahora veremos un par de sistemas que podrían ser usados prácticamente para atacar cualquier sistema criptográfico, ya sea un cifrado simétrico, asimétrico o un hash.

Brute Force es un término coloquial para designar un tipo de ataques que se versa simplemente en el poder computacional de los sistemas modernos. Brute Force (Fuerza bruta) básicamente lo que realiza es probar una a una todas las combinaciones posibles de una posible key (en caso de un cifrado) o posibles hash en caso de un hash. De echo, las tablas Rainbow serían algo así como unas tablas precomputadas brute force para los hash, ya que lo que contienen no es más que todas las posibles de la entrada. Las técnicas de fuerza bruta no obstante suelen quedarse como última solución, ya que su éxito o fracaso tan solo está directamente relacionado con la complejidad de la contraseña, y como hemos dicho ya por complejidad nos referimos al set de caracteres usado, así como a la longitud de esta.

La fuerza bruta clásica es simple de comprender. Imaginar que se tiene un maletín con apertura con combinación con 3 ruletas de números, que van entre 0-9 y cuya key hemos olvidado. Podríamos probar todas las opciones posible para tratar de adivinar cual es: “000, 001, 002, 003, 004… 997, 998, 999”. Serían unas 1000 combinaciones. Esto hacerlo a mano podría ser incluso factible, pero tan solo estamos hablando de 3 cifras (caracteres). Si transladamos esto a un algoritmo como AES cucya Key se desconoce, es exactamente lo mismo, serían necesarias unas 1000 combinaciones (Siempre hablando en el peor de los casos) para lograr la key. Pero que sucede si aumentamos ese “Set de caracteres”?

Actualmente la capacidad de cálculo de un procesador es impresionante, y si incluimos la posibilidad de poder usar nuestra tarjeta de vídeo para dicho propósito, podemos multiplicar incluso por x100 o x1000 el rendimiento!! Pero aun así, ¿hasta que punto es posible atacar con fuerza bruta un sistema? Primero tendríamos que presuponer una capacidad de cálculo estimada de nuestros sistemas, y a partir de ahí hacer suposiciones y aproximaciones de hasta que complejidad es viable atacar una key por fuerza bruta. El problema es que el tiempo para poder verificar una key u otra varía del algoritmo usado. Veamos algunos ejemplos sobre la capacidad de cómputo de un PC, las mostradas corresponden aproximadamente al PC usado en la redacción de este artículo:

Algoritmo CryptoZip: 50 Millones de contraseñas por segundo -> Clásico cifrado usado en archivos ZIP
Algoritmo AES-256: 1000 contraseñas por segundo -> Cifrado simétrico actual usado en archivos ZIP

Como podemos ver, hay más que ligeras diferencias. Con esos datos, podríamos por tanto esclarecer aproximadamente la viabilidad de poder romper una key en un tiempo razonable. Según esos datos, vamos a ver el tiempo estimado (máximo) necesario para romper diferentes ejemplos:

Key numérica CryptoZip de 13 caracteres de longitud: 67 horas -> viable
Key numérica CryptoZip de 17 caracteres de longitud: 257 días -> “viable”
Key minúscula CryptoZip de 11 caracteres de longitud: 884 días -> no viable
Key minúscula CryptoZip de 8 caracteres de longitud: 1.2 horas -> viable
Key minúscula+numérica CryptoZip de 11 caracteres de longitud: 86 años ->no viable
Key minúscula+numérica CryptoZip de 8 caracteres de longitud: 16 horas ->viable
Key minúscula+numérica+mayúscula CryptoZip de 9 caracteres de longitud: 9 años -> no viable
Key minúscula+numérica+mayúscula CryptoZip de 8 caracteres de longitud: 51 días -> “viable”
Key minúscula+numérica+mayúscula+símbolos CryptoZip de 8 caracteres de longitud: 3 años -> no viable
Key minúscula+numérica+mayúscula+símbolos CryptoZip de 6 caracteres de longitud: 3.2 horas -> viable

Key numérica AES-256 de 9 caracteres de longitud: 9 días -> “viable”
Key minúscula AES-256 de 7 caracteres de longitud: 97 días -> “no viable”
Key minúscula+numérica AES-256 de 6 caracteres de longitud: 26 días -> “viable”
Key minúscula+numérica+mayúscula AES-256 de 5 caracteres de longitud: 10.7 días -> viable
Key minúscula+numérica+mayúscula+símbolos AES-256 de 4 caracteres de longitud: 19.2 horas -> viable

De todos estos datos podemos sacar ciertas conclusiones. Cuando se está usando un algoritmo antiguo o relativamente rápido de verificar, sería posible recuperar keys de hasta 15 caracteres aproximadamente si es solo numérica, de unos 8-9 si contiene tan solo letras minúsculas y números, pero no más de 6-7 caracteres para keys que son complejas.

En caso de AES-256 es aun peor. En el mejor de los casos, tan solo podríamos intentar romper keys de hasta 9 caracteres de longitud si fuesen tan solo numéricas. Para el resto de los casos, contraseñas mayores de 4-6 caracteres que fuesen complejas serían imposible de romper por fuerza bruta al estilo más clásico.

No obstante existen multitud de técnicas basadas en fuerza bruta para mejorar en mucho estas cifras. Por supuesto, en el momento que sales del método tradicional, abandonas la posibilidad de lograr la recuperación al 100%. La idea es intentar mantener el mayor índice de porcentaje posible reduciendo al máximo el número de combinaciones posibles. El problema de este método es que suelen estar basados en la estadística y otras técnicas, en la suposición, en lo que podemos llamar “común”:

  • Diccionarios: Se presupone que la key/contraseña escogida pertenece a una palabra que existe en un diccionario previamente creado o calculado. La idea nace de que lo normal es que las personas usen nombres comunes para sus claves y contraseñas. No obstante los diccionarios más sofisticados no solo incluyen aquellas palabras que existen en un lenguaje u otro, sino posibles alternativas a ellas. El diccionario contendrá aun así cientos o miles de millones de posibles opciones, pero siempre serán exponencialmente menos que combinaciones posibles por fuerza bruta.
    Dado los múltiples problemas de esta técnica, suele usarse conjuntamente con métodos híbridos. Por ejemplo a la lista de entrada se le realizan modificaciones a todas sus letras de modo que se verifiquen todas las combinaciones posibles de cada entrada con letras mayúsculas o minúsculas. Así por ejemplo si tenemos la entrada “casa”, se probarán diferentes versiones de esta: “casa, Casa, cAsa, caSa, casA, CAsa, CaSa… CASA”. Esto hace aumentar enormemente el espacio de claves a probar, pero continuaría siendo exponencialmente menor a un ataque de fuerza bruta clásico.
    Otra posible “optimización” a un ataque de diccionario es la combinación. Es una cuestión de conocer como piensan los usuarios. Si bien es cierto que existe un porcentaje alto de usuarios que usan palabras “naturales” para sus contraseñas/keys, también existe un porcentaje alto que cree que una combinación de estas dos palabras resulta en una contraseña más segura. Por ello, otra mejora habitual en los ataques por contraseña es permitir la combinación de dos, o incluso tres, palabras que se encuentran en el mismo diccionario. De este modo si en el diccionario tenemos las palabras: “casa” y “antonio”, nuestro ataque comprobaría: “casa, antonio, casaantonio, antoniocasa”.
    Los ataques de diccionario son increíblemente rápidos, pero en contrapartida son completamente ineficaces cuando la contraseña/key usada no se encuentra en ellos, lo cual es facil si se crea esta sin ser una “palabra” con “sentido”.
  • Fuerza bruta “inteligente”: La idea ha sido siempre reducir al máximo las combinaciones posibles. El diccionario es una técnica realmente eficaz, pero depende enormemente del diccionario, del lenguaje… y por supuesto del usuario y la contraseña que haya podido establecer. La fuerza bruta establece que cualquier combinación es posible (y realmente es así), en cambio esto no es cierto si se atienden a las estadísticas de los usuarios, contraseñas comunes, palabras empleadas, frases empleadas… lo cual lleva a replantearse la fuerza bruta. ¿Es posible eliminar combinaciones (estadísticamente hablando) por ejemplo si tenemos una key de hasta 8 caracteres en minúsculas? La estadística dice que existen combinaciones de letras que jamás se darán. Por ejemplo, no existen palabras en español que estén constituida por dos letras seguidas, excluyendo la “erre” y la “ele” (quizás exista alguna, pero el ejemplo es claro). Esto hace eliminar de un plumazo una cantidad considerable de combinaciones. Esto crea una serie de normas que van eliminando combinaciones y más combinaciones al ataque de fuerza bruta clásico, por ejemplo interpretando las letras que pueden ser usadas al inicio o al final, letras que suelen ir juntas o letras que no…
    Este tipo de fuerza bruta decrementa enormemente las posibles combinaciones, lo que hace que el ataque pueda ser llevado a cabo mucho más rapido. En contra partida de nuevo tenemos que un usuario podría siempre crear una key/contraseña que se saltase estas medidas. Por ejemplo la contraseña: “tYb,3hI?” sería imposible de detectar por ningún sistema casi con toda seguridad, tan solo por fuerza bruta clásica.
  • Plantillas: Con plantillas nos referimos a la posibilidad de poder acotar la búsqueda de una key por fuerza bruta basándonos en ciertas reglas que nosotros mismos especificamos. Por ejemplo una plantilla podría ser simplemente especificar los primeros 4 caracteres de la contraseña, dejando para la fuerza bruta tan solo otros 4. O por ejemplo una plantilla podría ser igualmente especificar una palabra que estamos seguro que la clave contiene, dejando a la fuerza bruta que compruebe todas las posibilidades teniendo en cuenta que existen por ejemplo 4 caracteres que siempre estarán juntos, estén al inicio, en medio, al final…
    El problema con las plantillas es que dependen casi en su totalidad en lo que se pueda conocer a la víctima y que tipo de palabras ha podido usar. Pensar por ejemplo en fechas de cumpleaños, aniversarios… podríamos especificar por ejemplo que se verificasen todas las combinaciones posibles de hasta 12 caracteres que contengan la fecha “22051950”. Dado que son 8 caracteres, tan solo serían 5 caracteres por combinar, es decir, los 4 caracteres restantes que completarían los 12 caracteres más la fecha en sí, que sería tratado como un carácter más.
    De nuevo la eficacia dependerá de factores externos, como lo bien o mal que se conozca a quien puso la contraseña, a la suerte, a la perseverancia…

Posiblemente, uno de los “crackers” más famosos fue siempre John The Ripper, que fue creado originalmente para lograr obtener las contraseñas de Unix, almacenadas todas ellas tradicionalmente en un hash basado en DES (cifrado simétrico). Con el tiempo, el soporte para este “crackeador” de contraseñas fue ampliándose, soportando otros hash como los que usa Windows para almacenar sus claves de sesión. Esto puede hacernos pensar que el uso de la fuerza bruta ha ido cada vez más relegándose a un segundo plano, dada la complejidad del calculo necesario para poder computar contraseñas/key actuales. En cambio, la fuerza bruta posee dos cualidades únicas que hacen que posiblemente siempre sea una opción viable a considerar. Esto es así por dos motivos:

El primero, la fuerza bruta tiene un índice de probabilidad del 100% y teóricamente “siempre” podrán realizarse (en realidad existen métodos criptográficos en los que la fuerza bruta no es posible realizarse), solo es cuestión de tiempo, ya sean 1000 años o dos segundos.
La segunda característica, es que aunque sea necesario un mayor tiempo de cómputo o se usen cada vez keys más largas y complejas, la capacidad de cálculo actual se va incrementando de igual modo. Lo que actualmente un PC puede llevar a cabo en un año, simplemente por tener una tarjeta de video por ejemplo con soporte para CUDA, puede ser suficiente para reducir ese año a simplemente algunos segundos. Esto es posible a que la capacidad de cálculo en paralelo de una tarjeta de vídeo es muy superior a un procesador tradicional. Por ejemplo, es posible que la nueva generación de tarjetas de nVidia, la esperada familia basada en Fermi, pueda incrementar en un x10000 la velocidad de cómputo de contraseñas AES-256 especificadas anteriormente, eso hace que de 1000 contraseñas por segundo se pase a lo mejor a 10.000.000 de contraseñas por segundo. Es decir, no hay que perder de vista jamás que las capacidades de cálculo son mejoradas cada día, tanto tarjetas de vídeo como procesadores. Lo que hoy no es viable, mañana puede ser completamente viable.

El mejor ejemplo de esto es RSA. Es imposible factorizar en tiempo factible una key RSA-1024… pero esto tan solo es cierto a medias. Quizás fuese imposible hace unos años, quizás es imposible actualmente… pero cada día que pasa es más posible. Eso hace que actualmente RSA-1024 esté siendo sustituido casi en su totalidad a RSA-2048, es casi seguro que que vivamos para ver que RSA-4096 es lo mínimo para mantener el sistema seguro. Es decir… Brute Force será posiblemente siempre una técnica usada y que tendrá siempre una efectividad decente.

Para acabar, vamos a ver lo simple que es usar John The Ripper para extraer las contraseñas de usuario de un iPod/iPhone. Todos sabemos que cuando se le realiza JB es posible acceder a él por medio de SSH. También sabemos que posee dos usuarios: “root” y “mobile”, y que en ambos la contraseña es “alpine”. ¿Pero como se ha llegado a esta disertación? ¿A caso Apple ha filtrado estas contraseñas? Vamos a extraerlas.

Lo primero que necesitamos es conocer en un sistema Unix en que archivos se almacenan las contraseñas. Esto se hace normalmente en uno o en dos, dependiendo si se está usando un ocultador o no. Si no se está usando, lo normal es que estas contraseñas y usuarios se encuentren en un archivo llamado passwd, que contiene los nombres de usuarios y las contraseñas en un hash-cifrado basado en DES llamado shadow. Dichos archivos en el iPod/iPhone se llaman “passwd” y “master.passwd”.

Una vez se obtienen ambos archivos, se debe de generar un archivo único que integra ambos archivos (esto es así por el propio sistema que usa UNIX para ello). Una vez obtenido este archivo único se realizaría un ataque de fuerza bruta. Dado que UNIX usa un hash muy débil (basado en DES), es fácil romperlo:

C:\Users\Theliel\Desktop\>unshadow passwd master.passwd > contra
“contra” es el archivo “unificado”

C:\Users\Theliel\Desktop\>john contra
Loaded 2 password hashes with 2 different salts (Traditional DES [64/64 BS MMX])
alpine (mobile)
testtest (root)

guesses: 2 time: 0:00:10:47 (3) c/s: 2134K trying: testtart – testzirz

Para esta prueba, la contraseña de la cuenta mobile fue establecida de nuevo a su contraseña origen, y la contraseña root fue establecida a “testtest” para tener una contraseña con longitud de 8 caracteres. Hay que tener en cuenta que iPod/iPhone no soporta contraseñas mayores de 8 caracteres. Se puede observar como el ataque tubo éxito, siendo necesario tan solo unos 11 minutos en llevarse acabo. Este ataque de fuerza bruta difiere quizás un tanto del clásico ataque de fuerza bruta, dado que va dirigido a un Hash y no a un cifrado, pero básicamente es exactamente igual.

Si las tablas rainbow nos enseñaron a la necesidad de crear siempre los hash con salt, la fuerza bruta y todas sus variantes nos enseñan que la mejor protección ante este tipo de ataques no es solo un buen sistema de cifrado, sino una key, contraseña, clave de paso… que sea segura, con una longitud decente, que no sea personal, que… cuando se toman las medidas oportunas, este tipo de ataques está evocado al fracaso.

 

Criptoanálisis

El término Criptoanálisis es un poco ambiguo en la medida que podríamos considerar como “criptoanálisis” prácticamente cualquier ataque que queramos realizar contra la criptografía. En cambio podríamos, como ya dije en su momento tomar por criptoanálisis tan solo aquellas técnicas, generalmente estadísticas en combinación (o no) con otras, para lograr el resultado deseado, que puede ser desde la roptura completa de un sistema obteniendo una key, accediendo simplemente a la información cifrada o… así por ejemplo, la paradoja del cumpleaños aunque es usada para crear colisiones en los hash, podría interpretarse como tal como un sistema de criptoanálisis.

Esto no es un método nuevo creado en el siglo XXI, sino bastante antiguo. La idea de estudiar un manuscrito e intentar descifrarlo la conocemos desde los mismos jeroglíficos a notaciones musicales o muchos lenguajes ya desaparecidos. ¿Por qué? Es fácil, la mejor forma de “traducir” (aquí usamos el término descifrar) algo que se desconoce es buscar patrones en común, palabras que se repitan constantemente, distribución de los caracteres a lo largo del escrito… todo ello ayuda sobremaneramente para lograr una “traducción” de algo desconocido. En el caso de la criptografía en realidad es muy similar. Un ejemplo claro de criptografía lo encontramos cuando se habló de los diferentes modos de cifrado de los bloques de criptografía simétrica, en el que se sometió el cifrado CBC a un test sobre una imagen para verificar su fortaleza. En realidad, ese test lo que hace es mostrar gráficamente una serie de patrones repetidos por toda la imagen.

Entre los ataques de criptoanálisis más comunes podemos encontrar:

  • Análisis de Frecuencias
  • “Texto codificado” conocido
  • “Texto plano” conocido
  • Texto plano/codificado escogido

El análisis de frecuencias pudimos ya comprobarlo cuando vimos el método de codificación por bloques CBC. Pero puede ilustrarse de un modo aun más simple. Imaginar por ejemplo el cifrado de sustitución más simple, en el que cada letra del abecedario se mapea a otra letra de este. La key por tanto sería tan solo este mapeo. Es decir, si la Key fuese:

ZYXW….

Significaría que la A sería sustituída por la Z, la B pro la Y, la C por la X… para descifrar un texto de esta forma, tan solo tendría que tener la otra parte la mismaplantilla. Al leer Z la sustituiría por una A, las Y por B… este tipo de cifrado aunque pueda parecer trivial ha sido muy usado en la antigüedad. Hay que tener en cuenta que las matemáticas modernas, así como los dispositivos de computación que tenemos a día de hoy no se encontraban disponibles muchos años atrás, y que un cifrado tan aparentemente simple como el explicado podía ser suficiente para que, por ejemplo, dos amantes compartiesen cartas comprometidas, sin que ninguna tercera persona lograse descifrarlas.

Es cierto que con los sistemas modernos de codificaciones por bloque, los análisis de frecuencias van teniendo cada vez menos interés como método directo para estudiar un cifrado, no obstante continúa siendo usado tanto para verificar la resistencia de un buen cifrado como en la búsqueda de otros sistemas mucho más sofisticas en combinación con estos.

Estos análisis de frecuencias han sido muy usados durante muchos años, y a día de hoy constituyen siempre un comienzo a la hora de estudiar un cifrado concreto. Podríamos destacar igualmente el método de Kasiski, similar al que vamos a ver a continuación, pero orientado a conocer la longitud de las palabras, o extender el análisis de frecuencia al índice de coincidencia. Dependiendo de que tipo de cifrado sea, quizás sea mejor usar un método u otro. Para quien quiera jugar con todo esto, les recomiendo una vez más Cryptool.

Vamos a crea un ejemplo con el cifrado más básico de sustitución y verificar que con un ataque de análisis de frecuencia es posible recuperar el texto original. Gracias a ello, se podrá ir recuperando al mismo tiempo la “key” usada en el cifrado de dicho mensaje. Para llevar esta labor a cabo, tendremos que partir de un texto cifrado por sustitución, e intentar obtener el mensaje original a partir de este. Para este ejemplo he partido de un pequeño fragmento de “El Zahir”, un libro de Paulo Coelho (gran escritor, el libro es mu interesante igualmente). Dicho fragmento ha sido procesado con CryptoTool para generar un texto cifrado por sustitución usando una key aleatoría. Recordar que la key no es más que un mapeo de un carácter a otro, en el que ningun caractar en este caso está repetido, es decir, la asociación es 1 <– >1:

piczyiugwtxhzrxibkziqejiywxbikkziynwiqngsijmnifgypzjwzeirwjpigbaztxjugin
ikkitiyczypzikkzugiikkznirwfznwjzbrxnizkxyxsxykzjzvxbexjkzugiyiagiyxkxibp
xbhiynikwljzjirinwvzcwjibhzyxhxbpjzjwxeibyzjirwzmbxhcibxhcimrwzjihxjrzb
rxbgiypjzcwypxjwzhwibpxynwkiyritihiywbpibpzbrxriyhgljwjiknxnibpxibikugi
niiugwtxugimbgiypjxyhznwbxyineivzjxbzrwypzbhwzjyi

Al texto superior se le han eliminado tanto signos de puntuación como espacios, para que no sea posible percibir inicios o fin de palabras. Podemos ver el esquema que se ha usado para realizar esto:

Un texto original se cifra por medio de sustitución con una “key” que descnonocemos. Después de realizar la operación de cifrado, enviamos como texto plano el resultado para poder visualizarlo: “Texto cifrado”. Al mismo tiempo, la salida cifrada se pasa de nuevo por el descifrador que debería de devolvernos el texto original reconstruido: “Texto Reconstruido”. Dado que no hemos comenzado a aplicar el análisis de frecuencia, actualmente el texto Reconstruido es exactamente igual al texto cifrado. Por último se puede observar como a la salica cifrada se le ha aplicado un pequeño analizador de frecuencia, el cual nos devielve el porcentaje de aparición de cada letra. Visto de una manera más gráfica tenemos:


Frecuencia de caracteres del Texto Cifrado


Con estos datos, podemos comenzar por tanto un sistema de deducción basado en la estadística. Según la gráfica superior, el 16,37% de todos los caracteres son “I”, el 9.82% “Z”… ¿Como nos vale esto? Recurriendo ni más ni menos que a la estadística. Estos son los datos obtenidos de nuestro texto cifrado. ¿Pero que dicen las estadísticas del lenguaje castellano de forma general? Es decir, si conociésemos la frecuencia “global” media de las letras escritas de nuestro lenguaje, podríamos comenzar a deducir y reemplazar. En mi caso he usado como referencia la frecuencia de caracteres de “El Quijote”. Con cerca de medio millón de palabras, puede servir a groso modo como dato “fiable”. Lo ideal sería establecer una frecuencia basada en diferentes tipos de textos, a poder ser mucho más largos. Pero a modo de ejemplo es suficiente:


Frecuencia de Caracteres de "El Quijote"


Con este patrón que creemos “fiable” podemos por tanto comenzar a conjeturar. Según la frecuencia basada en “El Quijote”, las vocales ‘E’ ‘A’ y ‘O’ serían las letras con mayor frecuencia y en dicho orden. Si estableciésemos una correspondencia directa entre ambos análisis, tan solo tendríamos que sustituir las vocales citadas por aquellos caracteres con mayor frecuencia en el texto cifrado, que serían en el mismo orden: ‘I’ ‘Z’ y ‘X’. Si volvemos a CryptoTool y añadimos dichas letras en las posiciones adecuadas, comenzaremos a tener una primera versión de texto reconstruido, siempre y cuando la hipótesis aplicada de frecuencias sea correcta: ‘I = ‘E’, ‘Z’ = ‘A’, ‘X’ = ‘O’

pecayeugwtoharoebkaeqejeywobekkaeynweqngsejmnefgypajwaeerwjpegbaatojugen
ekketeycaypaekkaugeekkanerwfanwjabroneakoyosoykajavobeojkaugeyeageyokoebp
obheynekwljajerenwvacwjebhayohobpjajwoeebyajerwambohcebohcemrwajehojrab
robgeypjacwypojwahwebpoynwkeyreteheywbpebpabroreyhgljwjeknonebpoebekuge
neeugwtougembgeypjoyhanwboyeneevajobarwypabhwajye

Aun con 3 posible letras descodificadas, es imposible tener algo legible. Eso sí, hay que tener en cuenta que cada letra que es sustituídas y dado que es una sustitución 1 <–> 1, implica que para el resto de los caracteres las posibilidades van decreciendo igualmente. Podríamos continuar con las dos siguientes, pero si contemplamos las estadísticas de nuestro texto cifrado, tanto la ‘B’ como la ‘Y’ poseerían un porcentaje igual. En cambio si acudimos a las frecuencias de nuestros datos muestra, tenemos que las dos siguientes letras corresponderían a la ‘S’ y la ‘N’ en dicho orden. No obstante, podemos acudir a la frecuencia de repetición de dos caracteres juntos iguales. Si lo hacemos, obtenemos que los caracteres más repetidos (en parejas) correspondiente a nuestro texto cifrado son:

II: -> 2 apariciones, 0,59% del total
KK -> 4 apariciones, 1,18% del total

Y del mismo modo para nuestro texto de muestra:

LL:9258:0,00467523338292373
RR:2378:0,00120087545739821

De forma aplastante, LL es el carácter más repetido estadísticamente en nuestros datos de muestra. Si observamos los caracteres repetidos en nuestro texto cifrado tan solo tenemos dos, II y KK. No obstante, ‘I’ =’E’, luego podríamos asumir sin duda alguna que ‘K’ = ‘L’. Al ser un texto pequeño, no disponemos de otros caracteres dobles que podamos sustituir por ‘R’. Pero al igual que tenemos carácteres dobles ampliamente usados en nuestro lenguaje, también tenemos combinaciones de 3 caracteres que prevalecen sobre las demas, como es el caso de ‘QUE’. Estadísticamente es la asociación de tres letras más repetida con muchísima diferencia. Si examinamos las agrupaciones de 3 caracteres en nuestro texto cifrado, existe curiosamente una asociación de 3 caracteres con un 1.46% de aparición, que corresponde a las letras ‘UGI’, si tenemos en cuenta además que la ‘I’ es una ‘E’, es evidente que U = Q y G = U

pecayequwtoharoeblaeqejeywobellaeynweqnusejmnefuypajwaeerwjpeubaatojquen
elleteycaypaellaqueellanerwfanwjabronealoyosoylajavobeojlaqueyeaueyoloebp
obheynelwljajerenwvacwjebhayohobpjajwoeebyajerwambohcebohcemrwajehojrab
robueypjacwypojwahwebpoynwleyreteheywbpebpabroreyhuljwjelnonebpoebelque
neequwtoquembueypjoyhanwboyeneevajobarwypabhwajye

Con el trabajo realizado por ahora, es posible ir dividiendo ya algunas de las palabras que van apareciendo, y sustituir también la ‘W’ = ‘I’, dado que es la vocal que nos resta, y después de QU -> es evidente que si no es una ‘E’, será una ‘I’. Con todas las vocales despejadas, y aun sin conocer cuales corresponderían estadísticamente a la ‘N’ y la ‘S’, si nos restaría con una probabilidad de 6.85% la ‘J’ de nuestro texto cifrado, que equivaldría a ‘J’ = ‘R’ en nuestros datos de muestra. Podemos por tanto agregarlo todo:

pecay equitoharoeblaeqereyiobellaeynieqnusermnefuypariaeerirpeubaatorquen
elleteycaypaella que ella nerifanirabronealoyosoylaravobeorlaqueyeaueyoloebp
obheynelilrarerenivacirebhayohobprarioeebyareriambohcebohcemriarehorrab
robueypraciyporiahiebpoynileyreteheyibpebpabroreyhulrirelnonebpoebelque
ne equitoquembueyproyhaniboyeneevarobariypabhiarye

Con ello podemos deducir sin mucho trabajo, ahora sí: ‘bueyproy’ que ‘B’ = ‘N’ e ‘Y’ = ‘S’, no hay más remedio, y poder formar así ‘NUESXRO/S’, con lo que además obtenemos también ‘P’ = ‘T’:

te cas equitoharo en la eqeresion ella esnieqnuserm ne fustaria eerirte unaatorquen
elletescastaella que ella nerifaniranronealosososlaravoneorla que se auesoloent
onhesnelilrarerenivacirenhaso hontrario eensare riamnohcenohcemriarehorranro
n
uestra cistoria hientosnilesretehes intentanroreshulrirel nonento en el que
ne equitoque m nuestros haninos eneevaronaristanhiarse

Lo cual nos hace resolver del todo el texto cifrado. Si sustituimos la ‘H’ = ‘C’, ‘N’ = ‘M’, ‘M’ = ‘Y’, ‘F’ = ‘G’, ‘E’ = ‘P’, ‘R’ = ‘D’

te has equitohado en la eqpresion. ella es mi eqmuser y me gustaria pedirte un aatorque
me lletes hasta ella, que ella me diga mirandome a los osos la ravon por la que se aue solo entonhes
melilrare de mi vacir en caso contrario pensare ria y noche noche y ria recordando
n
uestra historia cientos miles de teces intentando desculrir el momento en el que
me equitoque y nuestros caminos empevaron a distanciarse

Por último, solo nos queda terminar de colocar las pocas letras que nos quedan, añadir los espacios que nos restan y en todo casi si queremos añadir acentos, comas y otros para que el texto tenga mayor sentido. El texto descifrado correspondería a:

“Te has equivocado en la expresión. Ella es mi ex-mujer y me gustaría pedirte un favor: Que me lleves hasta ella, que ella me diga mirándome a los ojos la razón por la que se fue. Solo entonces me libraré de mi Zahir. En caso contrario pensaré día y noche, noche y día… recordando nuestra historia, cientos, miles de veces, intentando descubrir el momento en el que me equivoqué y nuestros caminos empezaron a distanciarse”

 

Texto codificado conocido puede parecer una perogrullada, parece evidente que siempre tendremos acceso al texto codificado, máxime cuando precisamente lo que se quiere realizar es desencriptarlo. Pero se especifica para indicar que tan solo tenemos acceso a dichos mensajes codificados. Un ataque de estas características implicaría estudiar tan solo los mensajes cifrados, y a partir de ellos lograr de alguna forma invertir el cifrado de estos, recuperar la key o lo que sea posible. Parece imposible a simple vista que simplemente por el estudio de estos mensajes cifrados se pueda llevar a alguna conclusión, en cambio ya vimos por ejemplo con el análisis de frecuencia (que realmente se aplica a un mensaje ya cifrado) que esto es posible.

Un ejemplo muy interesante sobre esto es una de las muchas vulnerabilidades de WEP, ese “sistema de seguridad” WIFI que aun está implantado en más de un 50% de los hogares, me atrevo a decir. WEP usa como vimos en su momento un sistema de cifrado simétrico basado en flujo, en concreto el algoritmo se conoce como RC4, y básicamente lo que hace es generar un flujo constante de bits que hacen de key para los datos que se van enviando/recibiendo, y dicho flujo es al mismo tiempo generado en el otro punto de la comunicación. La forma en la que se cifran los datos en RC4 dijimos que era realizando una operación lógica XOR entre el mensaje original y la key del stream (del flujo). El problema aparece cuando dos mensajes diferentes son encriptados con la misma key-stream. ¿Como es esto posible? es simple, si la key maestra no se modifica, la key-stream generada no será modificada tampoco. Para evitar que la key-stream se pueda repetir, se usa un vector de inicialización que se concatena con la key maestra, y a partir de dicha asociación se genera el stream necesario. Cada paquete enviado incluirá un vector de inicialización diferente, generado aleatoriamente, y que será transmitido al medio sin cifrar conjuntamente con el paquete cifrado, para que de este modo, los destinos puedan conoce el IV usado, concatenar el IV (vector de inicialización) con la key maestra que tienen y con ello generar el key-stream del paquete para poder desencriptar el contenido.

En teoría podría parecer un sistema seguro, el key-stream es diferente en cada paquete, con lo que no hay duplicación de key-stream. El problema es que el vector de inicialización de WEP es de 24 bits, es decir… es muy pequeño. ¿Que probabilidad existe de que se produzca una colisión? Es decir… ¿que se generen dos IVs iguales? podríamos decir que 224 pero como quedó ya constante, por la paradoja del cumpleaños esto no es así:

X(P,Y)= Raiz (2Y Ln (1/1-P))

Para una probabilidad de 0.99 (99%) necesitaríamso en el peor de los casos 12.431 paquetes aproximadamente. Es decir, cada trece mil paquetes wep, al menos dos estarán usando la misma key.

Ahor abien… ¿como influye esto? Tan solo hay que saber que la operación lógica XOR posee la propiedad conmutativa (y por supuesto su tabla de verdad). Imaginar por tanto que tenemos en nuesras manos 2 mensajes diferentes cifrados con la misma key-stream:

A y B son los mensajes, Cifrado (A) y Cifrado (B) los mensajes que hemos capturado, los cuales comparten la misma key. K es la key del paquete, es decir, la concatenación de la Master Key y el IV. Sk (K) sería por tanto la key-stream

Cifrado (A) = A XOR Sk (K) -> El cifrado de A se forma mediante el mensaje original y XOR key-stream
Cifrado (B) = B XOR Sk (K) -> El cifrado de B se forma mediante el mensaje original y XOR key-stream

Cifrado (A) XOR Cifrado (B) -> Por la propiedad conmutativa y con las ecuaciones superiores tenemos que:
(A XOR Sk (K)) XOR ((B XOR Sk (K)) = A XOR B XOR Sk (K) XOR Sk (K) -> Sk (K) XOR Sk (K) = 0 por definición
Cifrado (A) XOR Cifrado (B) = A XOR B

Es decir, si se realiza la operación XOR entre ambos mensajes encriptados, el resultado es el mismo que si se realiza la operación XOR a los mensajes no cifrados. La utilidad es inmediata, dado que sería posible descifrar el contenido de los mensajes originales, en el peor de los casos haciando un poco de fuerza bruta. Un ejemplo:

k 1= IV | MK
ks = RC4(k1)

A= 01011
B= 01101
ks= 11011

Cifrado (A) = 10000
Cifrado (B) = 10110

Cifrado (A) XOR Cifrado (B) = 00110 = A XOR B -> Se cumple!!

Se podría pasar a usar ahora por ejemplo fuerza bruta para intentar descubrir los posibles mensajes originales. Es cuestión de analizar las probabilidades que existen de encontrar el mensaje original, e ir probando. En el momento además que se obtenga uno de los mensajes, el otro es encontrado de forma automática también.

Acabamos de ver lo que entendíamos por la técnica de “texto cifrado conocido”, del mismo modo tenemos también la técnica conocida como “texto plano conocido“, en la que ahora no solo disponemos del texto cifrado, sino que también disponemos de todo o parte del contenido original. Es evidente que en este caso lo deseado no es obtener algo que ya tenemos. La idea es recuperar el resto del mensaje cifrado en caso de que tan solo tengamos el mensaje parcial o por el contrario ser capaces de recuperar la key original por medio de esta técnica.

Posiblemente el mejor ejemplo de “texto plano conocido” que podemos encontrar sea el sistema usado por el compresor ZIP. Esta técnica permitía extraer todos los archivos cifrados de un ZIP, sin necesidad de contraseña, simplemente poseyendo un archivo sin cifrar que estuviese ya dentro de dicho ZIP. Es decir, imaginar un archivo ZIP encriptado con una contraseña con las fotos más comprometidas de nuestros hermanos. Imaginar que tenemos alguna foto que el nos ha enseñado sin encriptar, fuera del ZIP. Podríamos recuperar todo el contenido.

Otro ejemplo podría ser también un cifrado como el que hemos hablado antes, de sustitución. Con saber una letra o un par de ellas del mensaje original, podría ser suficiente con suerte para llegar a deducir el resto. No hablo solo al cifrado de sustitución que ya mostré, sino alguno que pueda ser más complejo. De todos modos, es un sistema relativamente poco efectivo en los métodos de codificación modernos, siendo realmente vulnerabilidades de las propias implementaciones las que hacen posible este tipo de ataques y no el cifrado en sí.

Por último, podríamos disponer ya no solo material cifrado o sin cifrar como el que hemos visto, sino que material cifrado o sin cifrar que nosotros escogemos a conciencia para poder realizar nuestro criptoanálisis. Se conoce como “texto escogido”. Normalmente esta no es una opción viable, dado que es complicado poder disponer de un material cifrado o sin cifrar que hemos seleccionado previamente. No podemos decirle a una persona a la cual le interceptamos un mensaje que nos envíe otro mensaje tal y como nosotros lo queremos. Es decir, esta técnica queda reservada a un “pequeño” grupo, no de manera generalizada.

Por un lado tenemos los cifrados asimétricos, en los cuales en cualquier momento si que podemos disponer de cualquier material cifrado y sin cifrar que provenga de la clave pública del objetivo. Es cierto que no podremos disponer de texto escogido cifrado que provenga de su clave privada, pero al menos ya es algo. Es más, muchos de los ataques que se han realizado a sistemas RSA, han estado basados en textos escogidos para poder lograr (o no) la key privada. Aunque normalmente, estas vulnerabilidades suelen ser más propias de las implementaciones. Por ejemplo, sería muy interesante ver el comportamiento de una implementación SSL/TLS frente a lo mejor un mensaje creado a propósito que tan solo contiene una cadena inmensa de contenido vacío (0x00), o variar la longitud a voluntad para ver que tipo de Padding se está usando, o intentar… es decir que las opciones son múltiples. Es una herramienta muy poderosa, pero como hemos dicho reservada tan solo a escenarios bastante concretos.

Por otro lado podríamos tener aquellos sistemas en los que pudiésemos “obligar” a un cliente a enviarnos material específico. Esta por ejemplo es otra vulnerabilidad de nuestro ya más que hablado WEP, y es además como la mayoría de los atacantes logran recuperar las contraseñas WEP de los usuarios que aun las usan. Este ataque está basado por ejemplo en el reenvío masivo de paquetes ARP (ARP no será tratado en estas líneas). WEP no modifica en modo alguno la longitud de los paquetes, recordar que usa XOR para cifrarlos. ARP por otro lado son paquetes con una longitud determinada y que son fácilmente reconocidos por cualquiera, incluso estando cifrados. Estos paquetes ARP que son ampliamente conocidos, tienen una cabecera de 16 bytes que es común a todos ellos!. Es decir, los primeros 16 bytes de un paquete ARP son siempre los mismos, exactamente:

AA AA 03 00 00 00 08 06 -> Los primeros 8 Bytes de un paquete ARP
00 01 08 00 06 04 00 01 -> Los 8 Bytes siguientes de un paquete ARP

El último byte no obstante varía entre 01 y 02 si el paquete ARP es un “response” o un “request”. Por otro lado, dado que la MAC del frame no es cifrada por WEP, conocer si el paquete es un ARP response o un ARP request es sencillo (mirando el destino de la MAC o el origen de ella).

En ese momento ya conoceremos los primeros 16 bytes cifrados de u paquete ARP (enviados por el AP) y los 16 primeros bytes del paquete ARP sin cifrar (deducidos). Dado que los datos son cifrados por medio de XOR, si se realiza un XOR a los datos cifrados con los datos sin cifrar da exactamente la key usada para cifrarlos. Es decir, fácilmente podemos recuperar desde un paquete ARP 16 bytes de la key-stream, y dado que el IV se envía también sin encriptar, también se dispondrá del IV empleado para concatenar la master key que se usó para generar el key-stream

Para poder realizar un ataque completo a WEP es necesario la recolección de cierta cantidad de key-stream, cuando se obtiene dicha cantidad, por medios probabilísticos y un poco de fuerza bruta es posible la obtención de la key:

 

Side Channel

Por último, vamos a hablar del último grupo de posibles ataques a sistemas cifrados que podemos encontrar. Se llaman métodos Side Channel, es decir, métodos “paralelos”, realmente no buscan encontrar vulnerabilidades en el propio cifrado, sino que normalmente en el sistema en el que están implementados o en el medio por el que circulan dichos datos. Ojo!! no a la implementación de ellos!! sino en el sistema que son implementados. Para ello se estudia el comportamiento de dichos sistemas ante un cifrado o un descifrado.

Posiblemente a día de hoy sea el mayor riesgo para los cifrados. Dado que todos estos sistemas están siendo utilizados de un modo u otro en un hardware, este hardware se comportará siempre de manera diferente dependiendo de los datos que circulen por él. Por ejemplo, cuando se está descifrando un código en un PC, algún lugar de este se está procesando dicha Key. Por muy seguro que sea el cifrado si la key se encuentra en dicho momento en memoria, un atacante con acceso a dicho sistema podría intentar recuperar dicha key de la memoria del sistema. O quizás más famosos aun son los ataques de tiempos, que estudian el tiempo que requiere el procesador, la memoroa, la caché… en procesar el encriptado/desencriptado de los datos. En definitiva, la idea es estudiar el entorno y conocer como se comporta este ante diferentes tareas en el cifrado. Esto puede parecer ciencia ficción, pero realmente funciona, y supone u verdadero riesgo para los cifrados simétricos o asimétricos, así como a todas las comunicaciones a día de hoy.

Posiblemente los Side Channel más conocidos sean:

  • Arranque en frío e inicio alternativo
  • Monitorización del hardware
  • Extracción directa
  • Análisis Electromagnético
  • Análisis de consumo y de estados
  • Ataques de tiempo

Cold Boot o arranque en frío es una técnica destinada a la extracción de keys que son usadas por un sistema que aun estén residiendo en la memoria de este. Para que un sistema (ya sea un PC, un procesador criptográfico, un dispositivo portátil…) pueda utilizar una key, esta debe de pasar antes a su propia memoria RAM. La memoria RAM de estos dispositivos suele ser volátil, es decir, su información se pierde (se va degradando paulatinamente) inmediatamente después de que el suministro energético ha sido retirado. Es decir, mientras el sistma está arrancado, es normal que por ejemplo los módulos TPM de los que ya hemos hablado mantengan las Keys en la RAM de estos, que el PC arrancado en Windows tenga las Key de BitLocker o EFS en la memoria del sistema, que la key privada de nuestra smartcard esté en la RAM de este cuando se está usando… etc etc. Lo que sucede es que mientras el sistema está arrancado o en funcionamiento, estas keys pueden estar residiendo en la memoria si se están usando, pero tan solo mientras el sistema está conectado. Al cerrar el sistema y la alimentación se corta, la RAM deja de tener coherencia y los datos simplemente se desvanecen.Es por ello que la memoria necesita lo que se denominan ciclos de refresco, en los que la información de esta es reescrita de nuevo en ellos para que esta pueda mantener su información intacta. Al cortar la energía no se refrescará, con lo que la información se pierde. Esto lo observamos por ejemplo cuando un equipo está en suspensión. Un PC en suspensión en modo S3, deshabilita prácticamente todo el hardware del sistema… menos la RAM, la RAM continuará estando alimentada, refrescándose cuando sea necesario para poder mantener los datos.

Lo que sucede realmente es que esto no es algo inmediato. La información en la RAM no se desvanece de forma inmediata nada más apagar el sistema ni mucho menos, tiene un período de tiempo estimado, en el que a partir de dicho tiempo es una cuestión de probabilidad, hasta que hayan desaparecido del todo. ¿Cuanto es este tiempo? Depende de mil factores, lo que es seguro es que si la RAM se vuelve refrescar, los datos de esta se fijarán. Imaginemos ahora que tenemos ante nosotros un PC en suspensión S3, el cual sabemos que usa BitLocker o EFS para proteger su equipo. Nosotros sabemos que casi con toda seguridad en algún lugar de la memoria se encuentran las keys necesarias para poder acceder al sistema, dado que el propio sistema está arrancado y funcionando. Y aquí es donde aparece el Arranque en frío. Imaginar que durante unos instantes cortamos la energía al sistema, pero la volvemos a restablecer de forma que intentemos mantener intacta la mayor parte de la RAM posible. Al arrancarlo, dado que la RAM es posible que aun mantenga las keys en memoria, podríamos intentar a través de algún inicio alternativo al del sistema para volcar todo el contenido de la memoria en disco, para analizarlo con detenimiento con posterioridad. Quizás no podamos acceder a primera instancia al sistema, pero si podemos iniciar un segundo sistema operativo o alguna herramienta que nos permita realizar la tarea de volcar la memoria, es posible que en la memoria volcada esté aun residente algunas de las keys buscadas.

Se podría proteger así mismo el sistema para evitar incluso el acceso a un inicio alternativo por medio de un HDD externo, USB… pero aun así no sería algo definitivo, dado que siempre se podrían extraer físicamente (cuando sea posible claro) la RAM del sistema e implantarla en otro equipo o analizador para poder volcar su contenido.

Las únicas defensas ante este tipo de ataques es tomar las precauciones necesarias, por ejemplo jamás dejar un sistema que sea crítico conectado a la alimentación si no se está usando, usar hardware específico para almacenar las keys como por ejemplo tarjetas personales, obligar a usar PINs para proteger las keys… en fin. Aunque ningún método es fiable al 100%, al menos siempre se puede complicar la obtención. No pensar solo en un PC cuando se habla de criptografía, un movil, una PDA, una tarjeta inteligente… a fin de cuentas todos los dispositivos electrónicos funcionan de una forma muy similar: Memoria, uno o varios procesadores, registros, puertos de entrada/salida… por eso cualquier sistema que se requiera seguridad, podría implementar medidas para garantizar que cuando el sistema sea apagado las keys ya no residan de modo alguno en memoria, por ejemplo forzando el desmontaje de las unidades cifradas cuando no están en uso y técnicas similares, aunque como se ha dicho, lo mejor es simplemente no usar sistemas de suspensión S3 o de hibernación S4 en sistemas que deseamos que dispongan del mayor grado de seguridad.

Continuando con el estudio del hardware y el arranque en frío, nos topamos con la monitorización del hardware. Es evidente que cuando hablamos de Side Channel lo normal es mezclar la informática con la electrónica al más puro estilo. Dado que podemos conocer el funcionamiento exacto de un hardware o de un módulo TPM, de la memoria, del procesador… podríamos estudiar su funcionamiento electrónico en determinadas tareas, con herramientas como los osciladores, los analizadores lógicos, sensores de temperatura… es evidente que para todo ello es necesario tener acceso al hardware del sistema, tiempo y instrumentación.

Pensar en un sistema en el que las Keys sean almacenadas en un procesador criptográfico tipo TPM, y que este cuando lo cree oportuno carga la key en su propia memoria interna para ser utilizada. Imaginar que disponemos de instrumentación necesaria para “abrir” ese procesador criptográfico, que será un chip encapsulado en plástico, y conectar sus buses de datos a un analizador lógico. Una vez todo el sistema conectado y preparado, se realizará un arranque normal, pero a la par se estaría analizando toda la información que circularía por los buses de datos del módulo TPM. Si en algún momento la key viaja por los buses de datos de este, el analizador lógico será capaz de leerla. Esto mismo es aplicable a un PC, se podría conectar un analizador lógico a los buses de un PC e intentar buscar por ellos el dato deseado. La premisa es la misma, es buscar la key allí donde pueda circular.

Un método más agresivo a la monitorización del hardware sería el intentar la extracción directa. Las keys que son usadas para cualquier tipo de cifrado asimétrico suelen estar almacenadas, es lógico. Lo normal es que estén almacenadas en algún soporte extraible como una tarjeta criptográfica o en algún hardware especializado, tipo TPM. Da igual que estas estén protegidas o no por contraseña, ya que los PIN realmente lo que nos da es la llave para acceder a ella, pero de cualquier forma las keys están en dichos soportes de forma física. Si las keys están en ellas de forma física, en algún lugar de esa electrónica existirá un registro, una pequeña memoria (ya sea Flash, ROM, EEPROM…) que contiene dichos datos sensibles. Visto un todo desde fuera parece simplemente algo absurdo poder mirar ahí, pero desde un punto de vista electrónico es la mejor opción. Hay que tener en cuenta que la mayoría de las memorias ROM, EEPROM, FLash… se acceden de una forma “estandar”. Lo que sucede es que es la misma electrónica y procesadores que están en los circuitos los que es´tan diseñados para que el sistema no pueda acceder a ellos, pero no implica que no se pueda acceder a ellos manualmente. Podría ser por tanto posible acceder a los elementos hardware de dicha tarjeta criptográfica, hardware TPM… de forma que pudiésemos tener acceso a dichas memorias, y que por medio de algunos cables conectados en los puntos exactos y enviando las señales correctas a dicho hardware, este nos devolvería su contenido, revelando así los datos deseados. Es evidente que esto es tan solo la teoría, la práctica es mucha más compleja, se requiere de material especializado para ello y ni siquiera se puede decir que tenga un éxito rotundo, ya que dependerá de la electrónica, de la complejidad, de la seguridad… con la que fue dicho dispositivo creado. A fin de cuenta este tipo de Side Channel tan solo podremos verlo nosotros como teórico, aunque por supuesto es usado de forma práctica. Pensar en espionaje industrial, gobiernos, mafias…

Dejando de momento un poco el hardware concreto, ha existido una técnica sorprendente, yo la llamo análisis electromagnético. En física, cualquier paso de electrones es por un cable produce un campo eléctrico y por tanto un campo electromagnético. Ahora bien, pensemos por ejemplo en un cable de red Ethernet por el cual circula toda nuestra información. Ese flujo de información está produciendo que dicho cable ethernet esté emitiendo constantemente radiaciones electromagnéticas que podrían ser estudiadas, y a través de ellas ser capaces de conocer la información que viaja por ellos. Esta tecnología existe a día de hoy. Si bien es cierto que esto no afecta directamente a los sistemas de encriptación tal y como estamos explicando, estas técnicas podrían ser usadas de igual forma para estudiar las radiaciones electromagnéticas que proceden por ejemplo de una tarjeta criptográfica en funcionamiento, o un módulo TPM, y de este modo, como si de un analizador lógico se tratase, lograr el cometido deseado.

Por otro lado podríamos realizar un estudio analítico del consumo y el estado del hardware en las tareas de codificación/descondificación. Un procesador criptográfico o una CPU no requiere el mismo consumo energético para computar por ejemplo una key de 128 bits que para una de 192 bits. Todo este tipo de información es activamente utilizada en conjunción a otros ataques para poder lograr el fin deseado. Del mismo modo, se pueden monitorizar los estados que ocurren en el procesador, como por ejemplo si el procesador ha pasado a un estado de inactividad C6, si se ha introducido un error controlado en los datos para estudiar como se comporta el sistema… es decir, cualquier “trampa” que podamos imaginar para poder extraer cuantos más datos sea posible sobre el sistema, y con ello lograr descubrir que está circulando realmente por sus interiores, o si la key tiene que tener 4 o 5 caracteres o…

Por último, los análisis de tiempos podemos decir que son similares a los análisis de consumos, solo que en este caso se estudia sobre todo el tiempo de computación. Del mismo modo que el procesador tendrá un consumo mayor para computar una key mayor, también requerirá de más tiempo para dicha labor. Pero es más, es posible incluso que el tiempo que requiera un procesador para cifrar una key, por ejemplo: “101010” sea diferente a la que se requiera para la key: “101011” (se ha modificado un bit).

Se podrían estudiar estos tiempos o estados a lo mejor para ser capaz de aplicar correcciones estadísticas a ciertos algoritmos para la obtención de una clave privada desde una clave pública. Si el problema de esta es la imposibilidad de obtener la factorización, por medio de optimizaciones, cribas y otros gracias a estas técnicas, se podría diseñar para un sistema concreto un algoritmo que fuese capaz de factorizar la clave pública en un timpo razonable.

Otro posible uso sería estudiar el tiempo de la latencia de la red, de los sistemas de dos extremos que usen una conexión SSL/TLS y con ello realizar un estudio que pudiera indicarnos cual es la key privada que se está usando, dado que los tiempos, las latencias, los retrasos… todo ello puede verse afectado dependiendo de cada bit que pueda poseer la clave privada.

En Side Channel se estudian todas las posibilidades que puedan brindarnos un mayor grado de información de un sistema. Cuanta más información se pueda extraer de dicho sistema, más fácil o posible será poder atacarlo.

 

Para acabar, Actualmente existen técnicas para poner en jaque prácticamente cualquier tipo de cifrado o sistema de autentificación. Esto no implica que en la actualidad no exista nada seguro, simplemente no existe nada seguro al 100%, aunque si al 99.99%. Con una buena praxis y una buena educación en seguridad, un sistema informático o electrónico puede ser una bastión en toda regla frente a ataques externos.

¿Comienza la debacle para Apple?

Share on Google+Share on FacebookTweet about this on Twitter

Puedes vender un caramelo a precio de oro  a un niño ansioso de azúcar una vez, dos veces… pero no tres. Esto es lo que está empezando a sentir Apple, y es lo que se presagiaba desde muchos sectores. Si hay algo que alabar a Apple fue su idea increíble con su concepto de “iPhone”, pero se centró tanto a explotarlo y a arremeter contra toda la industria, que poco a poco ha ido siendo su propio destructor. En el mercado tecnológico, no estás dispuesto a invertir constantemente en tecnología útil, o estás fuera en 3 días. Pero no solo debes de crear tecnología útil, sino que sea usada y esté al alcance de todos. Si te aferras a creer que eres intocable, que siempre serás el mejor y que toda la competencia son unos inútiles, desprestigiándolos, criticándolos… llega un día en el que las cosas empiezan a ir mal.

Este y otros muchos motivos son los que hacen que Apple jamás despegará de su ínfimo porcentaje dentro de la tecnología. No puedes ir contra la industria, no puedes imponer tus opiniones por la fuerza aun cuando sean las buenas!! Tienes que tener miras amplias, apoyar los estándares, intentar equilibrar un mercado. Lo que sucede es que si Apple hiciese eso perdería muchos clientes que simplemente compran productos de ellos por creer que son diferentes.

A tan solo unas semanas de que comience a comercializarse el iPad, Apple no sabe ya que hacer para intentar darle más publicidad. Lo último fue una cuña publicitaria en la misma gala de los ¡¡Oscars!! Cuando un producto lo vale, no suele hacer falta gastarse tantos millones en publicidad, spots, cuñas, editoriales en los periódicos… Las críticas no han sido nada positivas, es cierto que pocos son los que a estas alturas no saben que es el iPad, pero la pregunta es cuantos serán capaces de comprárselo. Y lo cierto es que todo apunta que será un “Fracaso”. Por supuesto habrá muchos que lo compren, y posiblemente la gran mayoría de ellos sean personas que no se han parado a preguntarse realmente que necesitaban o que se estaban comprando.

Apple, desde hace ya más de un año ha ido cada vez a peor. En Febrero se registraron el mayor porcentaje de iPhones en el mercado!! siendo usado por más del 75% de las personas que accedían a internet desde dispositivos portátiles. Apple, en vez de crear un iPhone nuevo y realmente mejorado que hizo? Sacar un iPhone 3GS, el tercero!! el tercer terminal que sacaba y era prácticamente igual en todo que los otros dos. 3 terminales para poder grabar video? 20 actualizaciones de software para un terminal, casi todas ellas para arreglar fallos? En junio llegaría la sorpresa para Apple de un bug que incluso permitía el control remoto de iPhone por SMS, y Apple se quedó de brazos cruzados.

Por las mismas fechas más o menos, y pese a la inminente salida de Windows 7, Apple en vez de comenzar a crear un OS realmente seguro o eficiente no hizo otra cosa que sacar una actualización!! a la que llamó Snow Leopard, y por supuesto cobró por ella. Para lo que microsoft llama Service Pack y es gratuíto Apple lo llamo nueva versión. Al poco tiempo se descubrió u bug muy gracioso en Snow Leopard, por el cual simplemente podías perder TODOS tus datos de tu sesión… y Apple se quedó con los brazos cruzados.

Se comenzó entonces a rumorear la salida de un teléfono por parte de Google, y Windows 7 se empezaría a comercializar en unos días. ¿Que hizo Apple? Primero salir en todos los medios de comunicación haciendo demagogia barata, con frases tan interesantes como: “Estamos esperando con entusiasmo la salida de Windows 7, porque implicará que muchos usuarios se pasarán a MAC OS” “La gente está cansada de Windows, será un desastre mayor a Vista” “La nueva versión de Windows nos hará ganar mucha mayor cuota de mercado”… Prepotencia, prepotencia, prepotencia… tal fue la historia que incluso el día antes del lanzamiento de Windows 7 Apple intentó ecplipsar el momento con la salida de un ratón supuestamente mágico y revolucionario, que por cierto, a día de hoy no es que se hayan vendido muchos.

Antes de contar como acaba la historia, vamos a continuarla. Poco a poco, Nexus One tomó forma y pasó a ser una realidad, y pro parte de Apple se rumoreaba la posible creación de un TabletPC super revolucionario. Acabado el año Nexus One vio la luz, con un hardware muchas veces superior al iPHone, con un OS muchas veces superior al iPhone. Las únicas críticas fueron para el escaso soporte técnico por parte de Google, lo cual fue solucionado a los pocos días, a men de una actualización para corregir unos problemas con 3G.

Apple, para variar, tan solo podía hacer una cosa, lo que hace siempre, en vez de crear un producto competitivo criticar a la compentencia: “No se porque google entra ahora en el mundo de la telefonía, a caso nosotros entramos en el negocio de los buscadores?”. Apple fue demandada por Nokia por violaciones de patentes, y Apple en vez de llegar a un acuerdo respondió con otra demanda. Dicha demanda volvió a ser respondida por parte de Nokia con otra nueva demanda por más patentes… Así es como intenta arreglar las cosas Apple, con la ley del más fuerte. No sería sino hace relativamente unos días cuando Apple a arremetido también contra HTC por violación de supuestas patentes de ellos. Si no puedes ganar, al menos intentas hacer que la competencia pierda.

Para Apple se complicaba todo… luego el lanzamiento de un TabletPC podría poner de nuevo la baraja a su favor y lograr otro éxito rotundo. Pero en vez de intentar crear algo decente, simplemente cogió lo que ya tenía, le puso una pantalla más grande y le puso un precio disparatado. Lo llamó iPad, que por cierto, nombre que ya estaba patentado no por una sola empresa, sino que se sepa por dos!! De nuevo más juicios y más denuncias.

A todo esto, hay que sumarle la anulación de garantías de los Macbook por que se había fumado cerca de ellos, o la censura tan radical por parte de Apple en la AppSTore… cosas a dia de hoy desde mi punto de vista impensables

 

Ahora bien… ¿a día de hoy? Ya he dicho que puedes vender un caramelo a precio de oro a un niño chico necesitado de azucar, pero no eternamente. ¿Sabéis que dicen los números? Los números dicen que en un año el porcentaje de uso del iPhone ya ha caído un 10%, situándose ahora mismo entorno al 65%, si tenemos en cuenta que los movimientos más destacados han sido de hace unos meses para acá, Apple tiene un problema. Andriod en los últimos 3-6 meses se ha doblado, y todo indica que en los próximos meses podría comerle sin problema alguno otro 10% Apple. Actualmente Android roza el 20% en conexiónes a internet desde dispositivos portátiles. Google no para de dar bocado tras bocado a Apple, y va a continuar dándolos por una razón muy simple, Apple no es capaz de crear hoy en día algo que realmente sea útil y pueda llegar a las personas. Actualmente comparar Android con iPhone OS sería como comparar unas vacaciones en algunas islas exóticas con una cárcel. Con iPhone OS no puedes hacer NADA, ni siquiera podemos decir que el iPhone sea un Smartphone. Peor aun… las ventas de Nexos One están comenzando a aumentarse considerablemente, lo cual nos dice que Google irá pegando cada vez bocados más grandes a Apple, mientras que los programadores y desarrolladores son mucho más propensos y se sienten más a gusto a trabajar con Android.

Pero el iPhone es solo uno de los problemas de Apple. Por otro lado, su navegador Safari no para de perder cuota de mercado. Si tenemos en cuenta que tanto Safari como IE son navegadores por defecto en Windows o MAC OS, esto es aun más impactante. El porcentaje de Safari alcanza casi tan solo un 4%.

Lo peor no ha sido eso… Windows 7 ha sido y está siendo un éxito rotundo. Todas las palabras que se dijeron contra Windows 7 por parte de Apple les están costando mucho. Un OS tan pesado, tan malo, tan inseguro… tan tanto que dice Apple, y en tan solo 3-4 meses ya cuenta con más de un 20% de cuota de mercado. En los últimos meses la cuota de mercado de MAC OS ha descendido y está descendiendo, colocándose aproximadamente en unas 0.3 décimas por debajo… el problema es que dependiendo de a que estadística se acuda, nos dirá que MAC OS es usado en un 7% o en un 4%. La tasa actual REAL de MAC debe de rondar entorno al 5.5% a nivel mundial. Perder 3 décimas en un porcentaje tan pequeño, es un bocado considerable, si tenemos en cuenta que además es Windows 7 el que no solo le está quitando cuota de mercado a Windows Vista y XP, sino también a Apple. Y lo peor para Apple es que la tendencia va a continuar. Windows 7 es más seguro, más eficiente, con mayor libertad para todo… Apple lo único que le queda es tragar saliva.

Esto es algo que se esperaba venir. Si intentas vender tus sistemas, tu tecnología simplemente por decir que lo tuyo es mejor, nunca vas a despegar del suelo, aunque muchos se lo crean. Me gustaría ver que sucedería si Microsoft realizase las campañas de marketing y tan agresivas que realiza Apple, gastándose las ingentes fortunas que se gasta en hacer que la manzana aparezca en cada película, en spots, en prensa, en… Apple tendría que comenzar gastándose el dinero en sus programadores, en sus ingenieros…

Safari baja
MAC y MAC OS bajan
iPhone baja

Y todas las encuestas, profesionales, analistas… dicen que esto va a continuar. Por mi parte me entristece dado que la competencia siempre ha sido y será sana, es lo que hace que el mercado avance y podamos tener productos de una calidad tan importante o de alta tecnología como Nexus One. Por otro lado me alegro, Apple necesita un buen baño de humildad. Siempre he sido una persona extremadamente crítica con Microsoft, y sinceramente en tiempos de Gillermo Puertas (Bill Gates) microsoft escuchaba más el dinero que sus usuarios. Esto es algo que tengo q alabar enormemente a Steve Ballmer, no solo cogió las riendas de Microsoft, sino que desde mi punto de vista le dio un enfoque diferente. Las cosas comenzaron a cambiar. Ahora, es cierto que podemos criticar no cientos… miles!! de programas o quejas o… en contra de microsoft. Pero también hay que reconocer que en los últimos años han estado con las orejas bien abiertas, adaptándose, mejorando… intentando hacer las cosas bien, no solo para ganar dinero!! sino escuchando al usuario tanto de nivel bajo, medio como profesionales.

Apple si quiere puede cambiar y convertirse en una gran empresa, sentirse orgullosa de si misma. Pero desde mi punto de vista no podría pensar bien de una empresa que su concepto de hacer publicidad es intentar desprestigiar el producto de la competencia. Microsoft? Aun le queda mucho que mejorar y aprender, para mi algo que aun no logro entender por parte de Microsoft es que diablos sucede con Internet Explorer.

En la otra cara de la moneda Google continua siendo un ejemplo a seguir en muchos aspectos (no en otros). Android a demostrado ser un OS más que increible para los terminales portátiles, Chrome como vimos en la entrada pasada se ha convertido en una opción viable para aquellos que solo necesitan un navegador para navegar. Los servicios de Google son cada vez mejores, con más prestaciones y el 90% todos gratuitos, siempre apoyando estándares e intentando mejorar realmente el estilo de vida de las personas.

 

Y con esto hasta el próximo día amigos. ¿En este mundillo lo mejor? En este mundillo lo mejor siempre está por venir.

Firefox 3.7: Aceleración por Hardware y una de Navegadores

Share on Google+Share on FacebookTweet about this on Twitter

No soy muy dado a este tipo de entradas, pero mientros concluyo con el último capítulo de Encriptación y Autentificación me he animado a decir algunas palabras sobre lo que está por llegar por parte de Firefox.

Firefox abrió la guerra de los navegadores hace unos años. Nadie apostaba por él, pero en cambio demostró no solo ser mucho más seguro que la competencia (IE, Opera y Safari básicamente), sino que también mucho más rapido. Por otro lado, la sustitución de los peligrosos ActiveX por complementos o temas hizo que Firefox ganase adeptos cada día que pasaba.

Tanto Opera como Safari viendo lo que pasaba creyeron que podían seguir los pasos de Firefox e intentar robar cacho a IE, cosa que tan solo Firefox estaba logrando arrancar a base de bocados. Microsoft por su parte no le dió más importancia hasta que Firfox se había convertido realmente en una opción más que viable y con un mercado bastante amplio, lo que hizo a MS sacar su IE 7 y posteriormente IE8, francamente una chapuza cada uno de ellos.

Explotó de nuevo la guerra, Opera y Safari querían tajada y Google quiso unirse a la fiesta con Chrome. Superar a Firefox en cuanto prestaciones y versatilidad resulta imposible a día de hoy, por lo que tanto unos como otros se han centrado los últimos meses simplemente en optimizar código, mejorar el engine JavaScript para mejorar los tiempos de renderizado de webs y cosillas similares. Esto se ha logrado hasta tal punto que a día de hoy sin duda alguna el navegador más rapido renderizando una web es sin duda alguna y con diferencia Chrome, seguido de Safari y Firefox más o menos en igualdad de condiciones, por detrás a corta distancia Opera y en último lugar y muy alejado IE.

Aquí hay que ser realista y tener mucho cuidado con los test que se realizan y quien los haces, así como conocer un poco cada navegador. De no hacerlo, los test no valen absolutamente para nada, y entra el fanatismo y la publicidad gratuita. Esto tampoco significa que cada navegador vaya orientado a un grupo diferente de usuarios, exceptuando quizás IE y Safari, que se quedan descolgados del resto por falta de “utilidad”.

Como hemos dicho, Chrome de Google es con diferencia el navegador más rápido a la hora de renderizar una web, pero en contrapartida también es con mucha diferencia el navegador más simple y menos cargado de todos. Optimizar un código de un millón de líneas es más complejo y difícil que optimizar un código de 100. Esto no hace a Chrome ni mejor ni peor, simplemente es un navegador ligero, actualmente no demasiado versátil si lo comparamos con Firefox, pero es que su planteamiento es muy diferente que el que hizo crear por ejemplo Firefox. Tiene una tasa de mercado entorno al 6%

Tanto Safari como Google usan el mismo motor de renderizado, WebKit, el cual hace que los dos compartan el mismo alma por así decirlo. Esto no quiere decir que sean iguales ni mucho menos, pero por ejemplo comparten prácticamente los mismos estándares y muchas funciones. Safari no es un navegador ya de por sí con muchas funcionalidades y se ha demostrado que es bastante “inseguro” en comparación con la competencia. Esto hace que no tenga un mercado claro, lo mismo que le ocurre a IE, lo que hace que sus usuarios (el 99% usuarios de MAC OS) usen en sus ordenadores (o se planteen) otros navegadores como Chrome o Firefox.Tan solo cuenta con un 4% aproximadamente de mercado, y desde hace ya tiempo va perdiendo cada día mas usuarios, aunque de muy poquito en poco. Resulta curioso que si tenemos en cuenta que tanto Windows como MAC OS usan navegadores predeterminados diferentes, y que tanto Chrome como Safari están disponibles ambos para MAC OS y Windows, es simplemente impresionante que Chrome ya haya superado en índice de mercado a Safari, sin siquiera tener OS propio (quitando Android o el OS Chrome)

Opera es un caso extraño. Opera lleva en el mercado muchos años, y siempre ha tenido un buen rendimiento, seguridad y versatilidad. En cambio por una extraña razón, aun cuando Firefox no era una opción y tan solo existía IE, Opera nunca gozó de “suerte” o siquiera de demasiada aficción. Tengo que reconocer que antes de Firefox era mi navegador por defecto y tenía ciertas cualidades que me parecían bastante interesantes, como en aquella época era el renderizado de webs para móviles por ejemplo. Opera ha mantenido más o menos siempre la misma cuota de mercado, un 2-3%. Aun después de todos los esfuerzos de Opera, tiene en estos tiempos un problema añadido: Firefox y Chrome. El primero por ser con diferencia (desde mi punto de vista) el mejor navegador en términos generales del mercado, y el segundo tiene Google detrás, por no decir que es un navegador actualmente bastante eficiente. Esto me temo que hará que Opera continúe su camino en “solitario”, y sinceramente… tienen todo mi respeto, siempre han estado ahí, y eso se agradece, no hay que olvidar que muchas de las innovaciones que hoy por hoy tenemos en los navegadores se las debemos a ellos.

IE, Internet Explorer… bueno, me temo que microsoft tiene actualmente la guerra perdida. Se mantiene a salvo simplemente por una cuestión llamada Windows, y que actualmente con las nuevas leyes de seleccionar navegador perderá aun otro trozo más de mercado. Día a día IE pierde cuota de mercado, situándose actualmente en torno al 60%. Si tenemos en cuenta que Windows lo tiene preinstalado y que Windows se usa en más de un 90% de los ordenadores, es impresionante que Firefox esté ganando terreno. No es tan impresionante si tenemos en cuenta que IE es una porquería. Quizas ya no en seguridad como siempre se critica (que también), sino por el rendimiento tan pobre que tiene, la falta de estándares que soporta y las pocas funcionalidades que nos ofrece.

En último lugar y lo que me ha hecho escribir estas líneas, Firefox. Firefox no solo comenzó siendo una posible alternativa más rápida y segura q IE, sino que pronto se convirtió en toda una plataforma eficiente para la navegación y desarrollo web. Son innumerables las extensiones ¡ÚTILES! que tenemos, y por supuesto para los amantes de la estética los temas. Firefox es simplemente rápido (aunque no el que más en términos generales), Compatible (aunque no el que más) e increíblemente versátil. Pero tiene otro AS en la manga, y es aun lo que puede dar de sí.

No voy a entrar por tanto si mejor Safari, si mejor IE o mejor Opera. De los tres más cariño a Opera, pero si tengo que ser franco, aunque en su última versión (creo que se ha liberado ya la 10.5) es muy rápida, situándose más cerca de Chrome y por encima de Safari y Firefox, no creo que marque una diferencia significativa, a fin de cuenta la velocidad no lo es todo.

Chrome se diseñó simplemente para dar agilidad a la navegación. Creado de Cero para ello, la preocupación de los desarrolladores no era crear extensiones o añadir funcionalidad, simplemente ser el más rapido. Y lo logró. Y si tu que me lees lo único que quieres o deseas de un navegador es velocidad a la hora de renderizar una web, actualmente Chrome es lo mejor que puedes tener… actualmente. Si deseas algo más, Chrome no te lo va a dar, al menos por ahora y en mucho tiempo.

Firefox… al ser un proyecto de código libre como Chrome tiene muchas ventajas. Primero que es mucho menos vulnerable a ataques externos, con lo que es mucho más seguro. Por otro lado es la propia comunidad quien crea, mejora, aporta… Actualmente el proyecto Firefox tiene una aceptación impresionante, es una plataforma poderosa y eficiente.

En cambio parece que lo que fue una virtud para él, su velocidad a la hora de renderizar páginas, ahora al estar tan de moda en laa competencia parece ser que deja a Firefox en una posición inferior, vulnerable. Ahora parece que todos los navegadores son rápidos y eficientes. Pero como hemos dicho hay mucha trampa en ello. Para comenzar, Firefox es realmente muy rápido, lo que sucede es que casi todo el mundo tiene más de un y dos complementos cargados, muchos de ellos consumen bastante memoria, lo que hace que el navegador sea en su conjunto más lento. Si desechásemos todo aquello que hace de Firefox tan versatil y útil, su rendimiento aumentaría considerablemente. A fin de cuenta no se puede tener todo en este mundo… ¿o si? Pese a ello, es evidente que Chrome está bastante por encima de Firefox y aun arrancando Firefox sin nada, Chrome es más rápido.

En cambio Firefox tiene un par de ases en la manga. El primero, el cual ya ha pasado a versión Alpha, (y que es el motivo de este artículo) se llama DirectWrite, aceleración por hardware para el navegador. El segundo, aun en fases relativamente iniciales se llama Electrolysis.

En las últimas build de Firefox, Firefox 3.7a3pre, se ha incluido ya soporte para DirectWrite, una tecnología que proviene de Directx, soportada por las tarjetas de video (mínimo Directx9, recomendado DirectX10+) y tan solo Windows 7 o Windows Vista. La idea es simple, dotar al navegador la capacidad de usar la tarjeta de video para las siguientes tareas:

  • Disminuir notablemente el renderizado del texto e imágenes
  • Aumentar exponencialmente el rendimiento al procesar archivos SVG o el manejo de rutinas de transformaciones de objetos
  • Aumentar la calidad tanto del texto como de las imágenes visualizadas

básicamente, podemos simplificar todo ello y decir que se logra disminuir de forma notable el tiempo de procesar páginas web de cierto tamaño (este blog es una buena prueba de ello, por la cantidad de texto en cada página), el más que evidente suavizado de las fuentes (lo cual hace que la lectura en el navegador sea más comoda y “bonita”, ya este el texto escrito en horizontal, vertical, diagonal… las fuentes siempre se verán perfectamente), y por supuesto la representación de gráficos 2D, ya sean imágenes, transformaciones de estas o gráficos vectoriales SVG.

Personalmente antes de ponerme con ello pensé que era una mejora relativa, pero la verdad es que el resultado es inmediato. Simplemente la propia estética del navegador mejora con el más que notable suavizado de fuente y otros pequeños detalles. Más tarde, comencé a testearlo con pruebas más concretas, y es cuando en algún que otro ejemplo dije: “Joder…”.

Normalmente estamos acostumbrados a que nos incluyan mejoras de las cuales no solemos percatarnos. Me pueden decir que el navegador es más rápido, pero por muchos test que me enseñen yo quiero ver que esto es verdad cuando navego yo, no cuando ejecuto test especializados. Y por ahora las pruebas que tengo es que efectivamente DirectWrite en Firefox se nota. Es curioso no obstante, ver como muchos de los benchmark que existen actualmente no tienen en cuenta este tipo de factores a la hora de puntuar un navegador. Todo el mundo se está preocupando actualmente en mejorar sin límites los motores JavaScript, pero no es lo único importante. Sí, es evidente que JS es muy importante, pero no lo es todo. Muchos de los test actuales se limitan a comprobar el tiempo de ejecución de los diferentes scripts JS que tienen para comparar resultados… y eso es válido, pero solo para JS. El único benchmark relativamente fiable y completo pueda ser Peaceckeeper, y para el resultado final especifica que no tiene en cuenta el rendimiento 2D, dado que no todos siquiera lo soportan.

Vale, todo esto es mu bonit0, pero ¿donde está la pega? ¿Cuando? ¿Dónde?

Bueno, tiene inconvenientes. Por ejemplo que tan solo es posible usar esta tecnología en Windows Vista o Windows 7, es decir, por ahora entre ambos tienen un 30% quizás de mercado, dado que Windows 7 ya ha superado el 10%. Por otro lado requiere de una tarjeta de video no demasiado antigua y relativamente actualizada, lo cual tampoco debe de ser un problema para todos aquellos que disponen de Vista o 7, dado que lo “normal” es que dispongan de una tarjeta de vídeo que soporta DX9+.

¿Cuando? Actualmente ya ha sido implementada en Firefox 3.7 Alpha. Por experiencia puedo decir que generalmente cuando una función pasa a implementarse a Firefox, normalmente en las fases Alpha, suelen fallar una y otra vez, y poco a poco con las diferentes Builds se van corrigiendo los problemas. En cambio DirectWrite parece ser bastante estable, lo cual agilizará el desarrollo y pulido de este. Cuando pude probar esta nueva tecnología, es cierto que las dos primeras build tenían algunos problemillas, como algún parpadeo que otro del navegador y cosillas por el estilo. Desde ayer no he observado ningún problema ni bug sobre esto, lo cual es más que positivo. Firefox 3.7 está actualmente en fase Alpha 3 desde hace relativamente pocos días. Si todo marcha bien podría ser necesario tan solo una versión Alpha más o incluso liberar ya la Beta 1. Una tres versiones Betas, otras tantas RC (Release Candidate) y dispondremos de Firefox 3.7 final. Las build no obstante las tenemos prácticamente de forma diarias, actualmente como digo, las build corresponden a lo que será dentro de poco la liberación oficial de Firefox 3.7 Alpha 3. Todo ello lo que implica es que todos aquellos que quieran verlo implementado de forma “versión final”, tendrán que esperar hasta el lanzamiento de Firefox 3.7 (o quizás sea llamado Firefox 4).

¿Donde? No obstante, no implica que cualquiera pueda comenzar a utilizar estas funciones, solo tiene que comprender el riesgo y “dificultades” que pueden presentar usar compilaciones diarias. Sí, te garantizan estar usando lo último de lo último, pero evidentemente no siempre todo funciona bien… es más, casi nunca funciona todo bien. Por ejemplo, otra característica añadida, ha estado fallando muchísimo durante al menos una o dos semanas, hasta que se ha ido arreglando poco a poco.

Firefox 3.7 no solo nos dejará este buen sabor de boca. La otra función que ya está añadida a la versión Alpha 2 ha sido el comienzo de lo que será una parte de Electrolysis. En este caso concreto, se ha separado del nucleo del propio navegador los plugins. Con plugins no me refiero a las extensiones, sino a Adobe Flash, Java… anteriormente todos ellos corrían de una forma u otra dentro del propio navegador, lo cual hacía que si por cualquier circunstancia dicho plugins fallaba, el navegador entero sufía las consecuencias. Ahora se ha separado a otro proceso. Si algún plugins falla, el navegador no se verá afectado, simplemente será necesario refrescar la web que ha dado el problema.

¿Como? Todo aquel que quiera comenzar a usar estas características tendrá que una versión Build, lo cual no es recomendable para la gran mayoría:

Firefox 3.7a3pre

Una vez instalada, se debe de habilitar dicha opción. Dado que es una opción aun en desarrollo, no se encuentra activada por defecto. Para ello es necesario acceder a la ventana de configuración avanzada de firefox, que para quien no lo sepa, se accede tecleando en la barra de direcciones lo siguiente:

about:config

Una vez realizado, veremos un listado con cantidad de configuraciones. Buscamos en nuestro caso dos entradas concretas:

a) gfx.font_rendering.directwrite.enabled -> Cambiarlo a True
b) mozilla.widget.render-mode -> Cambiarlo “6” (sin las comillas)

con esos dos cambios, tan solo reiniciar. Si reunimos las condiciones suficientes, nos daremos cuenta inmediatamente, aunque solo sea por el suavizado de la fuente. Ni que decir tiene que Thunderbird ya incorpora estas mismas funcionalidades en sus build más actuales, y se habilita exactamente igual.

¿Algunos ejemplos sorprendentes?

PNG girando a gran velocidad
Globo -> Esta es realmente sorprende, probarla antes y después. De ir a trompicones y no poder a ir completamente fluido
Google Maps

¿Esto es todo?  No, aun no hemos hablado de Electrolysis, aunque aun tardará en ver la luz.

Aunque en ningún sitio lo dicen, tanto IE, Safari, Opera y Chrome usan las prestaciones de los ordenadores multi-nucleos o multiprocesador. Firefox no. Sí, no es broma, Firefox actualmente tan solo usa un núcleo. El proyecto Electrolysis separará en tres la carga del navegador. Por un lado las pestañas, por otro lado los plugins y por otro la interfaz. Con las últimas build, los plugins han logrado ser separados del nucleo con éxito, es tan solo el comienzo de Electrolysis. Cuando el proyecto haya concluído y todo esté integrado en Firefox, se espera que el rendimiento de Firefox se acerque prácticamente a rozar Chrome, esperando en principio una duplicación/triplicación de rendimiento a la hora de renderizar webs.

Es decir, tiene una carta que ya todos los navegadores han usado. Esto no quiere decir que no se pueda optimizar aun más el motor JS de Firefox o mejorar todo en su conjunto. Esto quiere decir que gracias a Electolysis Firefox será considerablemente más veloz y seguro. Cuando se separe el contenido web del núcleo de Firefox, cualquier pestaña que deje de funcionar no afectará al comportamiento del resto del navegador, será aun más complicado que u exploit afecte al sistema, el sistema responderá mucho mejor en cualquier tarea. Es decir, pensar en lo que se tiene actualmente, y multiplicarlo por 3.

Actualmente se encuentra en la segunda fase de desarrollo. Quitando la separación de los plugions, el resto no ha sido implementado (y no lo será) en Firefox 3.7. Depende de a la velocidad que avance el proyecto podremos verlo antes o después, esperemos que podamos disfrutarlo en este año. Tener en cuenta que no hablamos de una pequeña modificación al navegador, sino tocar en lo más profundo de este y de como está cimentado.

En un par de meses aproximadamente la versión 3.6.2 de Firefox debería de estar terminada. Con ella, la separación de los plugins, ¿soporte DirectWrite,? Actualizaciones no intrusivas, velocidad al arrancar, una GUI un tanto mejorada… no será sino hasta Firefox 4.0 cuando Electrolysis esté integrado completamente en Firefox, junto con una interfaz bastante cambiada (más similar a la de Chrome), JetPack (que será uan nueva forma de crear extensiones) y Weave (Que permitirá poder sincronizar “navegadores”, pudiendo tener en dos disposivitos diferente los mismos favoritos, contraseñas, historiales… todo de ello de forma completamente segura).

Firefox no está muerto, le queda mucho rodaje. Es una de las aplicaciones que tengo que decir más sigo porque sinceramente lo merece. El trabajo realizado sobre él es increible, y mejora cada día. Estoy deseando que la versión 3.6.2/3.7 sea liberada para comenzar a probar Firefox 4.0. Aunque Chrome es una muy buena alternativa, actualmente prefiero Firefox. El tiempo que me ahorra gracias a sus extensiones y a la gran personalización que me da, hace que sea perfecto a mis necesidades. Por supuesto el rendimiento es importante, y es bueno ver que están en ello. No pasará mucho tiempo en que podamos ver a Firefox compitiendo con Chrome por el navegador más veloz también. Y sin olvidar por supuesto que Chrome no es ni la mitad de la mitad de lo que es hoy en día Firefox.

Un saludo a los lectores y a toda la comunidad de Mozilla por su increible trabajo. Da gusto comprobar una vez más que el software libre es la mejor opción. Prometo volver a escribir sobre esto cuando lo dicte el momento.Y con ello, ya puedo volver a terminar el capítulo sobre seguridad.

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Creative Commons License
Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.