mega, un servicio no tan seguro

Les imagino al tanto del último invento de Kim Dotcom. Después de que el FBI tirase abajo su invento Megaupload, ahora vuelve a aparecer con un esquema llamado Mega, diseñado para que puedas almacenar películas piratas, pero claro, ellos no saben nada y nosotros tampoco. La idea es que tengas un espacio “en la nube” para guardar tus archivos de forma protegida. Me recuerda a aquellos paquetes de uva prensada que se vendían en EEUU durante la prohibición con el aviso de “no meta usted este paquete en un barril, ni le añada agua y azúcar, ni lo deje fermentar en lugar seco y fresco durante quince días, porque entonces obtendría usted una bebida alcohólica, y eso es ilegal.”

Cualquiera que sea el uso que hagan los usuarios de Mega, nos proporciona una buena oportunidad de ver cómo se puede garantizar la seguridad de eso que llaman la Nube. En el caso que nos ocupa, la idea es que el cliente se encargue del proceso de creación de claves, algo que supuestamente beneficia a ambas partes: el usuario controla sus claves y Mega se lava las manos en caso de uso fraudulentos de su servicio.

Si no lo he entendido mal, todo se lleva a cabo desde el propio navegador del usuario gracias a un paquete en JavaScript que se descarga desde los servidores de Mega. Al registrarse en el servicio, el usuario introduce su nombre, dirección de email y contraseña. Después de recibir un email para confirmación haciendo clic en el enlace correspondiente, su navegador crea una pareja de claves asimétricas RSA. Es decir, utiliza el sistema de criptografía de clave pública, que usa dos claves distintas para cifrar y para descifrar. La clave de cifrado es pública (cualquiera puede conocerla y usarla para cifrar archivos), pero la clave de descifrado es secreta y conocida únicamente por el usuario.

La contraseña que ha creado el usuario sirve dos propósitos: autenticarnos frente al servicio (es decir, convencer a Mega de que yo soy yo y no otro yo), y cifrar los datos gracias a la clave maestra, que servirá para activar un algoritmo de cifra AES, considerado muy seguro. La seguridad del sistema se basa en una jerarquía de claves. Si lo que dicen los chicos de Linuxnoveles es correcto, el proceso de subida de archivos es semejante a esto:

1) Generamos una clave de 128 bits para ese archivo (llamémosle Ks)

2) Ciframos el archivo con esa clave

3) Generamos otra clave para enviar el archivo (sea Ke), imagino que con nuestra clave asimétrica RSA

4) Enviamos el archivo y su clave Ks, todo protegido con la clave Ke

5) Mega guardará tu archivo y tu clave Ks

Por supuesto, en el paso 5) no se puede almacenar Ks así por las buenas. Se supone que es secreta, así que la clave ha de ser asimismo cifrada. Qué cosas, cifrar una clave de cifrado ¿no? Pero así es más seguro, así que lo que se hace es cifrar Ks con la clave maestra del usuario. Es decir, esa clave maestra cifra la clave que descifra el archivo.

Puede que al lector le parezca raro tanta clave que cifra otra clave, que protege otra clave, que … No se preocupe, esta estrategia de “cifrado por capas” es muy habitual, ya que cada clave sirve a un propósito distinto. Usted lo hace en casa: la llave de entrada a su casa permite abrir la puerta y entrar para introducir el PIN que desconecta la alarma, y luego necesita la combinación para poder abrir la caja fuerte, que puede que contenga el PIN de su móvil, etcétera. Haciéndolo bien, el sistema puede hacerse muy seguro.

El problema con el esquema de Mega es que se han descubierto diversas vulnerabilidades, algunas de ellas triviales. Voy a intentar explicárselas de la forma más sencilla posible, y solamente me centraré en las que tengan componentes criptográficos. Sé que hay muchos otros fallos (en JavaScript, en SSL… ), pero no voy a entrar en ellos y se los dejo al lector como ejercicio.

La generación de claves asimétricas

Esa clave RSA de 2048 bits sirve varios propósitos, como el de enviar las claves de los archivos. Ahora bien, en el proceso de creación de las claves es necesario un conjunto de datos aleatorios, pero los ordenadores son muy malos generando aleatoriedad. El servicio Mega utiliza un generador de números llamado Math.random(), pero no es un generador aleatorio sino pseudoaleatorio; es decir, parece que genera azar pero es sólo aparente.

Una forma adicional de generar azar (o, como dicen los entendidos, “entropía”) es que el usuario mueva el ratón o pulse teclas. Esa puede ser una buena fuente de azar, no perfecta pero buena. Sin embargo, cuando se genera la clave RSA el servicio Mega muestra un aviso que dice “para reforzar la clave, hemos recogido entropía de los movimientos del ratón y tecleos.” Hemos, en pasado. Normalmente, servicios similares dicen algo como “vamos a generar azar, por favor mueva usted el ratón un rato.” Pero Mega usa los movimientos anteriores. ¿Y si nos hemos pasado diez minutos en el baño antes de pulsar “generar clave” y el ratón ha estado quieto? ¿Y si tengo estropeado el ratón y estoy usando el teclado? ¿Y si nuestros dedos han pulsado teclas de forma ordenada? Mega debería pedir al autor que generase azar en ese momento, no decirlo a toro pasado.

La deduplicación

