Mensajes

Buenas.

Lo único que he encontrado es la publicación en el medio de prensa oficial del MIT (en inglés): https://news.mit.edu/2016/programming-language-living-cells-bacteria-0331

Según ellos podrás compilar el programa y pasar la estructura del ADN a la bacteria para que realice los fines programados. En mi campo he leído sobre autómatas celulares destinados a computación criptográfica, supongo que esto está relacionado con ello, y por fin dejaría de ser algo teórico, aunque no sé el alcance que puede llegar a tener, pues no me muevo por el campo biológico-científico.

Saludos!

El problema con truzone.org es que su certificado sólo es válido para el dominio cloud.rolandocaldas.com. Esto se debe a una mala configuración por parte del administrador de dicho dominio, el cual debería haber incluído truzone.org y www.truzone.org en el campo SAN del certificado.

Lo mejor cuando sale el mensaje de "conexión no privada" es verificar a mano el certificado presentado, para saber si nos están engañando o es una mala configuración del administrador de dicho dominio.

Saludos!

Te dejo un post muy interesante sobre el cracking de múltiples cifrados de substitución, lo encuentro interesante pues tu cifrado es similar a las características aquí descritas, el post está en inglés, y la comunidad es muy extensa (actualmente soy miembro y hago mis preguntillas ahí). Segro que te ayuda a mejorar la seguridad y a emprender un criptoanálisis sobre el mismo.

https://crypto.stackexchange.com/questions/3826/possible-ways-to-crack-simple-substitution-ciphers

Si tienes alguna duda no dudes en comentarla.

Saludos!

JoseluCross he de comunicarte que tu cifrado tiene una vulnerabilidad en la forma que cifra los espacios, por lo que puedo deducir facilmente la clave de cifrado, me explico poniendo como ejemplo el que tu has puesto antes:

clave: hola
texto plano (plaintext): este es un mensaje super secreto y nadie nunca lo va a descifrar
texto cifrado (ciphertext): OdbHhVaa__lPO_aDTVlV_aSU]VQUOe]aco\DNZSaXf\FKoZRhgOaKoRH]TWI\R`
alfabeto:  (espacio)!"#$%&'()*+´-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_abcdefghijklmnopqrstuvwxyz{|}~

Vamos paso por paso, cogemos las primeras cuatro letras -> "este" y vemos como cifra:

'e' corresponde a O mediante 'h'
's' corresponde a d mediante 'o'
't' corresponde a b mediante 'l'
'e' corresponde a H mediante 'a'

hasta aquí todo bien, ahora toca el espacio entre "este" y "es"

(espacio) corresponde a 'h' mediante 'h' (está dándonos parte de la clave)

Sigo...

'e' corresponde a V mediante 'o'
's' corresponde a 'a' mediante 'l'

Toca otro espacio entre "es" y "un"

(espacio) corresponde a 'a' mediante 'a' (sigue dándonos parte de la clave)

y así sucesivamente hasta obtener la clave entera o parte de la clave "hola".

Simplemente he analizado el texto en el notepad mirando el mapeo entre ciphertext y plaintext, un analisis estádistico en base a tu alfabeto sería lo ideal.

Saludos!

Estás en lo cierto, el procedimiento es adecuado. Como bien dices, también existen alternativas que requieren bootear desde otro sistema, estás últimas para no alterar el sistema o evitar detecciones.

En este link encontrarás info muy útil, básicamente se listan métodos y técnicas relacionadas con el tema, así como los comandos que has posteado. Ellos lo califican de silencioso, pero en un PC bien protegido con HIPS supongo que saltarían las alarmas, por eso en un ámbito profesional es mejor bootear desde otro OS (sobre todo en el ámbito forense).

https://www.securusglobal.com/community/2013/12/20/dumping-windows-credentials/

Saludos!

Vigènere depende del tamaño de clave, básicamente si el tamaño de clave es inferior al tamaño del texto a cifrar (plaintext) se reutilizará la misma clave, pudiendo observar patrones en el ciphertext, deduciendo así la clave.

Si por algún motivo el atacante tiene en su poder ciertas partes del plaintext, le sería mucho más fácil obtener ciertas partes de la clave, por lo que podría deducir aún más carácteres del plaintext. Remarcar que si el tamaño de clave es igual al tamaño del plaintext se equipararía con un One-Time-Pad (se podría decir que a cada carácter una clave).

Saludos!

Buenas arget,

me refería a los RFC sobre estándares criptográficos. Obviamente las instituciones que he nombrado anteriormente no componen dichos documentos, pero fíjate que dichas instituciones son las que revisan y aprueban las primitivas criptográficas contenidos en dichos documentos (RFCs), así que para mi casi es lo mismo (por eso tiendo a generalizar).

Bueno los PRNG si tienen una tendencia (bias) su internal state puede ser determinado y de esta manera determinar su salida al completo, pudiendo recuperar por ejemplo la clave generada para un cifrado en AES (o cualquier otro). En el caso que expuse Dual_EC_DRBG sirve para el mismo propósito. Gracias a dios Win$ no utiliza el susodicho PRNG, todo ello bien documentado en el documento del FIPS-140 asociado a sus módulos criptográficos.

En lo de los FLOPS me has pillado, ¿puedes darme algo de docu para enterarme cuantos FLOPS tiene un equipo convencional y cuantos FLOPS son necesarios por ejemplo para factorizar un semiprimo con NFS o criba cuadrática? Lo único que se sobre el cómputo de la NSA es que un día Utah saldrá por los aires si eso explota

Para concluir, supongo que nadie enterado sobre estos temas se fía de las implementaciones privativas, lo mejor sin duda es utilizar alternativas libres, revisándo el código y ajustándolo a tus gustos.

Saludos!

Lo primero, y por tanto menos importante (XD) es que sí, lo he escrito yo, no sé a qué te refieres con el formato, a mi parecer se ve igual que cualquier otro post, solo que no me gusta escribirlo en el textarea de elhacker.net y lo escribo en gedit para luego copiar y pegar.

Mil perdones, no vi el encabezado del mensaje, ahí puedo apreciar que es de tu autoría.

¿Pero llegar a decir que el AES en inseguro? Yo lo considero totalmente seguro, a 256 bits, mediante el modo CBC o incluso el CTR basta, perfecto. Puedes decir que el que la contraseña sea de 256 bits como máximo te limita, yo particularmente lo soluciono aplicándole primero un SHA-256. Ah, espera, que como también es de la NSA ya no vale. SHA-2 lleva ya casi tanto tiempo en juego que la PS2 y si no se ha publicado nada, yo me callo la boca (no es lo mismo que SELinux). E igualmente confío plenamente en RSA. Y ya, para que me crucifique la comunidad criptográfica, digo que RC4 bien implementado (como casi todo menos el cifrado de César) es plenamente seguro, es cierto que el one-time-pad directamente implementado mola más y es más seguro, pero no es viable, lo siento.
Si no te gustan vete a tu esquinita a usar IDEA, Blowfish, RC5, Serpent, SHARK, Xenon y hasta el cifrado francmasón, por lo menos podrás comunicarte con la pared.

Supongo que intentarás esclarecer la situación actual. Espero que nadie de aquí diga lo contrario, es verdad que el órgano que regula la crypto en su mayor parte es la NSA, junto a los ya nombrados FIPS y NIST. ¿Los RFC de dónde crees que sacan sus especificaciones? No hay RFC si no se revisa y se aprueba el protocolo primero por estos órganos. Que decir que todos los módulos criptográficos, incluyendo los hardware (amazon y demás) cumplen con el FIPS-140 (y el 180) https://en.wikipedia.org/wiki/FIPS_140 cosa que se puede llegara desactivar, para utilizar otras versiones alternativas también aprovadas por el NIST. Si he llegado a este punto es por ver que implementaciones corren en nuestras máquinas a diario. Toda la info es pública, puedes ver que algoritmos CSPRNG, simétricos, asimétricos, parametrización, etc se utiliza en los susodichos módulos incluso a nivel de kernel, como generan la entropía y demás. Desde 2001 el PRNG estándar está contaminado, pero eso ya lo hablé en el otro post.

Como bien dices, el problema son las implementaciones, no la matemática subyacente, si el PRNG está contaminado ni AES se salva. A RSA se le pagó 1millon de $ para hacerlo estándar en sus módulos criptográficos (alavado sea Bruce Schneier por hablar sin tapujos). A TLS se le encuentran fallos de downgrade porque permite suspender el handshake temporalmente dando pie a crackers a computar la clave de sesión, para así completar el "finished". A mi eso me parece una aberración. A parte, sino, se le encuentran fallos de compresión, de padding, como bien dices, de reutilización de grupos modulares, a esto último le llaman DHE (ephemeral), vale, que seleccionan un exponente arbitrario cada vez, ¿pero y el módulo primo? Si no se cambia este último cualquier centro de cómputo puede llegar a computar la mayoría de índices (log. discreto) sobre el mismo grupo rompiendo así la crypto (LOGJAM).

Ahora los medios sensacionalistas e ingorantes dicen que ya se está factorizando a nivel cuántico (que si aplicando Shor etc), si leyesen el paper del MIT, se darían cuenta que están en pañales, pero no se molestan en verificarlo (el número en cuestión es el semiprimo 15). Ni siquiera resolviendo la hipotesis de Riemann se podría romper RSA, eso sí, podría darse el caso que resolviéndola se generara un nuevo algoritmo de factorización que cambiara las cosas.

No sé, propondría hacer aquí, en elhacker.net nuestra propia implementación de TLS y ver hasta dónde llegamos, pero creo que con la pereza que al final se respira en estos foros no llegaríamos ni a escribir el #include <stdio.h>

¿Cuántos usuarios crees que son capaces de comprender las entrañas de un tema tan extenso como la crypto? Llevo cosa de 2 años centrado en esto y no es moco de pavo. Me veo capaz, pero el foro de crypto pasó a mejor vida me da.

Buenas LaiaxanIV,

es grato ver retos criptográficos por aquí. El modo CBC encadena el bloque del plaintext actual con el ciphertext anterior aplicando XOR sobre ambos y cifrando con la clave (KS) creando así un nuevo ciphertext hasta llegar al último bloque, por lo tanto si no generamos un IV varios mensajes iguales o con el mismo comienzo darían un ciphertext igual en su comienzo o en su totalidad.

Lo he resuelto en C#, pero antes de dártelo mascado te doy un par de pistas:

- El IV inicialmente es 1byte, pero fíjate que se le ha aplicado un XOR con cada byte de la clave (KS), dándonos un IV final de 16bytes.
- La imagen ha sido cifrada obteniendo un ciphertext, y posteriormente se le ha concatenado el IV, por lo tanto si quieres descifrar la imagen debes de quitar los primeros 16 bytes para obtener el ciphertext original.
- Esos 16 primeros bytes que debes quitar son el IV, necesario para instanciar la clase AES encargada del descifrado.
- Quedaría algo así: AES.Decrypt(primeros_16_bytes_del_archivo_cifrado, fichero_cifrado_menos_los_16_primeros_bytes), siendo el primer parámetro el IV y el segundo el resto del bloque.

Aquí te dejo el código utilizado y el link a la imagen, espero te haya servido de ayuda. Cualquier cosa nos dices.

Link a la imagen ->  https://s23.postimg.org/9mccdlzkb/plaintext.jpg (no la pongo como tal porque es grande y no cumple las normas del foro)

Código (csharp) [Seleccionar] Expandir

using System;
using System.IO;
using System.Security.Cryptography;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace AES
{
    class Program
    {
        static void Main(string[] args)
        {
            using (Aes AESCSP = AesCryptoServiceProvider.Create())
            {
                byte[] ciphertext = GetCipherText();
                byte[] plaintext = new byte[ciphertext.Length];
                AESCSP.Mode = CipherMode.CBC;
                AESCSP.Key = File.ReadAllBytes(@"C:\\Users\\kub0x\\Downloads\\c.key");
                AESCSP.IV = GetIV();
                int plainbytes = AESCSP.CreateDecryptor().TransformBlock(ciphertext, 0, ciphertext.Length, plaintext, 0);
                Array.Resize(ref plaintext, plainbytes);
                File.WriteAllBytes(@"C:\\Users\\kub0x\\Desktop\\plaintext.jpg", plaintext);
            }
        }

        private static byte[] GetIV()
        {
            byte[] IV = new byte[16];
            FileStream fs = File.Open(@"C:\\Users\\kub0x\\Downloads\\c.enc",FileMode.Open);
            fs.Read(IV, 0, IV.Length);
            fs.Dispose();
            return IV;
        }

        private static byte[] GetCipherText()
        {
            FileStream fs = File.Open(@"C:\\Users\\kub0x\\Downloads\\c.enc", FileMode.Open);
            byte[] ciph = new byte[fs.Length-16];
            fs.Position = 16;
            fs.Read(ciph, 0, ciph.Length);
            fs.Dispose();
            return ciph;
        }

    }
}

P.D= arget mola ver que a alguien más le interesa este tema por estos lares, ya nadie habla de crypto.

Saludos!

No sé si serás tú el autor del texto (por el formato), pero supongo que tienes los conocimientos necesarios. No estaría mal que leyeras mi "análisis" sobre ECC, PKI y variantes de hace un año -> https://foro.elhacker.net/criptografia/iquest_os_parecen_realmente_seguros_los_cifrados_actuales-t431759.0.html

El problema es el mismo que con los protocolos iniciales de internet, la subversión. No es lo mismo buscar un bug en una libería criptográfica que romper el principio Gaussiano de su Disquisitiones, cosa que todavía no he visto en ningún lado. Tienes algoritmos que rebajan el coste (pollard's, baby-giant, lattices etc), pero nada que factorice o nos dé el índice de la modular exponencial en un tiempo razonable.

Cómo bien dices POODLE y ahora DROWN son cagadas similiares, basadas en el puro principio de Bleichenbacher sobre los Oracles. Con FREAK y LOGJAM sufrimos la tontería de los algoritmos de exportación de los años 90, donde la NSA obligaba a empresas extranjeras a usar tamaños de clave inferiores, facilitando el desciframiento de las comunicaciones. Pero tu hablas de fallos de Padding (DROWN, POODLE), Compresión (CRIME), Downgrade (FREAK, LOGJAM) y reutilización de primos en DH, esto último muy viejo ya que casi todos los servers utilizan varios grupos multiplicativos modulares, no uno hardcodeado (crypto efímera, DHE).

El NIST y la NSA van de la mano, el NIST crea la NSA revisa, todo ello cumpliendo el FIPS. En el tema de las ECC de arriba queda bien claro. Pero piénsalo, el problema REAL vendrá cuando los problemas en los que se basa criptografía pura, y no los protocolos subyacentes (TLS/SSL-PKI), comience a ser rebajada a un problema de parbulitos. Todos sabemos que PKI+TLS es inseguro, pero lo subyacente lleva más de 40 años perdurando.

Saludos!