beefhash

Note that the spec[1] requires that this tops at an implementation-defined size of integers, so you're likely not getting out of writing bignum code yourself (and even fifimplemented, the bignum operations may likely be variable-time and thus unsuitable for any kind of cryptography). Making the size completely implementation-defined also sounds like it'll be unreliable in practice, I feel like making it at least match the bit size of int would be a worthwhile trade-off between predictability for the programmer aiming for portability and simplicity of implementation.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf

Windows doesn't ship it, so now your build system got even more complicated on Windows.

That's partially on the community for making so much free (as in beer, often also as in freedom) software. The expectation is now there. Though how to reverse it remains an unsolved problem.

C has a proposal for #embed.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2499.pdf

wchar_t can be (a) not Unicode in any way, or (b) 16-bit, insufficient to represent a rune.

And every BSD out there. And whatever it is that macOS does. Microsoft looks to be the outlier to me.

Wait, doesn't this mean that the BSD sockets API is inherently dependent on UB, casing different socket types to each other and sometimes only using the first few members, or am I misunderstanding you?

C has been making strides towards complete Unicode support. I've been having trouble following along though: Am I correct in assuming that there's no actual multi-byte UTF-8 to UTF-32 Rune function and the best approximation depends on whatever wchar_t is? How would I best handle pure Unicode input and output scenarios on a "hostile" OS whose native character encoding is some EBCDIC abomination or a Windows codepage?

(Not one of the OPs:) Wasn't C11 Annex K, the notoriously failed bounds-checking interfaces, a example of not having an existing implementation?

Now that C2x plans to make two's complement the only sign representation, is there any reason why signed overflow has to continue being undefined behavior?

On a slightly more personal note: What are some undefined behaviors that you would like to turn into defined behavior, but can't change for whatever reasons that be?

What even is this timeline anymore.

Though I don't see this recapturing the casual reverse engineering market that Ghidra ate for lunch unless they have very compelling IDA Home pricing for the decompilers as well (the “One processor family of choice from the most common processors: PC, ARM, M68K, MIPS, PPC” statement is kind of vague about that).

It's a simplified description of EdDSA (and as much is said in the article), taking out the deterministic part for a random nonce, effectively presenting key-prefixed Schnorr signatures instead.

> I'm not sure why TweetNaCl is even considered a serious crypto library.

Probably because its authors are all big-name people and their paper says:

> We have placed TweetNaCl into the public domain, and we encourage applications to make use of it.

Maybe we should gatekeep it so much though. As long as there exist at least two people capable of implementation per programming language (one to implement, another to audit), there will only ever be one, single, canonical implementation and there's no way around it. It is not and should not be an inherent right to be allowed to implement cryptography (that is put into production or made publicly available). The gatekeeping is there for a reason and it's important that we uphold it. Fewer implementations means that more people will be focused on having to write and check less code overall. Patents could be used to help with this by only permitting one upstream implementation to exist, but that's now how they end up being used in practice, and that's ignoring the fact that patent expiry is impractically short (compared to copyright expiry especially so).

From what I can tell, they were trying to get it adopted as RFC, but then a couple more things popped up on the CFRG, so they're planning a new version[1]. It's been adopted by the CFRG officially[2]. I haven't seen any sign of when the next version may be out (which will be draft-irtf-cfrg-ristretto-00[3]), however.

I kind of hope they'll also add ristretto448 since RFC 7748 and 8032 include X448/Ed448, so that the draft has feature parity (and covers the h = 4 case properly).

[1] https://mailarchive.ietf.org/arch/msg/cfrg/3RRpX9hME5ErtAzCo...

[2] https://mailarchive.ietf.org/arch/msg/cfrg/wd8pprUfJoNhvEQE0...

[3] https://mailarchive.ietf.org/arch/msg/cfrg/pT2ML68BapPAcUiSk...

> efficient complete formulas for Weierstrass curves were found only after Curve25519 was well established