Este es uno de los apartados que ha generado mayor polémica. Mega se reserva el derecho de borrar un archivo si comprueba que es un duplicado exacto de otro archivo que ya esté en algún lugar de Mega, sea en la cuenta propia o en la de cualquier otro, aunque por supuesto permitirá al usuario acceder a ese archivo dondequiera que esté. La idea es que, si hay doscientos usuarios que tienen una copia de la última peli de Star Trek, Mega no tenga que guardar 200 veces el mismo archivo. Lo que hace es borrar 199 de esas copias y darle acceso a los 200 usuarios a la copia que queda.

El problema es que supuestamente ni siquiera Mega sabe qué es lo que estamos guardando. Los 200 clientes tienen cada uno de ellos una copia cifrada de la peli, y cada uno de ellos ha usado una clave diferente, así que ¿cómo sabe Mega que son todas la misma película? Incluso si Mega tiene una forma de conocer que hay 200 películas idénticas sin descifrarlas, el hecho es que sabe algo muy importante: que hay 200 películas idénticas. Y si a uno de

los usuarios le cae un puro de la SGAE o la RIAA, ¿cuánto tardarán los otros 199 usuarios en poner sus barbas a remojar? En suma, cualquier procedimiento de detectar archivos duplicados es una vulnerabilidad porque revela información acerca de dichos archivos.

En su web, Mega intenta aclarar este y otros conceptos. Afirman que la deduplicación se hace sobre los archivos cifrados, lo que implica que no pueden descifrarlos. Vale. Pero luego se queda a gusto afirmando:

Si el mismo archivo se sube dos veces, cifrado con la misma clave aleatoria de 128 bits, solamente se guarda una copia en el servidor

De acuerdo con eso. Pero díganme, genios de Mega: ¿cuál es la probabilidad de que dos usuarios distintos utilicen la misma clave aleatoria de 128 bits? Pues una entre 2^128. Y resulta que 2^128 es una cifra con 39 dígitos decimales. Es más probable acertar el gordo de la lotería primitiva seis veces seguidas (sin ser concejal de urbanismo). Menos mal que enseguida matizan:

O bien (¡y esto es mucho más probable!), [si] un archivo se copia a otra carpeta o a otra cuenta de usuario mediante el administrador de archivos o la API, todas las copias apuntarán al mismo archivo físico

Esto ya tiene más sentido. No en el primer caso, porque eso de almacenar varios archivos iguales es algo tonto; pero resulta que un usuario puede compartir un archivo con otros usuarios, y lo que hace la deduplicación es sencillamente darles acceso al mismo archivo en lugar de crear más copias.

Según parece, una medida adoptada con el sano propósito de ahorrar espacio de almacenamiento ha sido tan mal explicada que prácticamente se han disparado en el pie. Personalmente, no me gusta la forma de actuar en lo que respecta a archivos duplicados. Si mi colega me ha pasado una copia de una peli, prefiero que él tenga su copia y yo la mía. Entiendo que Mega no quiera malgastar espacio, pero yo tengo un espacio asignado, y la forma en que lo lleno es cosa mía.

El modo de encadenamiento

Los archivos cifrados se guardan según un esquema llamado ECB (Electronic Codebook Mode). No quiero enrollarme demasiado, y emplazo al lector interesado a que eche un vistazo a mi libro sobre criptografía, pero el cogollo del asunto es que un archivo grande M se cifra en bloques: M = (M1, M2, M3 … Mn). Existen diversas formas de efectuar el proceso de cifrado. La más sencilla, la ECB, consiste en cifrar cada uno de los bloques de forma independiente y luego unir todos los bloques cifrados obtenidos. Es decir, si Ek es nuestro algoritmo de cifrado, hemos hecho esto:

C = [C1, C2, … Cn] = [Ek(K1), Ek(M2) … Ek (Mn)]

El modo ECB es sencillo y rápido, ya que el bloque cifrado Ci depende solamente del bloque en texto llano Mi. El problema es que permite a un atacante hábil hacer jugarretas. Por poner un ejemplo sencillo, supongamos que hablamos de películas. Yo cojo varias y las cifro con la misma clave. Si las películas son todas de la misma productora, tendrán los mismos fotogramas iniciales (los focos del logo de la 20th Century Fox, por ejemplo), y por lo tanto los primeros bloques cifrados serán iguales entre sí. De ese modo, un atacante podría obtener información sobre el tipo de película o su procedencia, lo que le vendría muy bien a los abogados de la Fox.

Hay otros tipos de encadenado de bloques que permiten evitar estos ataques, pero adolecen de sus propios problemas, como la propagación de errores. Mucho me temo que el único motivo por el que Mega escogió el modo ECB es por su rapidez. Muchos usuarios entenderán eso de “cifrado mediante AES de 128 bits,” pero pocos sabrán los entresijos de seguridad relativos a los diferentes modos de encadenado. De todos modos, los de Mega parecen reconocer implícitamente la vulnerabilidad del modo ECB, porque anunciaron “¡no usaremos ECB!”, con exclamación incluida.

Si pierde usted la contraseña, la pierde para siempre

Hay dos constantes en el uso de una contraseña por parte del usuario medio. Una: escogerá contraseñas débiles en gran número de casos. Dos: tarde o temprano, se le olvidará. Este segundo problema es algo muy común. Sea por olvido o por cualquier otro motivo, llega el momento de cambiar la contraseña. Y no es una tontería, porque la contraseña desbloquea nuestras claves de cifrado. Sin ella, todo el contenido de nuestra cuenta de Mega es solamente un montón de bits. La propia Mega incide en la importancia de ese hecho: “la única clave que Mega exige que se almacene en el lado del usuario es la contraseña de login, en el cerebro del usuario”

