Mega, Un Servicio No Tan Seguro

Published on December 2016 | Categories: Documents | Downloads: 53 | Comments: 0 | Views: 196
of 20
Download PDF   Embed   Report

Comments

Content

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 Comentarios3 Trackbacks
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
ufator 28 enero, 2013
si no usas torrents pa qué comentas todo el tocho
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
Laertes 31 enero, 2013
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
Laertes 31 enero, 2013
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)
Laertes 31 enero, 2013
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
Laertes 31 enero, 2013
“Literalmente” no es sinónimo de “Correctamente”. Has expresado en una frase lo que he
intentado explicar en todos mis comentarios.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
antonio 4 febrero, 2013
Qué interesante esta discusión filológia que no tiene nada que ver con el artículo! Gracias!
0 (0 Votos) Responde
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 emplearla
para construir una tabla de valores precomputados que permita
atacar a diferentes usuarios, sesiones, etc. que deberían usar diferentes
valores 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 en
ataques que son variantes de un ataque de tipo TMTO, cuya idea fue concebida
por 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.
0 (0 Votos) Responde
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!!!!!

0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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!

0 (0 Votos) Responde
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.
0 (0 Votos) Responde
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
0 (0 Votos) Responde
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!!!
0 (0 Votos) Responde
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.
0 (0 Votos) Responde

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

Nombre
Email

Obligatorio
Obligatorio

Web
Comentario

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr

title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del
datetime=""> <em> <i> <p> <q cite=""> <strike> <strong>

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


Suscribirse al RSS
Recibe las actualizaciones por e-mail

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close