No, ci sono due ragioni per cui l'accoppiamento di SSL con "ElGamal encryption" non renderà i tuoi dati "più sicuri".
La prima ragione è che tra i due attacchi conosciuti a cui ti colleghi, uno è stato risolto a lungo (è una variante dell'attacco di Bleichenbacher del 1998, usando un oracle di padding, viene risolto rendendo il server SSL non riportare errori di padding allo stage RSA), e l'altro è generico sull'uso della compressione su un flusso di dati che contiene dati segreti e dati scelti dagli hacker allo stesso tempo (purché la crittografia rilasci informazioni su i dati crittografati lunghezza , la compressione sarà un problema aggravante, indipendentemente dall'algoritmo di crittografia, anche se diversi sono impilati l'uno sull'altro). Mettere qualche altro algoritmo nel mix non offrirebbe alcun vantaggio significativo per entrambi.
La seconda ragione è che il tuo suggerimento non ha senso. ElGamal è un algoritmo di crittografia asimmetrico (chiamato dopo il suo inventore ) che, per sua natura, crittografa solo un singolo elemento breve (non più di poche centinaia di byte). Se tu fossi SSL in cascata con qualche altro sistema di crittografia, quell'altro sistema di crittografia sarebbe un algoritmo di crittografia simmetrica (ad esempio il AES ) , qualsiasi algoritmo asimmetrico come ElGamal utilizzato solo per uno scambio di chiavi iniziale ... proprio come SSL fa con RSA o Diffie-Hellman.
In effetti, quando scrivi questo:
I know "HTTPS" has the same function as "Elgamal"
bene, hai torto. Le due cose non sono comparabili e non hanno la stessa funzione.