Not a legitimate complain at all--the jury is still out as to whether it will ever be possible to create a quantum computer capable of breaking current asymmetric primitives.
I'm assuming you're referring to the physical difficulties of creating such a device, since the theory has been there for a while now.[1]
I don't know why you're saying this isn't a "legitimate complaint" (or what even gives you the legitimacy to criticize such things), if anything this is just as, if not more legitimate than your comment.
Time and time again people thought we didn't need to worry about bigger registers/more memory/int overflow/screen sizes/etc. and they were proven wrong every time. Given everything we know so far and everything we've achieved in this field, I'd bet my money on the fact that we will have such capable devices in the future.
Actually wasn’t the latest gov standard pushing for quantum-resistant algos? I vaguely remember some controversy over it on HN, because the switched recommendation was sudden and came out of nowhere (with at least one suggestion that they must be nearing it, or someone else is). Dont follow this topic normally, which is why I’m so vague on this, and possibly wrong.
I'm confused... Wasn't all that published in 2015 already?
Edit: ah it says it right there on this article: The full version of this paper was published in Proceedings
of the 22nd Conference on Computer and Communications
Security (CCS), October 2015, ACM
I'm also receiving a locahost redirect over Verizon Wireless in the US when using Chrome for iOS.
DNS resolves to 80.82.77.83 and .84. When I surf directly to that IP I am redirected to https://sci-hub.se which seems to load correctly. That implies this is the correct server and not a MITM.
When using CloudFlare's DNS VPN I get the same IPs, so this is not a VZW injected IP.
It seems the Sci Hub site itself is doing the local host redirect...?
You should have learned this paper last semester, as the paper is from 2015 and is relevant if you study DH.
Anyway, for an application developer (as opposed to a crypto engineer), just use libsodium when you control both sides.
If you need to interop with someone else, use TLS 1.3 if you can, or TLS 1.2 but only with ciphers that support PFS and AEAD, i.e. in practice x25519 and P-256 ECDHE with RSA signatures with AES GCM or ChaCha20Poly1305.
Same primitives are available in SSH.
If you can, don't use IPSec, use wireguard.
Don't use pgp/openpgp/gpg email, use signal. You can use gpg to sign packages and encrypt backups, but the email integration and UX will kill you.
You can configure it to use crypto that is ok (and then use it to sign software packages or encrypt backups, like I wrote above, especially when interaction with gpg is done by scripts, not manually by humans, and key distribution is out of band and PFS is not needed).
For back and forth messages between two or more people, lack of forward secrecy is a problem, integration with the email program is a problem, email metadata is a problem (not just to and from but also the subject line), teaching your confederates to not reply in the clear quoting the entire decrypted message you sent is a problem, etc.
Security practitioners basically believe email cannot be saved, it cannot be used securely by regular people and its only use is to bootstrap something else.
Subject is hidden in newer software e.g. Enigmail and K9 (it's moved to encrypted part and replaced with a placeholder see https://github.com/autocrypt/memoryhole).
Gpg can use a lot of different crypto primitives. Some do have problems, some are kinda broken but still good enough for use, some are too easy to make mistakes so gpg is probably bugged, and some are top of the line.
Gpg email also leak some more metadata than signal does. But it leaks to different parties, so this is not clear-cut.
> It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further.
> Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS, Android, as well as Javascript and Webassembly.
Look at the release notes on the releases page to see what kind of things they do.
This is built into modern browsers so you can use that as the basis for HMAC if you can't trust TLS or have something like an open URL for a lambda function that in theory should only be hit by someone's webhook (ie. Slack)