Los servicios de Internet suelen dar dos alternativas: o bien recuperar la contraseña mediante alguna verificación de identidad (las típicas preguntas del tipo “¿cuál era el nombre de su mascota?”), o bien crear una contraseña nueva. Incluso en caso de que toda vaya bien, cambiar de contraseña cada cierto tiempo es una buena política de seguridad. Bien, pues ¿saben ustedes cuál es el procedimiento que usa Mega para cambiar o recuperar contraseñas? En una palabra: ninguno. Si a usted se le olvida su contraseña, AJO Y AGUA, jamás podrá recuperar sus archivos.

Lo triste es que no hay motivo técnico para que esto sea así. Mega ha reconocido el problema, y promete mejoras para el futuro, pero lanzar un servicio de almacenamiento sin la menor posibilidad de cambiar claves es como si Ford lanzase un nuevo modelo de vehículo al mercado y luego se olvidase de enviar repuestos a los concesionarios.

Mi clave es más grande que la tuya

En la actualidad, los expertos en seguridad recomiendan claves RSA con una longitud mínima de 2048 bits. Las claves de 1024 siguen siendo seguras en la actualidad, pero visto lo visto en el pasado, mejor ir a lo seguro. El servidor seguro SSL de Mega https://mega.co.nz utiliza cifrado de 2048 bits, pero también utiliza https://*.static.co.nz,

con clave de 1024 bits. Mega afirma que lo hace para ahorrar tiempo de CPU. No es realmente un problema, pero la verdad es que 2048 bits hubieran dejado buen sabor de boca.

¿Fiarme yo?

Mega ha descargado gran parte de la seguridad en el usuario. Esto es, en parte una buena idea, pero también es malo. El motivo: el ordenador medio es más vulnerable que una caja de zapatos. El usuario medio (ese que, según House, es idiota) usa un ordenador cuyo sistema operativo es vulnerable frente a virus, troyanos y todo tipo de bichos malos. Incluso sistemas bien protegidos pueden ser presa fácil de fallos de programación recién descubiertos o no parcheados.

La idea de Mega es que el usuario se sienta protegido incluso frente a ellos mismos. Da igual si el personal de Mega está infiltrado hasta el tuétano por el FBI, porque nuestros archivos se almacenan cifrados, algo así como esos guadamuebles que salen en los programas de subastas de Energy.

Sin embargo, sí que tenemos que fiarnos de Mega. El programa en JavaScript para crear las claves en nuestro navegador lo han creado y enviado ellos. ¿Cómo podemos estar seguros de que alguien no lo ha sustituido por una copia con fallos? ¿Y si Mega intenta engañarnos con un JavaScript vulnerable? La propia Mega reconoce que el usuario puede no fiarse de ellos, y le aconseja que en ese caso acceda a su cuenta mediante otras aplicaciones que no sean su web segura. Pero acto seguido afirma que “cualquier fabricante de software que ofrezca actualizaciones online de aplicaciones puede plantar código troyano en ordenadores específicos, con graves consecuencias.” Es decir, nos están diciendo que ojito con lo que instalemos en nuestro ordenador. Esto es algo conocido y no es un fallo específico de Mega; lo indico como recordatorio de que invocar cosas del tipo “AES y RSA-2048” no convierte un sistema en seguro por arte de magia. Esto es criptografía, no Harry Potter

Crackeando el sistema

Se ha informado de que existe un programa llamado Megacracker que permite recuperar la contraseña de algunos usuarios de Mega. Aunque esto se ha señalado como una constatación de la vulnerabilidad de Mega, no es totalmente cierto. Voy a intentar explicárselo de la forma más breve posible.

Cuando se intercambian contraseñas o se guardan en bases de datos, basta hacer una copia para tirar abajo la seguridad del sistema. En los últimos años se han robado bases de datos con millones de contraseñas de todo tipo de usuarios, desde Sony hasta la NASA. Para paliar el problema, no se utilizan las claves tal cual, sino que se las pasa por una función llamada hash. Ese valor de hash representa a la clave, pero no permite averiguar nada sobre ella.

Recuerda levemente a la letra del DNI. Si no quiero revelar mi número de DNI pero tengo que identificarme, basta con que el verificador me pregunte “¿cuál es su letra del DNI’? Yo

le digo cuál es, él comprueba si es la correcta y listo. El problema es que hay solamente 26 letras disponibles, así que la función que calcula la letra a partir del número del DNI no sirve como función hash, pero esa es la idea.

Eso significa que tomo mi contraseña, digamos que es 1234, la paso por la función hash y obtengo la ristra ue8gd18g2. Envío ue8gd18g2 y el servicio online verifica si hay un usuario con mi nombre cuya contraseña tiene un hash igual. Si es así, ya estoy verificado; en caso contrario, puerta. La ventaja de este procedimiento es que el servicio online ni siquiera necesita saber mi contraseña, le basta con el hash.

