Black-and-white thinking like this is always inaccurate.
>untested
The automated tests includes tests that make sure the XOF is correctly implemented. [1]
>unlooked at
People have been looking at my code for security holes for well over 20 years, and I have been getting multiple AI assisted security reports over the last year, things like “there’s a buffer overflow in this code which is nay to impossible to exploit, using code which hasn’t even been able to compile since 2022”.
XOF correctly implemented doesn’t ensure you haven’t made other mistakes, such as using entropy sources correctly, doing needed math correctly to avoid any entropy bias, etc. etc….
You’re correct about black and white thinking. Then you invoke multiple straw men in this thread to defend that you’ll roll your own.
Disclaimer: I’ve been hired for multiple DoD projects to break hardware and software security systems, and I nearly always succeed, because so many people (and companies) roll their own.
The nice thing about a secure XOF is that it doesn’t matter if the entropy given to the XOF is less than perfect. If an XOF is given 10 different sources of entropy, and only one of them is secure, the XOF will remain secure. [1]
One reason why I don’t change the RNGs used in my code is because I know how dangerous playing with RNG code is. For example, one implemention I wrote of the XOF—not one I used in production code, mind you—generated incorrect vectors, but only in clang and only at some levels of optimization. Needless to say, I now have a test to make sure my XOF code generates correct vectors with both GCC and clang at multiple different optimization levels.
People have brought up CVE-2008-0166 in this thread, but the Coldcard incident from this year (where people literally lost millions of dollars) also comes to mind, so I’m aware how dangerous playing with RNG code is.
That’s why the code is basically the same code I had 18 years ago, and why I (as well as multiple people running AI-assisted security audits) have extensively tested that code.
The proof is in the pudding: No security issues have ever been found with the XOF PRNG, and it’s been nearly two decades.
(I also think “straw men” is being used incorrectly here; most likely the parent poster thinks I was implying that Linux’s /dev/urandom is insecure but the actual argument is that my code runs on a lot more than just Linux, and some of those systems could have an insecure /dev/urandom)
[1] As per https://blog.cr.yp.to/20140205-entropy.html as long as we’re not using a malicious source of entropy, but said malicious source will need to perform 2^n operations of the XOF to generate n bits of controlled output, and only in the case if said malicious entropy source can somehow know the output of the other entropy sources, especially since the XOF is seeded once then run indefinitely in my code.
> The nice thing about a secure XOF is that it doesn’t matter if the entropy given to the XOF is less than perfect. If an XOF is given 10 different sources of entropy, and only one of them is secure, the XOF will remain secure
Secure is not a binary state; not understanding basic information theory and how entropy evolves is fatal.
This right here shows 100% why no one should trust you or your code. You have a seriously fundamental misunderstanding of entropy or what the Bernstein blog post (and it is a blog post, even if it’s Bernstein) states.
His post states, correctly, that a hash is as secure as its weakest entropy source. Adding more bad ones does not strengthen it. He doesn’t say you can ignore the entropy per source, and simply hope one “is secure,” whatever the heck that even means.
Entropy of a source is a number, often in units of bits/sec (or nats or Harley’s or some rate for differential entropy). It’s most definitely doesn’t even make sense to say “one is secure”. That’s a nonsensical phrase.
If you do not correctly know the entropy bit rate of all your inputs, and very importantly cross correlations, you cannot know if you have enough entropy accumulated for an operation, which is then used up; you cannot make downstream claims about security. That you’re so incredibly lax and naive and state the opposite of reality shows the lack of crypto skill. This type of misunderstanding is why there’s still groups hiring people like me to break systems: tons are implemented very poorly, leave holes from poor entropy, timing attacks, power attacks, glitch attacks, etc. depending on the system.
The very least anyone designing such things should know about information theory is a solid understanding of the book by Cover, then stack on top significant knowledge about the physical systems used under the software and have detailed models for them.
This is why people should be skeptical about this stack.
> His post states, correctly, that a hash is as secure as its weakest entropy source. Adding more bad ones does not strengthen it. He doesn’t say you can ignore the entropy per source, and simply hope one “is secure,” whatever the heck that even means.
I believe it is you with the misunderstanding. A hash is as secure as its _strongest_ entropy source provided that none of the inputs can snoop on the others. The key point being made in that blog post is that if a malicious source can snoop the other inputs and has knowledge of the implementation then it could potentially (partially) control the output. That's quite a high bar, and even then the attacker is limited to a brute force search for the desired partial output.
> you cannot know if you have enough entropy accumulated for an operation
This is superstitious nonsense. Entropy is merely an estimate of the effective size of the input space, ie how hard an attacker would have to work to exhaustively search it.
> The nice thing about a secure XOF is that it doesn’t matter if the entropy given to the XOF is less than perfect. If an XOF is given 10 different sources of entropy, and only one of them is secure, the XOF will remain secure. [1]
Isn’t that also true of the cryptographic sponge function that is used to implement /dev/{,u}random?
No you see what we do, Is we ask Claude to make no mistakes in implementing the CSPRNG. This way we ensure there are no mistakes in the implementation or mathematics.
I know it’s a joke, but that code wouldn’t pass the DieHard tests. That’s actually one of the tests I did with the XOF I used, a test I ran over 16 years ago.
We do know that whales have distinct regional dialects. I would assume that any animal complex enough to have aspects of their behavior not entirely determined by genetics (in other words, taught by parents or peers) exhibits regionally distinct behavior. So yes, dogs probably have "accents." Naively, it seems like it would be weird if they didn't.
Yes, models are a good use for P2P especially if everyone agrees to share the same torrent and someone (or a cohort) commit to seeding for the long haul.
I was hoping for the "all cards visible and one free slot to put a card in"
reply