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.
Round 1 submissions were received by November 2017:
Back in 2014 I got the recommendation to ditch 2048 in favor of 4096.
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
Mods, maybe add a "2015" to the title?
Source: I'm an author.
DNS resolves to 126.96.36.199 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...?
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.
Is there any problem with the crypto that gpg uses, or is it just a matter of the UX?
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 email also leak some more metadata than signal does. But it leaks to different parties, so this is not clear-cut.
If so, what are the reasons? Just enhanced usability, since I recall libsodium using the NaCl crypto primitives almost directly as-is?
> It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further.
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)