El problema es que, en ciertas circunstancias, ni siquiera el hash es completamente seguro. En teoría, no hay forma de obtener la contraseña a partir de su valor hash, pero en la práctica, y aquí está el detalle, los usuarios suelen escoger contraseñas débiles. Un atacante no tiene más que probar muchas contraseñas, calcular el hash de cada una de ellas y ver si coincide con el hash de la mía. Mi amigo el atacante toma 1234 y lo pasa por la función hash, obtiene ue8gd18g2, y luego ve que yo tengo un hash igual a ue8gd18g2. La conclusión es evidente: ese usuario está usando 1234 como contraseña. El proceso es automático. Hay programas que permiten efectuar miles de estas comprobaciones por segundo; y si usamos tablas ya precomputadas, esos miles se pueden convertir en millones.

La máxima de Schiller de “contra la estupidez, los propios dioses luchan en vano” es el eslogan no oficial de todos los BOFHs del mundo. Cada vez que un usuario escoge una contraseña fácil (y el término “fácil” es muy amplio, se lo aseguro), no hay más que coger el hash correspondiente y listo. Pero la idea de la función hash no es mala; es excelente, y si se utiliza bien resulta un arma extraordinaria contra los atacantes.

Como en otros casos similares, el diablo está en los detalles. Implementar una defensa basada en funciones hash es buena idea, pero sólo a condición de que se cumplan ciertas precauciones. Veamos si Mega aprueba o falla.

Precaución uno: use sal.

El término “sal” alude a un pequeño paquete de datos que se añade a la contraseña antes de calcular su valor de hash. El resultado es mayor seguridad, ya que los valores hash H(1234) y H(1234+sal) son totalmente distintos. Los ataques tipo “tabla arcoíris,” en los que se usan montones de valores hash precalculados, se vuelven ineficaces. Incluso conociendo el valor de la sal, el atacante necesitaría calcular montones de valores hash para dar con la contraseña adecuada; y puesto que la “sal” es aleatoria y cada usuario tiene un valor distinto, los métodos actuales de comprobación en grandes cantidades se vuelven inútiles. Bien, la pregunta es ¿usa Mega algún tipo de sal? No encuentro información al respecto, pero el programa Megacracker no dice que use sal en absoluto, y de hecho dudo que pudiese funcionar si hubiese sal en el sistema hash que usa Mega. A falta de confirmación, mi conjetura es que Mega no usa sal. FAIL

Precaución dos: use una función hash lenta.

Sí, han leído bien. Habitualmente se suelen buscar funciones criptográficas rápidas y eficientes, pero recientemente se prefiere justo lo contrario en el campo de las funciones hash. La razón es sencilla: puesto que hay programas capaces de calcular gran número de funciones hash, cuanto más lento de calcular sea el hash, tanto más difícil lo tendrá un atacante. Es como un cajero automático donde se puedan introducir todos los PIN posibles, sean correctos o no. Un ladrón de dedos ágiles podrá probar las 10.000 combinaciones en principio, pero si el cajero tarda cinco segundos en procesar cada intento, el ladrón necesitará demasiado tiempo. Hay funciones hash lo bastante lentas para dificultad el trabajo del atacante. Mega no utiliza ninguna de ellas, sino que se basa en el algoritmo rápido de cifrado AES. Mala elección. FAIL.

Peor aún, lo que implementa Mega ni siquiera es una función hash, sino un bicho llamado CBC-MAC. Resulta que un MAC es un Código de Autenticación de Mensajes, diseñado básicamente para comprobar si un mensaje ha sido alterado (sea por ataque deliberado o por errores en la transmisión). Un CBC-MAC tiene ciertas aplicaciones en criptografía, pero no es una función hash adecuada porque el mensaje original puede alterarse sin que el MAC lo detecte. DOBLE FAIL.

Condición tres: no le enseñes el hash a desconocidos.

Si has metido la pata con tu función hash, lo menos que se te puede pedir es que mantengas el valor hash de tu contraseña lo más oculto posible. Darle al enemigo el valor hash, sobre todo si se trata de una función inadecuada, rápida y no usas sal, es buscarte problemas. Sin embargo, ¡eso es precisamente lo que hace Mega! Cuando envía el email de confirmación, incluye el típico enlace en el que hay que pulsar. La dirección del enlace incluye, entre otros datos, el hash de la contraseña del usuario. Es decir, si seguimos con el ejemplo anterior, donde teníamos H(1234)= ue8gd18g2, lo que estamos haciendo es darle ue8gd18g2 al enemigo; bueno, al enemigo y a cualquiera que esté mirando. Sabiendo el valor de hash, el tipo de función hash usada, y encima sabiendo que no hay sal por medio, más te vale no haber escogido una contraseña débil. Y eso es precisamente lo que aprovecha Megacrack. FAIL.

Estrictamente hablando, este fallo es también atribuible a todos aquellos usuarios que piensan que 1234 o el nombre del perro son buenas contraseñas. Sobre Megacrack, el comentario de Mega es sucinto y hasta cierto punto sarcástico: “un excelente recordatorio de que no hay que usar contraseñas de diccionario o fáciles de adivinar, sobre todo si la contraseña también sirve como clave de cifrado maestra para todos los archivos almacenados en Mega” El problema es que cualquier servicio online ya debe contar con que el usuario medio es cortito, y habilitar todas las defensas posibles. Implementar métodos de hash tan inseguros como los de Mega es lo mismo que decir en voz alta “sí, el cliente es idiota, y nosotros también.”

Consideraciones prácticas

Yo, debo reconocerlo, no soy amigo de la Nube. He perdido demasiados artículos en la Red, confiando en que la web duraría eternamente, para aprender que, si no quieres perder archivos, lo mejor es guardarlos en casa; y si quieres mantenerlos protegidos, más aún. Por

