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!

Hola gracias por las respuestas,

Para plaintext si puedes usar solo sockets supongo que será mejor que cualquier librería, respecto a eficiencia de código y peso.

En mi caso mi proyecto usa conexiones SSL, pero también quiero usar funciones de cifrado como 3DES, podría matar dos pájaros de un tiro con OpenSSL, pero el peso del ejecutable sería mucho mayor, y no me interesa.

CURL entonces lo usaré fijo, y para cifrar ¿conocéis algun cifrado con la winapi?, me refiero a cifrados que usen CBC que es el más seguro, ¿no kubox? XD, aunque para enviar datos por HTTP quizás lo mejor sea RC4 que es simple y ligero aunque menos seguro.

Pues la idea es intercambiar datos entre cliente y server de manera cifrada y segura, podrán ver las cabeceras, pero el body que vaya cifrado punto a punto, no se por cual decantarme.

No se si se podrá hacer ahí algún juego con RSA, pero molaría bastante. En plan pasarle la pública al cliente y descifrar con la privada (y si sin CAs la seguridad es de risa pero mejor que  nada).

De todas maneras.. los CAs son entidades de terceros que validan servidores HTTPs entre otras cosas, esas CAs supongo que serán servidores, esos servidores supongo que tendrán un dominio, si hacemos DNS spoofing a ese dominio, no podremos dar validez a cecrtificados falsos? (y si esto se va algo de tema) XD, yo creo que es posible.

Saludos.

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.