Assuming you are talking about the Renes–Costello–Batina formulas, they're complete, but not necessarily efficient. According to [1], optimized short Weierstrass with the complete formulas is still 1.5 to 3 times slower than Curve25519. I imagine the numbers won't be much better for Edwards25519, either. There's definitely a ton of potential for a better complete addition formula on Weierstrass still left.

> Ristretto is nice but so terribly complex

Ristretto is nice, terribly complex, and you don't actually need to care about the conceptual complexity. As an implementer, your only job is to execute the explicit formulas in section 5 of the Ristretto website. You do not have to be able to follow the hard math (just how you do not have to be able to follow the hard math involved in making the explicit formulas). Plus the entire thing can be trivially constant-time given a constant-time selection primitive and constant-time field arithmetic. It's not that much more difficult than doing regular point compression on your own.

[1] Peter Schwabe, Daan Sprenkels. The complete cost of cofactor h=1 (published in INDOCRYPT19), https://eprint.iacr.org/2019/1166.pdf

To be fair, "the web" means "what Chrome does" nowadays to a lot of people. Even if it wasn't Firefox's fault but rather some web standard that Firefox adhered to, Firefox will be blamed for not being bug-for-bug compatible with Chrome.

ISO tends to be aggressive about their intellectual property, and given the prices of the standards, few people bother re-writing them to avoid their copyright. They have a lot of somewhat obscure standards that are highly priced, such as ISO/IEC 29192-x lightweight cryptography standards (each being ~60 bucks a pop).

And I guess it was probably cheaper for Google to just buy the TLD and not fix their internal processes?

I feel like I should add a bit that pledge(2) and unveil(2) take the "opposite" approach of SELinux. Instead of caging an application in hopes that the cage is correctly set up, the responsibility for pledge(2) and unveil(2) is intended to be with the application developer, who minimizes system calls as much as possible and only keeps paths unveiled that they actually require. As far as I know, the idea here is that the developer knows best.

People seem to have been experimenting with applying these restrictions from the outside, but it's generally hard to guess how a large program from ports will behave.

Then you'd just repeat the Perl 5/Raku split. You'd have a "new" C++ that isn't actually C++ but it's called C++ with a different version number and people will then bicker for a few years until they realize that the "new" C++ isn't actually C++ and that the "old" C++ just vehemently refuses to die, so they name it something else.

The C++ standards committee can standardize a backwards-incompatible "new" C++ for all I care as long as they don't call it C++.

From a practical standpoint, I agree (I've started abusing getentropy(2) as a more portable replacement), but it violates the use case though: getentropy(2) is only intended to seed userspace RNGs. Breaking the usage scenario means breaking the API contract.

No, it wouldn't, but they've made abundantly clear they're not interested in doing anything reasonable the BSDs propose.

On that note, would it kill the OpenBSD guys to get on the getrandom(2) train? I get it, they're dying on the “arc4random is better” hill (and, yes, I agree), but they're literally the last people in the way of making getrandom(2) the new default across not only the usual BSDs and illumos, but also glibc/Linux.

The job market has been very hard on everyone lately. And looking at current event, I don't think that's going to improve in the foreseeable future.

Whatever it is, I hope the answer involves “implement kevent(2) instead of creating epoll(2)”.

> And I don't think env's file path is even in POSIX, it's just a de facto standard.

You would be correct about that. And that sucks.

> Find me one system in current use (2020) that isn't 2's complement.

Fortunately, C2x will stop with the meme assumption that two's complement hasn't taken over the world (see draft N2479). It will not, however, specify signed integer overflow, which remains UB. :^)

> and decided to release it for the benefit of the community

I don't understand. You're saying “for the benefit of the community”, but then only speak about companies as negative examples. (1) Are companies inherently incapable of being members of the community to you? (2) Are people whose software is more liberally licensed (and may wish to incorporate parts of yours) not part of the community to you?

4.4BSD-Lite2 is the earliest they could do without risking some legal issues[1].

[1] https://virtuallyfun.com/wordpress/2018/11/26/why-bsd-os-is-...