Pregunta:
¿Qué tan seguro es el nuevo cifrado de Mega-sitio?
woliveirajr
2013-01-21 21:21:36 UTC
view on stackexchange narkive permalink

El nuevo sitio Mega, sucesor de Megaupload, afirma que toda la información está cifrada con una clave simétrica a la que solo tiene acceso el usuario.

Los términos generales se enumeran aquí:

Todos los archivos almacenados en MEGA están encriptados. Todas las transferencias de datos desde y hacia MEGA están encriptadas. Y aunque la mayoría de los proveedores de almacenamiento en la nube pueden reclamar lo mismo, y lo hacen, MEGA es diferente: a diferencia de la norma de la industria donde el proveedor de almacenamiento en la nube tiene la clave de descifrado, con MEGA, usted controla el cifrado, tiene las claves y decide a quién concede. o denegar el acceso a sus archivos, sin requerir ninguna instalación de software arriesgada. ¡Todo está sucediendo en su navegador web!

En la página de desarrolladores hay algunos detalles sobre AES 128bits, 64 bits aleatorios como valor inicial, y así sucesivamente. pero no puedo encontrar detalles sobre cómo el usuario final tendrá esa protección.

¿Alguien sabe cómo funciona realmente su cifrado / seguridad? ¿Es realmente seguro?

Ciertamente escuché cosas malas sobre su implementación. Desde XSS, sobre PRNG de entropía incorrecta hasta el problema fundamental de la criptografía javascript (normalmente no se da cuenta si el servidor envía código maligno, quizás solo para usted)
No me gusta su uso de MAC. Esto significa que cualquiera que pueda leer un archivo, puede generar MAC válidos. Eso me parece dudoso. Prefiero usar un árbol hash y firmar la raíz.
No sé si es seguro, pero de por vida no puedo hacer que funcione en absoluto. A veces, el entorno no se carga, a veces se carga, pero no podré hacer nada ni todo lo demás. Es un juego de azar.
Cuatro respuestas:
Thomas Pornin
2013-01-21 22:08:19 UTC
view on stackexchange narkive permalink

Los detalles son relativamente escasos, pero la sección 5 de la página de desarrolladores a la que enlaza 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 fragmentos, cada fragmento tiene su propia MAC, de modo que puede "procesar" fragmentos individualmente . Sin embargo, parece que no hay un número de secuencia en el MAC; Por lo que dice el texto, el IV para el MAC del segundo fragmento es el CBC-MAC del primer fragmento, lo cual es malo porque podría ser alterado por un individuo malintencionado. En la práctica, esto significa que el MAC por fragmento es útil solo si transmite los datos desde el principio , en el orden debido; el acceso aleatorio sería susceptible a 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.

Su MAC es dudoso en muchos sentidos. Creo que usar un MAC en primer lugar fue una mala idea.
Usar un modo de cifrado autenticado es una buena idea; y eso es lo que hacen: es CCM. Pero lo modificaron un poco, lo que es suficiente para levantar banderas de advertencia.
Creo que los MAC (o modos autenticados como CCM) no se ajustan a la situación en primer lugar. Ya que solo tienen uno para firmar y verificar, ya que permite que cualquiera que pueda leer el archivo falsifique MAC. Tampoco es trivial crear MAC fragmentados (no les fue tan bien en ese departamento, como ya señaló). TahoeLAFS utiliza un hash de árbol firmado para esto, que es muy superior en mi opinión. De esa manera, puede tener claves de lectura y escritura separadas y no es posible realizar ataques de mezcla.
@ThomasPornin ¿Qué considera "manejo cuidadoso de las claves" como se indica en su tercer párrafo? ¿Cómo maneja correctamente las llaves? Por ejemplo, si hay una tabla de base de datos con columnas fileID y fileKey, y ciframos la clave simétrica antes de guardarla en fileKey. Lo ciframos / desciframos enviando la fila para su procesamiento a través de API (SOA) a un CryptoBox (HSM del pobre), que contiene la clave criptográfica maestra. El cifrado / descifrado ocurre allí. ¿Se considera esto seguro? ¿Deberíamos usar también HMAC en fileKey?
La administración de claves de @Matrix: es un tema muy extenso ... Aquí, las claves por archivo deben generarse con un PRNG lo suficientemente fuerte y almacenarse en un archivo de clave maestra (que está encriptado con contraseña), con todas las MAC debidas para prevenir un atacante de alterar una clave o intercambiar claves. Esto tiene ramificaciones en la forma en que establecen el vínculo entre archivos y claves, y eso no parece estar completamente especificado. Las páginas web publicadas actualmente dan una idea de lo que hacen, pero no se acercan a nada que yo llamaría "una especificación decente".
Callum Wilson
2013-01-22 21:43:41 UTC
view on stackexchange narkive permalink

Parece que hoy hay prensa que describe las fallas de seguridad con el enfoque de seguridad adoptado por Mega; consulte este artículo que comenta 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 Mega administradores que las claves no pueden ser capturadas por un cambio de servidor en el javascript
  3. generación predecible de números aleatorios
  4. contraseña perdida = datos perdidos
No estoy de acuerdo con "contraseña perdida = datos perdidos". Esa es la naturaleza de la bestia, no puede evitar esto cuando usa cifrado.
Los propios Mega reconocen el problema de la "contraseña perdida = datos perdidos" y están creando un sistema para permitir a los usuarios recuperar datos utilizando una función de exportación clave. Consulte: http://gizmodo.com/5978164/mega-is-going-to-handle-password-resets-different-than-everybody-else
CryptoCowboy
2013-07-28 08:50:46 UTC
view on stackexchange narkive permalink

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á usando el mismo cifrado que todos los demás. Probablemente Full Disk Encryption (FDE / AES) para datos en reposo en la nube MEGA combinada con Internet Protocol Security (IPsec) que asegura la comunicación entre el almacenamiento en la nube PC / MEGA. Ambas formas de cifrado utilizan claves de 128 bits o 256 bits.

La triste noticia es que el cifrado de 128 bits o 256 bits ha sido pirateado. De hecho, recientemente, algunos piratas informáticos de Israel rompieron la clave GSM de 128 bits en 2 horas. Por lo tanto, la piratería por fuerza bruta es un desafío (ejecutar números secuenciales hasta que obtenga una coincidencia) o irrumpir en la tienda de claves ubicada en el cuadro de destino. FDE funciona utilizando un almacén de claves que está integrado en la memoria. Irrumpir en la memoria y obtener la llave utilizada para desbloquear. Así que hay un par de formas en las que los buenos piratas informáticos pueden romper el cifrado. La buena noticia es que la mayoría de los datos cifrados mantienen fuera al 90% de la población. Sin embargo, es el 10% de lo que tienes que preocuparte. :)

Léo Léopold Hertz 준영
2016-01-24 19:20:31 UTC
view on stackexchange narkive permalink

Los usuarios revisan el código 128 AES de manera 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 de forma progresiva. El código SDK ha estado disponible desde 2014 y ahora estamos revelando código para nuestro cliente web y extensiones de navegador.

Cambios en 2016 en cryptopp.h

  • función decodeintarray
  • serializekey función

Cambios 2016 en cryptopp.cpp

  • AsymmCipher :: serializeprivkforjs mucha limpieza en el cifrado asimétrico; constante estática muy fácil de adivinar (0123456789abcdef);
  • mucha limpieza y códigos 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 única prueba principal que solo contribuye con el cifrado. Código sdk / tests / paycrypt_test.cpp. Prueba principal PayCrypter: hybridEncrypt

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

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



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...