Mensajes

Buenas,

como bien te ha dicho warcry si cambias las DNS en tu equipo solo afectará a tu equipo, el router hará la consulta DNS a la dirección IP que especificaste en el apartado TCP/IP del equipo.

En cambio, en el router, cambia la historia. Todo depende de si tienes DNS Relay activado o no en el mismo. Sin DNS Relay, todos los equipos de la red apuntarán a la dirección IP de los DNS que pusiste en tu router (ej: 8.8.8.8 los de Google) pero si tienes DNS Relay activado las DNS de todos los equipos apuntarán a la dirección IP (en red) del router (ej: 192.168.1.1), así que el router haría la consulta y no tu equipo.

Y te preguntarás, que ventajas ofrece el DNS Relay, o usar el router como operador de las consultas DNS. Bueno, existe algo llamado caché DNS. Todos los equipos tienen una, pero es mejor que la cache esté en el router, ya que si visitas mucho una página desde un equipo y te conectas desde otro equipo a la misma web, el router no debe consultar los servidores DNS ya que los tiene en cache.

Sin el relay, todos los equipos que no tienen la web en cache han de hacer la consulta DNS, independientemente de que otros equipos de la misma red hayan resuelto la dirección de la misma web anteriormente.

Espero se entienda.

Saludos!

Como ejemplo está bien, pero ten cuidado con el parseo/análisis de datos arbitrarios y su consecutivo almacenamiento, pues un buffer overrun podría terminar en consecuencias serias. Por ejemplo podría mandar un paquete que no siguiera el esquema de request de HTTP, sin GET ni POST ni otros.

Lo mejor es seguir el RFC, también te ahorraras cuelgues estilo DOS/DDoS manteniendo la tabla de sesión (socks) en buen estado (apache slowloris que recuerdos).

Saludos!

Buenas,

las password están cifradas con AES, supongo que las password al exportar el archivo .cfg se ciran con una clave simétrica generada por el router, la cual estará residente en alguna NVRAM o quizá fue generada por tu ISP y guardada por ellos en su DB antes de entregarte el router. Lamentablemente esa info es confidencial. Incialmente me pregunté que sentido tiene cifrar una password con un algoritmo simétrico en un router, pero veo que son passwords de tu ISP, por lo tanto tiene mucho sentido.

Al ser tu el dueño de tu router puedes entrar via portal alejandra y activar la administración personal de tu router, cambiar la password y desactivar el control remoto via portal alejandra, otra alternativa sería instalar OpenWRT, el cual es un firmware libre para routers que provee una funcionalidad excelente, simplemente tu modelo ha de ser compatible, la configuración no es nada tediosa si lees la documentación oficial. Otra opción también sería deshabilitar el protocolo TR069, el cual da acceso a tu ISP al router para actualizar su firmware.

Saludos!

Y hablando acerca de cifrado RSA; compañero Kub0x ¿que opinas de ciertos sistemas que buscan romper el cifrado RSA?

Algunos algoritmos que se supone fueron desarrollados para con tal propósito y que usan la técnica de FACTORIZAR EL MODULO, al menos los que he encontrado son: la criba cuadrática, criba numérica o el algoritmo de factorización en curvas elípticas.
[...]

opino que dichos algoritmos de factorización llevan empleándose y optimizándose desde 3 decadas a lo sumo. La complejidad de los mismos es: Lenstra ECM subexponencial, Quadratic Sieve y GNFS se acercan al tiempo polinomial pero no son cuasi-polinomiales por lo tanto se quedan en la categoria NP (non-polynomial). Resumiendo, la complejidad de los mismos nos dice que todavía no existe un algoritmo de factorización polinomial capaz de resolver el problema subyaciente, excluyendo el algoritmo de shor, el cual lo resolvería en tiempo poly solo en un ordenador cuántico.

El problema de estas cribas es que necesitan de una indexación y recolección de datos descomunal para poder establecer un sistema que nos conduzca a la factorización del módulo (en este caso).

Métodos parecidos existen para otros algoritmos de criptografía asimétrica como Diffie Hellman y Curvas Elípticas (ECC). Aquí la tarea es tratar de calcular la clave establecida resolviendo el logaritmo discreto de la clave pública de una de las partes para así obtener su privada y computar dicha clave compartida.

