The case of the 9 bit AES key

Per the manpage you linked, openbsd's behavior does not match the drand48() interface, since the drand48() interface requires determinism.

I'm interested in that rant (at $WORK we adopted hash() for almost everything, and I'm curious to hear other perspectives).

Certification do exist for engineers, and various industries and governments impose their own certification programs on platforms and software before they’re authorised for use.

Each with varying degrees of trust. The outcome is never perfect, but that’s not their purpose.

What's your method for implementing rigorous testing while using AI?

University degrees are not the difference between an engineer and a developer, universities have churned out millions of people who don't care about programming and have no idea what they're doing, who are just following the script with as little effort as possible because they were told it was the easiest way to make a lot of money.

You can get through a Computer Science degree with just a few thousand lines of code if you focus on theory courses.

a small wonder the wunderkinds of computer science were at all capable given their lack of computer science degrees

one and the same

Be careful to use the cryptographic one, not rand(3)

And if you're a sysadmin, be extremely careful when generating keys in VMs or embedded devices. They tend to overestimate their entropy sources - it's possible that every clone of a VM generates the same keys. In some cases (cough ECDSA) generating the same key and nonce to sign two different messages is catastrophic - it immediately leaks the private key.

btw, the idea that the system rng isnt good enough, or "runs out" or whatever, is no longer true on pretty much every modern, widely used os.

btw... im sure there's some legacy rng in windows or some shit that isnt good. read the docs but if it's the blessed system rng, you're probably fine!

although... i suppose if this is news to you (the person reading this), then you probably shouldn't be implementing whatever you are that really requires prng. ask a friend for help. im not trying to be a jerk, i just want to make sure you dont hurt yourself!

Rule 3c: At least as many bits. Bits tend to not be as random as you think they are

How many people judge their tools based on the AES key entropy?

just down vote it.

You can downvote anything not interesting.

If he have list some alternative or give example, it might be interesting.

PDF.js, for example. It's what Firefox uses, and most websites with integrated on-page PDF viewing functionality.

File formats are the buffer issue honeypot. You may be aware of how often video and audio codecs have vulnerabilities - it's nearly never the hand-tuned frame decode assembly (where you would think all the mistakes would be). It's nearly always the thing that reads the metadata and encoded frames to memory. Binary formats have things like offsets in them, and those can be trivially used to overrun.

Same thing applies here. Even Rust has a crate for dealing with binary data, despite its memory promises: https://crates.io/crates/untrusted

It's a fucking minefield, and this is one area where the Rust zealots are undeniably correct. It doesn't have to be Rust, any memory safe language will do, but Rust also happens to be performance competitive and that's usually also desirable.

I think the claim is hyperbolic, since most people memory-unsafe PDF implementations, but PDF is a monster format, a metaformat that brings in virtually every conceivable display format, and their renderer implementations with them, often poorly-maintained, never-touched reference implementations from the before times. PDF is pretty scary.

PDFs are usually untrusted input and C provides no assurance there isn't a bug in the code that allows corrupted input to turn into arbitrary remote code execution.

buffer overflow vulnerability in code dealing with user generated data and a complex file format.