¿Qué tan seguro es el nuevo cifrado Mega-site?

Los detalles son relativamente escasos, pero la sección 5 de ht página de desarrolladores a la que se vincula describe el tipo de cifrado que aplican. . En pocas palabras: no lo dicen explícitamente, pero es básicamente modo CCM , aunque con algunas simplificaciones en la gestión de IV . No hablan de relleno y codificación de longitud, y esto podría ser un problema.

Además, el archivo se divide en partes, cada parte tiene su propio MAC, de modo que puede "procesar" partes individualmente. Sin embargo, parece que no hay un número de secuencia en el MAC; por lo que dice el texto, la IV para el MAC de la segunda parte es la CBC-MAC de la primera parte, lo cual es malo porque podría ser alterado por un individuo malicioso. En la práctica, esto significa que el MAC por trozo es útil solo si transmite los datos desde el principio , en el debido orden; El acceso aleatorio sería susceptible de ataques.

El concepto principal de usar una clave por archivo es sólido, pero requiere un manejo cuidadoso de las claves y no hay suficientes detalles en la página para decidir si las cosas se hicieron correctamente o no. Todo apesta a una construcción casera y se sabe que las construcciones caseras son un terreno fértil para las vulnerabilidades.

parece que hay prensa hoy que describe fallas de seguridad con el enfoque de seguridad adoptado por Mega, consulte este artículo que hace comentarios sobre la investigación de Alan Woodward.

Resumen de las principales fallas:

1. longitud de la clave para la clave SSL
2. Confíe en los administradores de Mega que las claves no pudieron ser capturadas por un cambio de servidor en el javascript
3. generación de números aleatorios predecible
4. contraseña perdida = datos perdidos

El cifrado por sí solo no protegerá su información, sin importar lo que diga MEGA o cualquier otra persona. Me imagino que MEGA está utilizando el mismo cifrado que todos los demás. Probable Full Disk Encryption (FDE / AES) para datos en reposo en la nube MEGA combinada con la seguridad del protocolo de Internet (IPsec) que asegura la comunicación entre el almacenamiento en la nube de PC / MEGA. Ambas formas de cifrado utilizan claves de 128 bits o 256 bits.

La triste noticia es que 128 bits o 256 bits de cifrado han sido hackeados. De hecho, recientemente algunos hackers de Israel rompieron la clave GSM de 128 bits en 2 horas. Por lo tanto, la piratería informática de fuerza bruta es un desafío (es decir, ejecutar números secuenciales hasta obtener una coincidencia) o ingresar al almacén de claves ubicado en el cuadro de destino. FDE funciona mediante el uso de un almacén de claves incrustado en la memoria. Al entrar en la memoria, obtienes la clave utilizada para desbloquear. Así que hay un par de maneras en que los hackers buenos pueden romper el cifrado. La buena noticia es que la mayoría de los datos cifrados mantienen fuera del 90% de la población. Sin embargo, es el 10% que tiene que preocuparse. :)

Los usuarios revisan el código 128 AES de modo que se pueda garantizar la alta calidad de la implementación. Proyecto principal aquí pero sobre la criptografía de Mega aquí . Blog sobre el desarrollo aquí

  

La transparencia del código se proporciona progresivamente. El código SDK tiene   estado disponible desde 2014 y ahora estamos revelando el código para nuestra web   Extensiones de cliente y navegador.

Cambios 2016 en cryptopp.h

• función decodeintarray
• función serializekey

Cambios 2016 en cryptopp.cpp

• AsymmCipher::serializeprivkforjs mucha limpieza en el cifrado asimétrico; constante estática muy fácil de adivinar (0123456789abcdef);
• códigos de limpieza mucho más legibles (nombres de variables, estructura, etc.)

sdk/tests/paycrypt_test.cpp

• longitud fija BASE64_IV, BASE65_ENCKEY, BASE64_HMACKEY, KEYS
• prueba principal PayCrypter:hybridEncrypt

Pruebas

Solo una prueba principal única que solo un contribuyente en el cifrado. Código sdk / tests / paycrypt_test.cpp . Prueba principal PayCrypter:hybridEncrypt

//Test PayCrypter:hybridEncrypt()
string finalResult;
string contentString = CONTENT;
ASSERT_TRUE(payCrypter.hybridEncrypt(&contentString, pubkdata, pubkdatalen, &finalResult, false));

que parece estar utilizando un esquema de clave asimétrica, es decir, puede ser ineficiente con mensajes muy largos. El riesgo principal ( Wikipedia ) aparentemente está en la encapsulación clave y su definición de seguridad donde la encapsulación de datos debe ser ligeramente más fuerte. Este hecho parece ser el caso en el código al comparar la inicialización de las claves.