rot256

Package management in Go always felt pretty hacky. Among the issues is the confusion between "what something is" and "where something is". At the beginning there wasn't even a way to have different versions of a package, with the justification that you should just fix an interface and keep it stable till the end of time, there was also no way to "lock dependencies" so at build time you got whatever that repo served you. It has gotten better since, but still some jankyness as a result of "growing" a package system.

Don't buy the argument, this stuff is simple enough that we can formally verify and audit it very carefully.

Additionally, NIST had the foresight to derandomize all the algorithms, so we can now check e.g. what a correct implementation will produce on particular seeds. This is a big deal because a bunch of e.g. ECDSA bugs, such as biased nonces or reused nonces, are trivally caught by such tests/derandomization.

TLDR: the bugs are going to be elsewhere.

ML-KEM encaps/decaps is very fast, as fast/faster than EC. It's large, and adding EC does not meaningfully affect the size, but it meanfully affects encaps/decaps time.

I write a lot of Rust and Lean, Fable 5 is in my experience better at both. Cost/performance is a different story.

Spotify is, without doubt, the worst piece of software that I still use on a daily basis. It's incredibly buggy, incredibly slow, and the UI has so many "usability inconsistencies".

I find the Android app particularly bad, just a couple of examples:

- Under a playlist you get a list of suggested songs, the UI element looks like a "regular song", but unlike every other "song" element the user has been trained to recognize, the "swipe right to queue" does not apply to these elements. For some reason.

- When you don't have connectivity, e.g. you walk into a Faraday cage, then the search tries to reach the internet and won't show you results before it either: 1) does so, 2) times out. Which means you can't browse your local library before some websocket times out. Just show me the local results first?

For LetsEncrypt, routing is authentication: if packets routed to the IP in the A record end up at your place, you can get a cert for that domain.

I think that way to solve BGPs security problems might be to use a new cryptographic hammer, "Proof-Carraying Data", where messages come with cryptographic proofs that they were produced correctly. This allows you to basically just run BGP, but every AS proves that it ran it correctly. The proofs take constant time to verify, regardless of how large the network is, or how many hops the routing message has taken. Feasibility is helped by latency not being super critical in BGP and BGP being a pretty simple protocol; which makes computing these proofs plausible.

https://rot256.dev/post/bgp-pcd/

Proof-carrying data has come a long way in the last 10 years.

EDIT: you would still need RPKI, but not BGPSec

This seems useless and misguided? This training material contents is clearly AI generated, if people can't be assed to write a book, then why should people read it?

Maybe it's my teaching background, but there is something uniquely soulless about teaching humans with AI slop passed off as a course; this is the stuff of "Amazon AI generated book spammers" and to be honest, I expected better from Microsoft.

If people wanted LLM output, they can generate it themselves...

PipePipe? https://pipepipe.dev/

EDIT: also skips sponsor segments.

As pointed out by Mark Galeotti, both the sources are less than reliable...

https://podcasts.apple.com/gb/podcast/in-moscows-shadows-120...

Whether dead or not, it is frankly disappointing that western media lends so much credence to sources which have been consistently wrong and made outright ridiculous claims before. Even if they try hedging it by calling them rumors, until more reliable sources emerge it is just noise...