HN user
I sort of wonder if there's going to be a barrage of exploits held until end-of-life that's going to be released now.
EDIT: I'm already aware that the system has been exploited to death and back, so I'm mostly curious if people haven't already dumped everything.
Why use C11 over C99?
C11 gives you noreturn and alignas. Alignas can be pretty useful for low-level development in particular. Just hope you don't need variable-length arrays because those got changed to optional.
Or even why use C99 over C89?
Several very big things: Native bool, stdint.h (fixed-width int types with known sizes ahead of time), long long, snprintf, not having to declare all variables at the top of the block (and now you can do for (size_t i = 0; i < sizeof(strbuf); ++i) because of it).
Open always wins, but that doesn't necessarily mean that it'll be qualitatively better, which is what your parent comment seems to hint at.
age only covers authenticated encryption. minisign/signify covers the signing part.
Everything else is either not used in practice or needs to be shifted to a dedicated protocol.
Here's the fix to e-mail: Centralization.
You can't curb abuse in a federated model. This is an issue that's been plaguing the fediverse as well. IRC networks, though not federated, have had to each individually ban spammers and other problematic users.
Google (GMail), Yahoo, Microsoft (Live/Hotmail), Yandex, QQ Mail. That ought to be enough for everyone. EDIT: and mail.ru
Upstream moving faster than downstream Linux distributions can possibly keep up with.
Indeed, C11 and C18 don't bring a lot. I'm glad that they don't because backwards compatibility and roughly predictable development of the language is important to me.
You also have the long, complex and constantly changing list of rules which need to be applied for each update. They are very strict about noting down the copyright of all the files, for example (which I can understand to some extent).
Tracking licensing information very strictly makes sense.
Other than that, however, the Debian packaging process is something only a lawyer could love.
Wiimmfi is closed source software, however. If you actually want to look at how the internals worked, the independent altwfc project[1] may be much more interesting.
[1] https://github.com/barronwaffles/dwc_network_server_emulator...
Nitpick: The name of the Swiss entity appears to be “RISC-V International Association”, notably an association, not a foundation.
So now that Perl 7 wants to actively remove backwards compatibility from its culture, where are people to turn now for stable/non-moving scripting languages?
Out of curiosity:
1. Why ECDSA?
2. Why a 512-bit prime for the curve?
Oh. I see what's going on, and I was wrong about this.
US7949129B2 expired because he didn't pay the patent fees. US8321675B2 claims priority to a patent from 2001. Claiming priority is a way to broaden an existing patent by saying “it's this, but improved”; however, this also means inheriting the expiry date of the patent claiming priority to. So yeah, that one's expiring next year already. Holy cow, thanks for making me check.
Another, related patent that he notes in the FAQ[1] is 8,107,620, which won't expire until 2029 unless IBM forgets to pay patent fees. Hard to tell if it really applies to OCB3 though.
[1] https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:p...
At least it's only 12 more years until the patents on OCB3 expire. We're almost at the halfway point.
Given there's been a recent trend about ransomware not only encrypting, but also exfiltrating data, backups won't save you from the bad PR of the leak.
At least PhDs in cryptography establish some amount of a baseline in that regard.
For some reason (probably due to QEMU), these kinds of bootloader tutorials are still stuck in the BIOS era. UEFI remains completely under-taught, which is probably in part because it's hideously complex.
Note that modern computers are supposed to be dropping BIOS boot support this year[1].
[1] https://arstechnica.com/gadgets/2017/11/intel-to-kill-off-th...
Legal types don't like the Unlicense either as far as I can tell[1].
You'll find software that is dual licensed CC-0 and something else, too,[2,3] because anything public-domain-ish with no attribution may be perceived as too risky.
[1] https://softwareengineering.stackexchange.com/a/147120
[2] https://github.com/BLAKE3-team/BLAKE3/blob/master/LICENSE
[3] https://github.com/LoupVaillant/Monocypher/blob/master/LICEN...
* and don't have anything on your track record making it impossible to land this kind of job due to the security clearance required
"Just Libsodium" doesn't work on anything smaller than a Raspberry-Pi, or pretty much any embedded system out there. There are alternatives out there
And the same author provides a solution for those systems as well with libhydrogen.
Though that doesn't look so super hot anymore given the recent advances on Gimli[1,2,3], but it'll likely still hold up in practice.
but sometimes your only choice is to code and optimise it yourself
That is a critical shortcoming of the ecosystem. If you reach that point, you should be hiring a cryptographer/experienced implementer. Your follow-up question might be “Where do the cryptographers come from, then?” and the answer to that is: “PhD programs at universities, ideally”. Curiously, however, many (most?) cryptography libraries that are used in practice appear to be written by people with barely any academic background. We should be working to rectify that one way or another (send the implementers to university or pull more people from theory into implementation practice).
you don't need to know all the attacks to protect yourself from them. What you need to know is the relevant classes of attacks, and how to void them
Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet?
And that's before you get to protocol design, where there are new, mysterious ways to shoot yourself in the foot (use TLS, use TLS, use Noise).
[1] https://eprint.iacr.org/2020/561.pdf
[2] https://eprint.iacr.org/2020/591.pdf
[3] https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slid...
How long until the patents expire?
If you want a to get this stuff into your head reasonably fast, go implement a curve. Then do it again, but in Rust (or C) and in constant-time. Then do it again, but actually computationally efficiently (i.e. optimize the hell out of a Rust or C implementation once it works). Choose a different curve each time. Then go and cook your own curve for shits and giggles.
You may easily spend a year upwards on this, but by the time you're done, you've basically run into every resource worth knowing about and are able to decently reason about elliptic curves (but by no means are in a position to write papers still).
I didn't know about possible patents, that sucks. (I live in the EU, though, so I can still give them the finger if I need to.)
Hamburg made this IP risk pretty clear in the paper, for a bit more context on it, see [1]. Because in the U.S. you have a full year before you even need to file a patent after publishing, we'll still have to wait and see if Hamburg's employer files a patent on his method. If they don't, nice; if they do, fucking hell this is why we can't have nice things. Renes/Costello/Batina is unencumbered as far as I know.
[1] https://www.reddit.com/r/crypto/comments/g46pft/_/fnwp9p2/?c...
we now have better ways of dealing with short Weierstraß curves
We do? The complete Renes/Costello/Batina formulas for point addition are significantly slower at a factor of 1.4.[1] The complete formulas presented by Hamburg are still somewhat slower than what you can get on twisted Edwards and almost certain to be patent encumbered by the end of the year.[2] Did I miss something?
SafeCurves discounts Renes/Costello/Batina and the like because “many of these formulas are considerably slower and more complicated than standard incomplete scalar-multiplication formulas, creating major conflicts between simplicity, efficiency, and security”.[3]
[1] https://cryptojedi.org/papers/complete1-20191011.pdf
Kind of hard when the operating system does it for you... https://groups.google.com/d/msg/comp.unix.aix/0dv4N0qmgVQ/ty...
The standard digest is 64-bits, but you can modify it to take 128-bits if you want a cryptographically secure hash.
There's not even an attempt at a preliminary cryptanalysis anywhere as far as I can tell. I'd advise staying far away from this for cryptography, especially if it considers a 128-bit digest size reasonable for anything but a message authentication code.
Can't really argue with the makers of proprietary microcontrollers about what tooling they provide though.
Tink addresses things libsodium doesn't really do.
Native support for AWS Key Management System and its equivalent on other cloud platforms is a huge win; we should all be using more of these. But libsodium would have to start mandating a TLS library and an HTTP library and whatnot, interfering with people's existing setups; you can't really do that without C programmers getting angry at you.
It deals with not only key generation, but also key serialization. libsodium kind of strands you when it comes to the question how to actually store keys.
Deterministic nonces have also been something that libsodium appears to have rejected: https://github.com/jedisct1/libsodium/issues/392
If you're looking at it from a misuse-prevention perspective, Tink is probably a major step up that accounts for modern use cases. libsodium's kind of in a lower level niche and suffers from being held back by C and its notoriously anemic standard library.
Everybody hates ads until it comes to their own bottom line, I guess. Exceptions apply, of course.
(2017)