This article is an automated machine-translation of an article in English. We know the translation isn't perfect, but we hope it's useful for people who don't read English.

Los codificadores de Kim Dotcom de hacking en criptografía de Mega incluso mientras hablamos - en verdad "beta perpetua" estilo

Filed Under: Featured, Privacy

Kim Dotcom nuevo de intercambio de archivos venture almacenamiento, Mega, quiere protegerse de las acusaciones de no tomar medidas contra la piratería.

Lo hace mediante el uso de criptografía para asegurar que no se ve, y de hecho no se puede saber, lo que has subido.

Esto proporciona privacidad para usted (a otras personas, incluyendo el personal propio de Mega, no pueden espiar a sus archivos) y negación de Mega (otras personas, incluyendo Mega propio personal, ni siquiera se puede decir lo que sus archivos pueden ser).

Pero para cumplir esa promesa, usted tiene que conseguir el derecho de cifrado.

Como hemos explicado ayer , los primeros indicios son que los codificadores de Mega no lo había hecho: nos escribió acerca de los problemas con la entropía (el azar), la deduplicación y la utilización de datos pobremente escogidas en un máximo de sesión de Mega correos electrónicos, innecesariamente haciendo diccionario contraseña posibles ataques.

Investigadores de grupo de hackers fail0verflow posteriormente redactó otro error criptográfico: el uso de una función defectuosa de hash para autenticar el código JavaScript que hace que el trabajo de servicio completo.

Voy a tratar de explicar brevemente.

Uno esperaría que un sitio seguro para entregar todo su contenido a través de HTTPS, incluso (o quizás especialmente) el código JavaScript que impulsa la criptografía.

Mega utiliza HTTPS, pero para ahorrar dinero sirve a la mayor parte de su Javascript de "barato" servidores distribuidos, redes de entrega de contenidos que usan 1024-bit RSA claves.

→ cortos claves RSA requieren menos potencia de CPU, por lo que obtener un mayor rendimiento para un gasto determinado. Pero las redes distribuidas significar más servidores y requieren de distribución de claves widepsread, por lo que aumenta el riesgo de un compromiso.

Para aumentar la seguridad global, Mega también sirve, desde servidores centralizados que usan 2048-bits de las claves, una lista de hashes criptográficos para el contenido alojado en los "asientos baratos". Estos servidores centralizados también sirven el código criptográfico necesario para verificar los hashes.

Eso significa que usted tiene que comprometer los servidores de 2048-poco protegidos y los servidores de 1024-poco protegidos para servir secuencias de comandos no autorizados de la parte inferior de la seguridad de la red.

LO! Una clara forma de tener su pastel de seguridad, pero pagan menos para entregarlo.

Ayer, sin embargo, fail0verflow documentado el código de cifrado sirven desde los servidores de mayor seguridad.

El código hash utilizado para autenticar el código JavaScript que viene desde los servidores de menor seguridad era la función h () ​​a continuación:


function h(s)
{
var a = [0,0,0,0];
var aes = new sjcl.cipher.aes([111111,222222,333333,444444]);
s += Array(16).join('X');

for (var i = s.length y -16; i -;) {
un [(i >> 2) y 3] ^ = s.charCodeAt (i) << ((7-i y 3) << 3);
si a = aes.encrypt (a) ((i & 15)!);
}
volver a;
}
[/ Codigo fuente]

No se preocupe si usted no habla JavaScript. Todo lo que necesitas saber es lo siguiente:

  • La función h () ​​es un algoritmo conocido como una llave CBC-MAC .
  • CBC-MAC no están seguros si la llave no es segura. Puede crear una falsificación si se conoce la clave.
  • La clave utilizada en h () ​​está cableada e inseguro. Está justo ahí: la matriz de JavaScript [111111,222222,333333,444444].

Ouch. No se puede utilizar CBC-MAC así. Es necesario utilizar un hash criptográfico adecuado en su lugar.

SHA-3 o SHA-256-probablemente sería una buena idea. Como señaló fail0verflow, SHA-1 estaría bien e incluso MD5 sería mejor que el código anterior, pese a la debilidad criptográfica MD5 conocido.

El consuelo, por supuesto, es que los servicios cloud pueden emitir actualizaciones casi instantánea. Sólo servirá el nuevo código la próxima vez que un usuario visita su sitio.

(Sí, dejar de lado el control de cambios tradicional, porque el usuario no tiene que elegir si o cuando se va a actualizar. Pero también evitar la lentitud de cambio de control, ya que el usuario no puede elegir si o cuando se va a actualizar.)

Y, por supuesto, por la tarde, Mega había seguido el consejo de fail0verflow 's.

El código de cifrado 2048-bit-protegida que protege el 1024-bit protegido por código de cifrado se ha actualizado para:

1
function sha256(d)
{
h = new sjcl.hash.sha256();
for (var i = 0; i < d.length; i += 131072)
h = h.update(d.substr(i,131072));
return h.finalize();
}

Ahora, SHA-256 se utiliza en lugar de CBC-MAC con una clave de cableado.

Buen trabajo por los codificadores de Mega para obtener las correcciones rápidamente. Pero si usted está confiando en Mega para su propia intimidad, es probable que desee que preguntarse por qué no obtener las bases de su aplicación crypto justo en frente.

Los comentaristas en nuestro artículo anterior ofreció la sugerencia razonable que la necesidad de cifrado principal de Mega es la auto-preservación: asegurar su propia negación con el fin de evitar ser derribado junto con los datos de sus usuarios. Su privacidad y la seguridad viene en segundo lugar.

Hay dos soluciones muy simples si eso es cierto. Usted puede optar por uno de los dos: utilizar un proveedor diferente, o cifrar los datos usted mismo antes de dejar Mega encriptarlo.

De hecho, ¿por qué no cifrar sus propios datos usted mismo, siempre y de todos modos? Se trata de sus datos, después de todo.

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog