I just posted another article about the problem, but there are several steps which could be taken today to plug the hole. Although that won’t protect any historical communications. This involves doubling security with post-quantum cryptography (PQC) and also the use of a novel scheme that I propose here.
PQC can’t be used alone today, it’s not proven. Many of the algorithms used to secure internet communication today was thoroughly researched, peer reviewed, and tested. It stands the test of time. But PQC is relatively new, and although accelerated efforts could have been taken years ago to mature sooner, they were not. That doesn’t mean PQC doesn’t have a part to play today.
Encryption can be overlapped, yielding the benefits of both. RSA for example is very mature, but breakable by a Quantum Computer. Any PQC is immature, but theoretically unbreakable by a Quantum Computer. By combining these the benefits of both are gained, with additional CPU overhead. This should be implemented today.
Standards need to be fast tracked, and software vendors implement with haste. Only encapsulation is required, like a tunnel in a tunnel. But TLS likely already has the ability for dual-algorithm protection built into the protocol. I’m yet to find out.
In addition to the doubling described above, I have a novel approach, Whisp. Web applications (ignoring oAuth) store a hash of a password for each user, this hash can help to form a key to be used during symmetric encryption. Because symmetric encryption is also mature and unbreakable (even by Quantum Computer), it’s an even better candidate for doubling. But it would require some changes to Web Application login process, and has some unique disadvantages.
Traditionally, in a web application, a TLS session is started which secures the transmission of a login username and password. Under Whisp, the 100% secured TLS session would only be able to start after the user enters the password. The usual DH or RSA process is used to generate a symmetric key for the session, but then that key is processed further using the hash of the users’ password (likely with a hashing algorithm). Only if the user enters the correct password, will the secure tunnel be active and communication continue. There are still draw backs to this approach however.
The initial password still needs to be communicated to the server upon registration. So this would work well for all established user accounts, but creation of new user accounts would require additional protections (perhaps PQC doubling) when communicating a new password.
I would favor the former suggestion of PQC doubling, but there may well be good reasons to also use Whisp. And it shouldn’t be long before PQC can be relied upon on its own.