dadrian

Raise rates.

I'll admit hostile was perhaps too harsh, however looking back to the late 2010s, it seems clear that the attitude was:

- C ABI is good enough for any compatibility

- "Rewrite it Rust" / RESF

- Prioritize language proposals, not fundamentals

I think the attitude as changed somewhat in the last 2-3 years, with more interest in cxx and crubit and crabi, although many of those things are at least partially blocked on stalled language proposals, and largely ignored by the "core" Rust community. I would say indifference and posturing does approach hostility.

There's also consistent conflation of "compatibility with C++" and "rich compatibility with all of C++". Swift is a great example of how targeting PODs and std::vector and aligning concurrency expectations gets you extremely far, especially if you limit yourself to just LLVM.

btw, I really appreciate your Rust book.

This is the exact attitude I am referring to. Also, Rust already uses LLVM.

Rust had to be dragged kicking and screaming into integration with other languages, and its C++ compatibility is a joke compared to Swift.

It's absolutely true that you need integration and compatibility to enable iterative improvements, but Rust historically has been hostile to anything besides unsafe C ABI FFI, which is not suitable for the vast majority of incremental development that needs to happen.

Luckily, this is starting to change.

Nah, it's like how the existence of Star Trek influences future development of technology. Did Mickens call it, or did the Mossad get the idea from Mickens?

Of course D&D is not an accurate picture of the medieval era. There's magic in D&D! There was not magic in the medieval era. What are we even doing here?

It's unclear that NSO group is interested in gaining access to iCloud accounts or Photos, nor is it clear that this entrypoint is something that would meet the bar or be useful for signals intelligence, since it requires sending a calendar invite and clicking on the attachment.

Bug bounties will pay for any bug. Offensive firms only pay for things that are practical, and they don't pay everything up front---it depends on the lifetime of the exploit. The business model is closer to a subscription or services.

There is no reason to believe NSO group would pay more, and they certainly wouldn't pay quicker.

I agree that simpler is better than more complex, but you're not saying what is wrong with the current approach. I gather you're upset about certificates (who isn't annoyed with X509?), but ultimately all you're saying is "I wish Serve and Dial were more secure, but without using the mechanism that specifically exists to make them secure." This is just one big No True Scotsman.

I'm confused as to why you think you can replace all the things in TLS that provide security with some sort of magical SecureConn function. TLS is the secure connection, so much so that your code example is exactly what happens in Golang when you use the TLS library. net.TLS provides a Dial() and a net.Conn implementation.

Your argument seems to be "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." This is a fundamentally unserious argument, unless you can say what is wrong and what the requirements for a new solution are that are not provided by TLS currently.

What do you think secure by default means?

Do not attempt to compete with SCWpod.

DJB and Tanya operate as a unit. Saying Lange agrees with DJB is like citing Clark as support of Lewis.

Of the SCW hosts, I'm actually the NSA plant. You got me.

And if there's one thing the cryptocurrency brand of cryptographers can do, it's come up with new ways to take out loans!

Hybrid kyber is actually enabled by default in Chrome on desktop, you don't need to go to chrome://flags to enable it.

They're not mutually authenticating, they're origin-bound (making them non-forwardable on the remote side) and channel-bound (meaning the authenticating action is guaranteed to be for the same device as the user action).

However, there's no particular reason a FIDO key couldn't sign a login statement to a phishing site---it's just that statement wouldn't then be usable as a valid credential for the true site, regardless of if the signature from the FIDO key was valid or not.

They are harder to implement than ECC.

It's not clear to me that this is something that should be genericized, nor that providing a generic HPKE to IETF WGs and then tweaking it as needed is any less work than just composing the correct primitives for each WG use case. As it stands already, IETF WGs are relying on properties that, e.g. DH-KEM only provided by accident. In practice, HPKE is not something you can just use off the shelf, and I personally wouldn't try to write an IRTF standard like it is.

Bottom of https://tldr.fail

I don't see TLS adopting anything other than the current hybrid or a pure Kyber, but Bas would know better than me.

Signatures are very difficult to do hybrid in a way that's not strippable.

I think lattices are in the realm of boring crypto these days, but I ask the actual mathematical cryptographers when I need real opinions.

Unlikely that signatures will ever be hybrid.

Fairly likely we move off of hybrid for key exchange once NIST finishes standardization.

It's a joke, because it's about migrating off of pre-quantum asymmetric cryptography.

> I don’t know why OP brought in MTU and packet sizes since that doesn’t really apply here.

It does apply. TCP exposes streams as the API, but the underlying data is still sliced into packets of size up to the MTU.

There's a difference between FIPS approved algorithms, which are actually pretty broad and well-selected these days, and FIPS validated implementations, which are at best a PITA and often actively harmful. Very rarely do you actually need a FIPS-validated implementation.

LDAP is a UofM innovation. Tim Howes, a Peter Honeyman student, wrote his dissertation about it, and then went on to found Loudcloud with Ben Horowitz.

UofM popularized the use of Kerberos in academic settings. IIRC, Dug Song added support for Kerberos to SSH, and some other people in Honeyman's group (CITI) connected Kerberos to Andrew File System (AFS). But we'd have to ask honey to know for sure.

Massive failure by Silicon Valley to have given us Juicero, but failed to have invented the battlecow.

It doesn't matter if the JIT itself is written in a memory-safe language or not if you're exploiting miscompiled JIT output. If the machine code emitted by a JIT is wrong, it can be exploited regardless of if the JIT itself is memory safe or not.

> There is no technological reason this is the case, but pure greed by publishers.

Ah yes, because server-side infrastructure is notoriously free and cheap to run, with no ongoing operational costs, and requires no employees to maintain.

All this article says is that Haidt's analysis is just correlation, and then cites a single metastudy from 2019, and doesn't go on to explain what Haidt did wrong. This is despite extensive writing from Haidt that deconstructs that specific metastudy.