supuesto, no se molesten en contarme los mil y un casos en que sería útil tener archivos a disposición en cualquier lugar en que me conecte, porque eso ya lo sé. Acepto que la Nube tiene sus ventajas. Lo que no entiendo muy bien es la ventaja de usar Nube cifrada para las aplicaciones a que están destinado Mega.

No nos engañemos, ese servicio está diseñado para subir, compartir y bajar películas y demás archivos grandes de procedencia digamos dudosa. Con independencia de las consideraciones éticas, morales y legales de este proceder, piense usted un poco. Mega, al igual que Megaupload, reside en Nueva Zelanda, y por los mismos motivos. No es por los preciosos paisajes que todos conocemos desde que vimos la trilogía del Señor de los Anillos en el cine, ni siquiera porque allí vive la reina geek de Naukas, sino porque allí el FBI no puede encarcelar al amigo Kim Dotcom. Es decir, motivos legales que les interesan a ellos, no a nosotros.

Cada vez que quiera usted bajarse una película de su cuenta, los datos tendrán que recorrer decenas de miles de kilómetros y llegar hasta su ordenador, en el otro punto del globo, a la velocidad que le deje su proveedor de ADSL. Incluso con una velocidad de 20 megabits por segundo (que ya es mucho), mi copia de Star Trek tardaría más de diez minutos en bajar, y yo solamente he tenido conexión a esa velocidad en el mismo lugar donde me doy el lote con Scarlett Johansson, es decir, en sueños. Luego hay que descifrar la película. Y si quiero subirla, todos sabemos que la velocidad de subida es mucho menor (la A de ADSL significa Asimétrico). Tendré suerte si consigo colgarla en mi cuenta en menos de una hora. Eso para cada película que quiera mover. La verdad, no le veo ventaja frente un bittorrent. Es cierto que bajar algo mediante eMule o utorrent tarda más, pero cuando tienes el archivo en tu ordenador, ya no dependes de una conexión ADSL o de un servicio que hoy es gratis, mañana será de pago y el próximo día puede no existir. Como un tal Megaupload, por ejemplo.

Personalmente, coincido con otros autores en que el sistema de seguridad de Mega no está diseñado para proteger al cliente sino para proteger a Mega. Han intentado crear una especie de guardamuebles anónimo, donde el conserje mira para otro lado sin querer saber lo que los clientes guardan en el interior, y donde nadie más que el usuario tiene llaves de la puerta. De esa forma, cuando lleguen los hombres G, podrán encogerse de hombros y pretender que ellos no sabían nada. El problema es que sus candados son débiles y las puertas tienen fallos, así que si usted quiere proteger sus datos, le recomiendo que no los suba a Mega. Allí solamente una cosa es segura: que el amigo Dotcom va a seguir forrándose vendiendo humo. En este caso, el humo de la seguridad aparente.

Compartir

Facebook136 Twitter130 Menéame20 Google+29 LinkedIn1

Entradas Relacionadas

¿Te tima tu proveedor de Internet?

Equilibrium, o Batman contra el Gran Hermano

Hallada la clave de los “relámpagos” en la alta atmósfera

32 Comentarios 3 Trackbacks

http://naukas.com/2010/12/05/te-tima-tu-proveedor-de-internet/

http://naukas.com/2013/01/17/equilibrium-o-batman-contra-el-gran-hermano/

http://naukas.com/2011/11/17/hallada-la-clave-de-los-relampagos-en-la-alta-atmosfera/

Participa Suscríbete

doodom 28 enero, 2013

Muy interesante el artículo y muy acertado. Solo un inciso: el hecho de que dos películas empiecen con la misma secuencia de créditos no quiere decir que el código una vez cifrado con la misma clave vaya a ser idéntico, porque también tendrían que coincidir los fotogramas a un nivel de milisegundos, el bitrate y utilizar los mismos codecs de vídeo y audio.

Por no decir que dudo que, si dos archivos de vídeo tienen tamaños diferentes, los primeros fragmentos codificados de las mismos vayan a ser idénticos por más que utilicen los mismos codecs, la misma tasa de bits y los fotogramas iniciales sean calcados. Tendrían que ser muchas las coincidencias a nivel de bit entre ambos ficheros para que tal cosa sucediera, cosa que a mi me parece bastante improbable.

Me ha llemado especial atención lo de “sal”. Curiosamente es una técnica que he utilizado alguna que otra vez en mi breve trayectoria como desarrollador web sin ser consciente de que tenía un nombre y era una práctica habitual en pos de la seguridad.

+1 (0 Votos) Responde

eduo 28 enero, 2013

Hola.

Aunque no vaya a ser yo quien defiende Mega y similares (al contrario, soy un muy vocal detractor del mismo y de sus usuarios “ideales”, de acuerdo a lo que a Mega le conviene, aunque me viene de conocer al Kim de hace muchos años y desconfiar de él por sistema) el problema de la deduplicación me parece que es otro que no queda nada claro en su explicación ni del todo claro en la de aquí.

El problema es que ficheros cifrados con distintas claves no pueden ser iguales, por definición. Es posible guardar un hash del fichero antes de guardarlo (es lo que hace dropbox, lo que hace “subir” cosas a veces casi instantaneo) y es posible usar ese hash guardado para decidir si algo ya existe. Pero si lo que se guarda es el fichero ya cifrado el problema es otro: Como puedo yo bajarme mi “copia” (que no es tal) del fichero si la que ya existe en el sistema está cifrada con otra clave.