Que decir que RSA tiene otro frente abierto, de hecho el problema RSA (https://en.wikipedia.org/wiki/RSA_problem) nos dice que no existe un método para resolver las raices e-ésimas de las exponenciales módulares de tipo [latex]m^{e} mod n[/latex]. Por lo tanto el problema RSA se considera igual de complejo que el de la factorización de enteros.

¿cual seria su opinión en caso de un cifrado a 64 bit?

Creo que aquí te refieres a algoritmos de cifrado simétricos. Bueno su robustez es otra. Bien sabemos que RSA por ejemplo ocupa tamaños de clave de 1024-2048-4096-... bit, pero la key strength o robustez de la clave no es el tamaño del módulo (1024-2048..) sino depende del algoritmo de factorización a emplear (este tema te ayudara mucho: http://crypto.stackexchange.com/questions/8687/security-strength-of-rsa-in-relation-with-the-modulus-size).

Pongo la tabla comparativa de la key strength de RSA vs la key strenght de un algoritmo simétrico como AES.

Strength  RSA modulus size   Complexity bit-length
  80        1024               86.76611925028119
112        2048              116.8838132958159
128        3072              138.7362808527251
192        7680              203.01873594417665
256       15360              269.38477262128384

Como se puede ver, según crece el tamaño en bit de la clave del algoritmo simétrico, también lo hace el tamaño de la clave RSA y la complejidad de bit entre ambas clave es mucho mayor. Podríamos decir que AES-128 tiene una complejidad similar a RSA-3072. Con esto quiero decir que si utilizaramos RSA-3072 como nuestro criptosistema, la complejidad de factorizar el módulo por GNFS sería equivalente a romper AES-128, pero realmente no se ha demostrado que sea así, todavía.

Un cifrado de 64-bit hoy día, como lo fue DES a partir de los 70, suponiendo que es seguro a ataques de criptografía diferencial, sería extremadamente inseguro debido al poder computacional, ya que la clave sería computable, además teniendo en cuenta la paradoja del cumpleaños, podrías dar pistas sobre la clave en [latex]2^{32}[/latex] operaciones de cifrado por bloque.

Bueno espero que os haya servido esta información, cualquier cosa ya sabeís.

Saludos!

Bueno tampoco me voy a explayar demasiado,

la criptografía es una rama muy amplia derivada de la matemática en general, no sólo se aplica la teoría de números, sino que hay problemas matemáticos que en este siglo están siendo aplicados a la criptografía. Actualmente, como sabreís, los algoritmos estandar asimétricos son conmutativos (Abelianos) y guardan ciertas propiedades interesantes para implementar la trapdoor y derivar una password común.

Hoy día dichos algoritmos se consideran seguros bajo un tamaño X de clave, el cual va incrementando progresivamente a lo largo de los años. Llegará un día en el que nuestro conocimiento sobre la computación avance, y también sobre los problemas matemáticos comprendidos en la crypto. Para ello, como sabemos que es cuestión de tiempo, los criptólogos investigan nuevas opciones que satisfagan cierta complejidad computacional.

Existen algoritmos más fuertes que los actuales, Lattice based (NTRU), Group based crypto (conjugate search, decisional problems etc) pero no han sido revisados y probados tanto como fueron DH, ECC o RSA. Personalmente ando estudiando la no conmutatividad en grupos (no abelianos) ya que por ejemplo puedes hacer un anillo conmutativo  forzando ciertas propiedades y de esta forma obtener un análogo conmutativo, pudiendo componer un cifrado fuerte.

Así que me atrevo a decir que la criptografía jugará uno de los papeles mas esenciales en este siglo, y a mi parecer, el papel más importante después del cuántico.

Saludos!

Buenas,

las firmas digitales son creadas aplicando un algoritmo de resumen (Hash) sobre el plaintext (datos) y cifrando el hash resultante con la privada.

Ahora, el destinatario ha de validar la firma digital presentada sobre el plaintext. Para ello el destinatario ha de saber el módulo y el exponente, ambos públicos SIEMPRE.

El destinatario descifrará la firma digital mediante la exponencial modular (donde participan exponente y módulo) y obtendrá un hash. El destinatario comprobará que el hash del descifrado coincide con el hash del plaintext. En tal caso hacemos las siguientes afirmaciones:

- La key RSA asociada a la firma digital es válida, ya que la firma fue creada por la clave privada del emisor, la cual sólo es conocida por el mismo.
- Los datos recibidos son válidos, ya que la firma digital se ha verificado en su totalidad. Es decir, nadie modificó esos datos o modificó la estructura de la firma digital.

Me huele a que estás usando o configurando PGP.

Saludos!

[solo utiliza 1 sola iteración]

Gracias por el apoyo matake, me gusta arrojar luz a este subforo, que es de los más oscuros  

Con dejarse de líos realmente me refería a utilizar PBDKF2 (Password based KDF) ya que la que cité (md5 + openssl) solo utiliza 1 sola iteración (malditos negligentes), no es estándar y se considera insegura.

En el RFC de PBKDF2 recomiendan 1000, los de OWASP 64.000 + un valor aleatorio para securizar el proceso. En ciertas comunidades recomiendan medir el tiempo de las iteraciones en milisegundos de la KDF siendo el líimte 9ms (creo). Con partir desde mil e ir subiendo basta.

4.2 Iteration Count

  An iteration count has traditionally served the purpose of increasing
  the cost of producing keys from a password, thereby also increasing
  the difficulty of attack. For the methods in this document, a minimum
  of 1000 iterations is recommended. This will increase the cost of
  exhaustive search for passwords significantly, without a noticeable
  impact in the cost of deriving individual keys.

Las KDF devuelven un output del tamaño que quieras, dicho output lo puedes partir para derivar la clave simétrica y el IV. Por lo tanto sólo necesitas la passphrase y el salt. Recuerda que AES sin GCM o una MAC no provee de integridad, así que el esquema queda suceptible a modificaciones.

Con TLS (HTTPS) podrás negociar la clave simétrica sin peligro, ya que después de verificar su certificado, sólo esa persona podrá descifrar los parámetros a negociar (esto es RSA, lo más básico). A partir de ahi se derivan las claves de cifrado (sesión) y de integridad de los mensajes.

Por lo que veo quieres implementar AES sobre TLS y hacer tu propia librería de https o implementación.

Información:

https://tools.ietf.org/html/rfc2898
https://crypto.stackexchange.com/questions/5440/can-i-use-my-random-iv-for-aes-as-a-salt-for-pbkdf2
https://crypto.stackexchange.com/questions/3484/pbkdf2-and-salt

Saludos!

[EDIT: El tema debería moverse a Criptografía.]

Te detallo el criptosistema que deberías implementar (todo ello con OpenSSL):

Para realizar una conexión segura debes cumplir con la autenticación, integridad y confidencialidad. El tema es que la crypto simétrica (AES,TDES,RC4 etc) se ocupa de la integridad y la confidencialidad, pero la autenticación en internet sólo se logra compartiendo una clave simétrica que ambos dos conoceís, para ello debes usar certificados x509v3 o una estrategia mejor, el key pinning (ya que sólo tendrás un certificado).

¿Y que es el key pinning? Bueno empresas como google, yahoo, microsoft etc tienen docenas de certificados para sus dominios y subdominios. En tal caso la verificación de certificados tiene sentido, pero en el tuyo, siempre enviarás el mismo certificado, así que es mejor hardcodear/bindear/pinear la clave en el equipo del cliente, y así no tienes que enviar ningún certificado. Hazme caso, lo mejor en internet es de antemano saber la clave del otro, al estilo SSH.

¿RSA, DSA, ECDSA, ECDHE, PRF wtf is this? Bueno, en tu protocolo tendrás que utilizar una suite criptográfica que provea de los tres principios citados arriba. El más simple es usar RSA para intercambiar la clave de sesión, ahi con la PRF se deriva la master key y luego con la misma PRF la clave de sesión y de integridad. Vamos que si no te quieres complicar emplea RSA para negociar la clave AES_CTR. Cifrar con CBC es seguro también teniendo en cuenta el padding, bueno OpenSSL ya la cagó hace tiempo con esto, supongo que usar CBC no implica riesgo, me gusta mas GCM porque es como usar un algoritmo MAC de integridad todo en uno.

Personalmente te recomiendo TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256. Donde ECDHE (Eliptic curve diffie hellman) es el algoritmo de key exchange, RSA es el algoritmo de verificación de la firma digital sobre los parametros ECDHE, AES 256 GCM (Galois counter mode) es el algoritmo de cifrado simétrico que ya provee de integridad y SHA256 como PRF (Pseudo Random Permutation). La PRF se usará en el campo Finished del TLS Handshake para verificar que no hay MITM.

Con este sistema obviamente dependerías de la lib OpenSSL, pero teoricamente es 100% seguro, por el momento.

Saludos!

EDIT: El tema debería moverse a Criptografía.

Así es, el IV y salt deben entregarse al otro extremo para el desciframiento. Ten en cuenta que el IV/salt hacen que un mismo plaintext o mensaje se cifre de diferente manera, por lo tanto preserva la confidencialidad, sin que un atacante pueda distinguir el mismo mensaje de dos ciphertext.

Sobre el tema de la clave, lo ideal, es que tenga el tamaño en bytes recomendado, para así cumplir con los requirimientos de seguridad en AES. Para ello tendrás que formar la Master password a través de una KDF (Key Derivation Function), como bcrypt o PBKDF2. No te asustes, estas funciones toman tu password y forman una de mayor tamaño, en caso de AES formarán una de 256 bytes (el tamaño ideal para la mejor seguridad).

Ahora para probar la calidad de la aletoriedad, bueno fíjate ten este fragmento de código extraído del git de la librería JS:

Código (javascript) [Seleccionar] Expandir

function cryptoJsAesEncrypt($passphrase, $value){
    $salt = openssl_random_pseudo_bytes(8);
    $salted = '';
    $dx = '';
    while (strlen($salted) < 48) {
        $dx = md5($dx.$passphrase.$salt, true);
        $salted .= $dx;
    }
    $key = substr($salted, 0, 32);
    $iv  = substr($salted, 32,16);
    $encrypted_data = openssl_encrypt(json_encode($value), 'aes-256-cbc', $key, true, $iv);
    $data = array("ct" => base64_encode($encrypted_data), "iv" => bin2hex($iv), "s" => bin2hex($salt));
    return json_encode($data);
}

Como ves primero genera un salt aleatorio con OpenSSL (OpenSSL utiliza algoritmos de generación criptograficamente seguros) para luego en la variable salted concatenar sucesivos hashes MD5 compuestos por la passphrase, el salt y el hash anterior.
Después obtiene la key de los 32 primeros bytes de la variable anterior, el IV de 16 bytes a partir del byte 32 de la misma variable.

Lo mejor es dejarse de líos y utilizar una KDF estandar, ya que la liberia CryptoJsAES implementa una KDF no estandarizada empleada por OpenSSL:

CryptoJS uses the non-standardized OpenSSL KDF for key derivation (EvpKDF) with MD5 as the hashing algorithm and 1 iteration. The IV is also derived from the password which means that only the actual ciphertext, the password and the salt are needed to decrypt this on Java side.

Saludos!

Buenas,

OpenSSL ofrece conexiones SSL y además tiene una suite de cifrado muy buena quizás la mejor librería de cifrado que haya, sus librerías estáticas son 2: libeay32.lib (13.405kbs) ssleay32.lib (2.232kbs).

Mientras que CURL ofrece conexiones para muchos protocolos con SSL pero nada de cifrado, su librería estática libcurl.lib pesa 1.613kb.

Todas las librerías de las que hablo son para versiones release.

Pero, ¿Por qué opción decantarse si utilizamos cifrado en nuestro programa?.

¿Y para conexiones sin texto plano, que pesará menos conexiones con la WINAPI o con CURL?.

Saludos.

Depende. OpenSSL si quieres implementar un servidor que utilice una suite criptográfica segura, o bien, CURL si simplemente quieres desarrollar un cliente que realice conexiones SSL/TLS remotas.

Supongo que para plaintext CURL, además de que es open src.

Saludos!