No, hay dos razones por las que unir SSL con el "cifrado de ElGamal" no hará que sus datos sean "más seguros".
La primera razón es que entre los dos ataques conocidos a los que se vincula, uno se ha corregido por mucho tiempo (es una variante del ataque de Bleichenbacher desde 1998, usando un oráculo de relleno; se arregla al hacer que el servidor SSL sea no informando errores de relleno en la etapa RSA), y el otro es genérico sobre el uso de la compresión en un flujo de datos que contiene datos secretos y datos elegidos por el atacante al mismo tiempo (siempre que el cifrado filtre información en Los datos cifrados longitud , la compresión será un problema agravante, independientemente del algoritmo de cifrado, incluso si varios se apilan unos sobre otros. Poner algún otro algoritmo en la mezcla no ofrecería ninguna ventaja significativa para ninguno de los dos.
La segunda razón es que su sugerencia no tiene sentido. ElGamal es un algoritmo de cifrado asimétrico (llamado así por su inventor ) que, por naturaleza, cifra solo un elemento corto (no más de unos pocos cientos de bytes). Si tuviera un SSL en cascada con algún otro sistema de encriptación, ese otro sistema de encriptación sería un algoritmo de encriptación simétrico (por ejemplo, el AES ) , cualquier algoritmo asimétrico como ElGamal se usa solo para un intercambio de claves inicial ... al igual que SSL lo hace con RSA o Diffie-Hellman.
De hecho, cuando escribes esto:
Sé que "HTTPS" tiene la misma función que "Elgamal"
bueno, estás equivocado. Las dos cosas no son comparables y no tienen la misma función.