Currently being investigated by browser makers but not something they can just do on their own like Signal.
Here's Chromium's current proposal that they're testing:
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
A loosely moderated place to ask open-ended questions
Search asklemmy ๐
If your post meets the following criteria, it's welcome here!
Looking for support?
Looking for a community?
~Icon~ ~by~ ~@Double_[email protected]~
Currently being investigated by browser makers but not something they can just do on their own like Signal.
Here's Chromium's current proposal that they're testing:
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
This is really interesting, thanks
Do you know if Firefox and/or Safari have indicated if they'll be supporting this scheme too?
Firefox definitely will once a standard is available
thank you for this article
There are solutions currently in development, but as far as adoption goes, most sites won't use them until there is a real need.
Looking back 10 years ago, even HTTPS didn't have widespread adoption like it does now.
Hmmm real need.... we need it now, lots of traffic is being harvested now for cracking later.
Oh I fully agree. However, the people that control the purse strings in business will not take IT security seriously until something bad enough happens that it either makes the news or affects them directly.
True. I just think of the hubble program and how what we learned was that there were already a bunch of them pointing at earth. I think quantum computing will be the same. 127 qubit machines are now publicly available... so what's available to the cia?
Idk if that will ever hit the bank accounts that matter
Using a symmetric pre-shared key based VPN can help mitigate this issue. While the actual HTTPS data will still use non-PQR cryptography, Wireguard's XChaCha20 and OpenVPN's AES-256-CBC are considered safe against quantum computers since they don't use asymmetric cryptography.
Of course, you still need to trust the VPN provider.
Awesome! Thats good info, thanks!
โLotsโ
Citation needed
[This comment has been deleted by an automated system]
Who has an interest in cracking your https traffic to say, lemmy? If it's a nationstate, they already have access to root private key certs and that attack angle will not be mitigated with "quantum" encryption. If it's Capitalism, i.e. google-ads or whatever, then it's a marginal utility issue. If they harvested some of your https traffic from 20 years ago, it's pretty worthless as far as metadata for ad-targeting etc goes. I don't really see what "quantum encryption" would gain you.
True it's definitely tinfoil hat territory
I'm a nobody, and I don't expect there's anyone who wants to access my encrypted traffic, but someone out there is important enough to the right people that would love to get access to that kind of stuff.
Wouldn't HTTPS automatically support it once TLS does?
It depends if the new encryption methods are compatible with the key exchange mechanism.
Considering this proposal is used for the key exchange, they definitely need to update both the client side and server side part to be able to make use of it. That's the kind of thing that may take years but luckily it can fall back to older methods.
It also needs to be thoroughly vetted so that's why it's a hybrid approach. If the quantum resistant algorithm turns out to have problems (like some others have), they're still protected by the traditional part like they would have been, with no leaking of all the data.
Luckily the majority of websites and Internet traffic go to the three cloud companies
So how does it work? I guess they exchange keys both ways and then hash them together?
Honestly lattice encryption has been vetted for three decades now. We still can't say for sure P is not NP, but I'm far more worried about someone getting a quantum computer early than a sudden breakthrough on breaking either kind of algorithm.
Looks like it just concatenates them:
The shared secret is calculated as the concatenation of the X25519 shared secret (32 bytes) and the Kyber768Draft00 shared secret (32 bytes). The resulting shared secret value is 64 bytes in length.
https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html>
Huh. I guess whatever algorithm comes next is resistant to half of the secret being compromised, then.
Edit: It looks like they concatenate things from the two algorithms a few times in the process, so maybe they figure it would be difficult to isolate a vulnerability assuming either one is strong.
Key exchange works pretty much the same way as with prime/DLP-based algorithms. It's just different math (and more data!) being used.
Source: Math background, I know how the magic works. At least in theory.
Yeah, I feel like it's going to take both browser vendors shaming sites once a standard is developed/finalized and something like a quantum version of whynohttps.com to drive adoption.
The problem really is the store and decrypt nature of it. It could be used against old data so the time when it needs to be implemented is before it becomes possible to decrypt. I feel like people aren't good about planning like that and tend to be more reacting to what is currently possible.