Es posible, claro, si nos permite por el hecho de haber querido subir el mismo fichero el bajar el fichero de alguien más para el que no tenemos la llave, so excusa de que es el mismo.

En el caso de varios “compis” compartiendo un fichero sí que lo veo posible, ya que se asume que todos tienen las claves de todos. Guardar una sola copia no solo es normal sino

de esperar (de nuevo, dropbox lo hace). Y si no estuviesen cifrados incluso podría hacerse a un nivel aún más bajo para optimizar aún más el espacio.

Al final el río suena se mire como se mire, me parecería correcto que la gente esperase a ver si trae piedras antes de mojarse los pies. El único problema es que entre tanto lenguaje la gente se pierde y piense que ya todas sus preocupaciones para subir y bajar “cultura” están cubiertas por la insistencia de un desconocido con un modelo de negocio poco claro.

0 (0 Votos) Responde

[email protected] 28 enero, 2013

Titular sensacionalista y críticas sin mucha base. Los archivos no se duplican cuando usas la función de “importar a tu cuenta” en vez de “descargar”. Yo lo veo muy lógico. No obstante, buen resumen de cómo funciona Mega.


angel asenjo 28 enero, 2013

Muy interesante, y util, artículo.

Me ha molestado un poco el hincapié que se hace sobre el uso “pirata” que se hace de estas páginas (entre las que podemos incluir el Terabox de Movistar, Dropbox, SugarSync… etc.).

Somos muy numerosos los profesionales de la imagen que utilizamos estos espacios para compartir y enviar nuestros archivos.

Saludos.


ufator 28 enero, 2013

si no usas torrents pa qué comentas todo el tocho


unomas 29 enero, 2013

Muy buen articulo aunque no coincido con tus opiniones personales, la idea del megaupload pirata la tienes tu, y media españa… Y eso me apena, ya antes de que lo cerraran y en un futuro proximo ofrecian un servicio rapido y fiable, por culpa de gente que sube ‘el señor de los anillos’ megaupload crecio… Pero tambien cerro, como dices para eso

ya esta bittorent.A mi parecer hay que darle tiempo a que mejore, no podemos exigir que cambien cosas, simplemente pedirselo, es un servicio que ofrecen ellos., es un o lo tomas o lo dejas.


MichaelCor 30 enero, 2013

Buenas. Muy buen artículo. Solo un par de ideas:

La complejidad para romper funciones hash, dado que se basa en que las contraseñas son débiles, se podría aumentar exponencialmente pasando la función n veces o incluso utilizando diferentes algoritmos, lo cual lo haría impredecible para un atacante. No¿??

Y otra cosa, la ventaja de Mega frente a bittorrent puede que no se vea fácilmente en España pero es evidente en países como Alemania dónde tienes a la GEMA espiando nodos ‘falsos’ de bittorrent y que te meten multas de varios miles de euros por usar redes P2P y prácticamente te tienen capado todo lo que tenga copyright, tienes que recurrir a proxies extranjeros, vpns y movidas. Otra cosa es que sea ético o no, pero útil es.


Laertes 30 enero, 2013

Veo mucho la expresión “dispararse en el pie”, traducción lieteral del inglés “shoot your own foot”. ¿Ya nadie utiliza aquello de “tirar piedras en el propio tejado”?

¿Saber otro idiomas? sí, imprescindible, ¿importar expresiones que no existen en un idioma de otros? sí, pero ¿sustituir expresiones perfectamente válidas y conocidas por otras provenientes de idiomas extranjeros porque mola mucho? Creo que no.

+1 (0 Votos) Responde

eduo 30 enero, 2013

Hombre, no. Es que no significan lo mismo.

“Tirar piedras en el tejado propio” significa ir creando una situación que se volverá en nuestra contra. Hacer algo que no conviene pero poco más. Se implica que hay un aviso de que lo que se hace va a salir contraproducente y se ignoran esos avisos.

“Dispararse en el pie” significa meter la pata de forma contundente, inmediata y desproporcionadamente catastrófica. No hay aviso y no hay forma de detener y evitar el daño.

Que se adopte TODO lo que sea de TODOS los sitios donde enriquezcamos. Así funciona el lenguaje y asi funciona bien.

Otra cosa es que usemos frases sin saber lo que significan, algo que por ejemplo que provoca que pensemos que unas y otras son intercambiables.

Todo esto sin entrar en la multitud de frases y palabras que usas de forma cotidiana que son importadas de otros lenguajes y que no escuchas como raras por haberte criado con ellas. La versión del idioma que te es familiar no tiene más mérito para ser la que deja de evolucionar que las que vinieron antes.



Creo que tienes una pequeña confusión con estas expresiones inglesas:

- “to shoot one´s own foot” equivale a nuestro “tirar piedras en el propio tejado”- “to put one´s foot in it” equivale a nuestro “meter la pata”

“to shoot one´s own foot” no equivale a “meter la pata” y no “significa meter la pata de forma contundente, inmediata y desproporcionadamente catastrófica. No hay aviso y no hay forma de detener y evitar el daño” como comentas.

Por ejemplo, un par de definiciones en inglés que he encontrado con un sencilla búsqueda:

To stop your own progress. (en http://www.idiomquest.com)

If you shoot yourself in the foot, you do something that damages your ambition, career, etc. (en http://www.usingenglish.com)

O una tradución en un diccionario inglés-español:

http://dictionary.reverso.net/spanis...io%20tejado

Y si quieres ejemplos de uso de ambas expresiones prueba con:

http://www.linguee.es/espanol-ingles...tejado.html

Por lo demás, ya he dicho que no estoy en contra de enriquecer el lenguaje con otras expresiones o palabras cuando no existe un equivalente y por supuesto no considero que las expresiones que me son más familiares tengan más mérito que cualquier otra. Lo que no me parece bien es ese afán que parece haber por traducir expresiones del inglés de manera literal, como puede ser la ya comentada “to shoot one´s own foot” o el horrible “patear el culo” que se oye en multitud de doblajes, traducción literal de “to kick someone´s ass”,

cuando en español hay multitud de formas de expresar lo mismo como pueden ser “dar una paliza” o “partir la cara”.

Este tipo de traducciones literales lo único que muestra es un desconocimiento de ambos idiomas.

Para que se entienda mejor, ¿a que no se te ocurriría traducir “de perdidos al río” como “from lost the the river” (salvo de manera humorística)? Pues eso mismo es lo que se hace al usar en español “dispararse en el pie” o “patear el culo”.

O yendo más allá, ¿a que nunca nunca dirías en inglés “throw rocks onto your own roof”? Porque creo que tus interlocutores se iban a quedar bastante flipados.


Eduo 31 enero, 2013

Hola

Te equivocas, aunque antes de entrar en corregirte por que entiendes mal las páginas y textos que citas o ponerte yo las que demuestren que te equivocas y seguir un juego idiota de ver quien sabe matizar mejor, quien sabe seleccionar mejor webs que le conviene interpretar mal o quien ha vivido y dado clases de idiomas más tiempo mejor dejare la discusión ahí, siendo irrelevante para el punto importante de lo que dices: que una frase es mejor que las que ha suplantado o que nuevas que la empiecen a suplantar sólo porque sea la que tu conoces y prefieres.

Porque honestamente no pensarás que el concepto ha tenido siempre una única frase y es justo la que defiendes, no?

Que el idioma evolucione hacia donde la gente le de la gana, como lo ha hecho toda la vida, y que ignore argumentos sin sentido que van en contra de todos a la historia y evolución del mismo.



De acuerdo, me guardo mis argumentos sin sentido. Pero la próxima vez que hables con un inglés le sueltas alguna traducción literal de una expresión española y cuando no te entienda le dices que el idioma evoluciona como le da la gana a cada uno.

0 (0 Votos)

eduo 31 enero, 2013

Error. Tu mismo has puesto lo que hace el matiz que importa: “Veo mucho la expresión”

El idioma evoluciona como le da la gana a la mayoría que lo usa. Precisamente como *NO* funciona es como te de la gana a ti o como me de la gana a mí.

En cuanto a lo otro, poco inglés no técnico usas si no reconoces la multitud de palabras y frases traídas de otros idiomas, algunas directamente sin traducir, que adopta sin mayores aspavientos.

0 (0 Votos)


Pues nada, tienes toda la razón, me has convencido. A partir de ahora voy a hablar con expresiones traducidas literalmente de otros idiomas. Agarra en un segundo que voy a gastar un penique.


eduo 31 enero, 2013

“Literalmente” no es sinónimo de “Correctamente”. “Hold on” es un idiom que se traduce, literalmente, como “aguanta”. Casualmente una frase común ya en español: “Aguanta un momento/segundo/minuto/rato”.

“Gastar un penique” es literal, sí, pero depende de que los baños costasen un penique. No funciona tan bien pero da igual, mientras la gente entienda lo que significa.



“Literalmente” no es sinónimo de “Correctamente”. Has expresado en una frase lo que he intentado explicar en todos mis comentarios.


eduo 31 enero, 2013

No. Dado que en ambos casos la frase es una frase hecha que no es literal. “Literalmente” no aplica a lo que dices, que sólo arguye si es correcto o no usar una frase cuando antes existía otra que, a tu parecer, funciona casi igual (imagino que la has investigado y sabes que su origen no es también extranjero y antes se usaba una diferente, ya que esa es la mitad de tu argumento)

En ambos casos es una frase en sentido figurado cuyo funcionamiento estriba en que la gente que la usa y la que la lee o escucha sepan, ambos, lo que significa.

Dado que la regla es esa cualquier frase, sin importar su origen, es igual de válida. Dado que el lenguaje muta constantemente es normal que las frases también lo hagan. Dado que el lenguaje optimiza es normal que frases más cortas o más explícitas vayan reemplazando a las que requieren saber algo de antemano.

Acordemos discrepar. Tu consideras que la versión del lenguaje y sus frases que tú conoces y a las que estás acostumbrado son más válidas que las que existían antes y a las que estas reemplazaron y que las que vengan después y reemplazarían a estas. Yo considero que el lenguaje cambia de forma impredecible de acuerdo a uso que mama de todos sitios, incluídos otros idiomas y culturas (“Saltar el tiburón” es una frase casi común hoy en día entre muchos grupos, y no tiene absolutamente ningún contexto deducible en español, pero mientras todos sepan para qué se usa, vale).

Usar frases nuevas y usar palabras nuevas no tiene diferencia.


leni 3 febrero, 2013

Puedes explicar lo que significa “saltar el tiburon”??

0 (0 Votos)

eduo 3 febrero, 2013

Puedes explicar lo que significa “saltar el tiburon”??

Google puede.


Laertes 3 febrero, 2013

@leni, en español no significa nada. En inglés sí, es una expresión que se usa cuando los guionistas de una serie la han alargado tanto que ya no saben lo que hacer para continuarla y las historias son cada vez más absurdas. El origen es porque uno de los protagonistas de la comedia “Días felices” salta, literalmente, sobre un tiburón en uno de sus episodios

0 (0 Votos)

Laertes 1 febrero, 2013

Con este último comentario me has explotado la mente, me como un pastel humilde. Demasiado largo, chupadores.


antonio 4 febrero, 2013

Qué interesante esta discusión filológia que no tiene nada que ver con el artículo! Gracias!


bonzo 5 febrero, 2013

Si me lo permite, un par de matizaciones, Sr Quirantes.

La “Sal” añadida a una función hash no necesita ser aleatoria,pero sí impredecible, de forma que el atacante no pueda emplearlapara construir una tabla de valores precomputados que permitaatacar a diferentes usuarios, sesiones, etc. que deberían usar diferentesvalores para este parámetro. Ya lo dice la canción:“¡Ay que función hash tan salada, tolón, tolón…!”

Por otro lado, estrictamente hablando, las tablas “Rainbow” se utilizan enataques que son variantes de un ataque de tipo TMTO, cuya idea fue concebidapor M. E. Hellman. Se trata, por tanto, de un ataque más sofisticado que un ataque de diccionario normal y corriente donde, por ejemplo, solo es necesario almacenar pares de: Texto en claro -> Imágen función hash/texto cifrado/etc.

Por lo demás, excelente e interesantísimo artículo.Un saludo.


bonzo 5 febrero, 2013

P.D. La canción a la que me refería decía:“…me da leche merengada,¡ay que función hash tan salada!¡¡¡¡tolón, tolón!!!”

P.D. ¡¡¡¡Mamma mía, no sabía que la infografía podía ser tan excitante!!!!!


EL fore 3 abril, 2013

No me gusta que ofendan los torrents y su velocidad, la velocidad depende de los leechers, seeders y velocidad de la conexión a internet.

Es lo que he aprendido descargando 275 GB de juegos sin sin incluir los programas y la música.

Que vivan los torrents!!!!!!

PD: thepiratebay ocupa el primer lugar de sitio de descargas mas usado.


Kim 19 agosto, 2013

muy interesante todo lo leído, en relación al párrafo de deduplicación, en mi opinión creo que es una política anterior de MegaUpload que simplemente migraron al nuevo servicio. De todas formas se explica que si un usuario, con su misma clave sube 20 veces el mismo archivo (por error consciente) es bastante lógico que el servicio sólo conserve 1 archivo y sus 20 entradas por optimización.


Dvip 17 noviembre, 2013

Pues mientras no guardes archivos que realmente sean privados o realmente importantes, no hay problema, las pelis se encuentran en cualquier lado, pero las fotos de tu fin de semana en la playa, o los documentos de tu empresa no se guardan con cualquier proveedor.


MCHD 25 febrero, 2014

Interesantísimo artículo, inclusive para los que sabemos poco del tema.Quería preguntar: Si uno comprime un ZIP con una carpeta-discografía completa y le agrega dentro (por si algún otro tuvo la misma gran idea) un archivo propio como puede ser una foto de su propio pie, ¿ hay una alta o baja probabilidad de que la discográfica descubra lo que uno está guardando dentro? y cuando me refiero a discográfica también lo hago pensando en el propio Host. ¿Pueden descomprimirlo para asociar las canciones a otros clientes o es inviable?.Un saludo!


Carlos 20 abril, 2014

Si pueden, Drive lo hace, no se pueden subir .exe, ni nombres como office, etc.. te borran los archivos por patentes, cosa que mega no hace.. es ahí la gracia, yo he compartido aplicaciones , etc… y es bastante bueno, no sé si para cosas personales, estoy leyendo más al respecto.


KanaKana 31 mayo, 2014

Interesante el tema, pero no creo que los usuarios de mega posean información tan importante como para hackear a todos, como mucho tratarán de buscar el correo de todos los usuarios para venderselos a una compañia de esas que envian spam al correo. si alguien tiene algo muy importante que desea guardar, simplemente hay que tenerlo uno mismo y no subirlo a ninguna pagina de ningun tipo, sin importar la seguridad que indiquen tener.

all hail Mega! >-< lo saque de code geass


CajonDesastre 3 octubre, 2014

Que risa con lo de “saltar el tiburon” menos mal que es una frase muy usada y de moda. Debo ser un cavernicola entonces, es la primera vez que la escucho. Si el lenguaje se modifica con las frases de las series americanas, que nos espera, mama mia!!!


Isaac Rasqui 28 enero, 2015

Pues no te vi participar en la convocatoria que organizó Kim Dot Com en Febrero de 2013 apenas 15 después de que publicaras este artículo, en el que ofrecía recompensa a quien pudiera hackear Mega para descubrir vulnerabilidades.

Hablar es gratis chico.


Deja un comentario

Tu email nunca será mostrado o compartido. No olvides rellenar los campos obligatorios.

Nombre Obligatorio

Email Obligatorio

Web

Comentario

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <cite> <code> <del datetime=""> <q cite=""> <strike> 

Notificarme los nuevos comentarios por correo electrónico. También puedes suscribirte sin comentar.

Suscribirse al RSS Recibe las actualizaciones por e-mail

mega, un servicio no tan seguro

Documents