Soatok Dreamseeker
Loup-Vaillant wrote this on Lobste.rs:
Personally I would actively avoid the check,
Hmm. What a weird thing to say.
Loup-Vaillant wrote a cryptography library called Monocypher, which famously had an EdDSA vulnerability mostly caused by their insistence on rolling their own custom EdDSA variant to avoid SHA512.
"I wonder how Monocypher holds up in 2026?"
Who said that? Well, anyway:
ticho
@soatok Feuding crypto-experts hate-reviewing each other's code is exactly the kind of vibe we need. Talk about adversary testing! 😎
Soatok Dreamseeker
@ticho I honestly welcome their feedback, no mater how dickish it will be, because it's a good way to learn your own blindspots before you ship to prod
Sayuri 💛⬜️💜🖤 ΘΔ
@soatok because who checks for buffer lengths in c anyways it just wastes cycles
wat
also pretty sure "user error" is exactly how exploits are born
Inex Code
@soatok making input validation (with many preconditions and requiring specific knowledge) a user's responsibility sounds like a recipe for disaster
F4GRX Sébastien
@soatok
> closed as not planned.
Lmao.
> The absence of input validation is core to the design of Monocypher, and Well documented. This allows Monocypher to simplify error handling and maximise portability. What you found was normal and expected.
Oh my dog
Dan Sugalski
@soatok Wait, so the entire input validation scheme is "don't call it wrong?"
That's... well, that's a choice you can make, I guess.
Soatok Dreamseeker
@wordshaper Our Threat Model is "You must only accept secure inputs if you want secure outputs".
Dan Sugalski
@soatok good thing this code doesn’t have to operate in an adversarial environment. Something unfortunate could happen.
lainy
Soatok Dreamseeker
@david_chisnall @lain @inex Yeah but https://github.com/LoupVaillant/Monocypher/issues/285#issuecomment-3991233186 lol
David Chisnall (*Now with 50% more sarcasm!*)
That's not uncommon in C. The Java Native Interface has a design rationale document that says that it doesn't, for example, check null pointers because it's impossible to check for the general case of invalid pointers.
I don't really agree with this philosophy, but it did provide a nice showcase for CHERI (the JNI was explicitly designed to not be a trust boundary, so being able to turn it into a defensible one was great).
David Chisnall (*Now with 50% more sarcasm!*)
I'm not sure that's an improvement. You defined the macro as:
+#define MONOCYPHER_CHECK(cond) do { if (!(cond)) return; } while (0)But this is returning without reporting any error. And that's necessary because the functions that they're in return void. But now they will simply not do the operation and fail. So now the outputs are full of uninitialised values.
And that's why functions returning void are bad code smell in crypto libraries.
Rich Felker
@david_chisnall @soatok @lain@lain.com @inex Indeed this seems worse. You need to either abort, longjmp to an error hander, or at least setup the structures in a form to defer the error til it's reportable later.
Soatok Dreamseeker
@dalias @david_chisnall @inex Yeah, the existing codebase is not amenable to good programming practices. I'm going to recommend libhydrogen instead.
Rich Felker
@soatok @david_chisnall @inex If valid input parameters are actually part of the interface contract, aborting seems perfectly reasonable and the best-hardened choice. Current behavior is also reasonable (as long as contract is clearly documented) but poor in terms of hardening. I doubt it matters unless there's a viable scenario where these parameters come from external input not the calling program text.
Soatok Dreamseeker
To be fully transparent: I have turned down job offers before because I do not feel comfortable writing C. Almost everyone I've met that believes they can write secure C code is overconfident, and that scares me. So I'm certain that a better patch is possible.
That said:
You're going to get an invalid output if you proceed with invalid parameters. Silently aborting immediately versus allowing stack corruption is a losing position to be in.
![[HANDMAIDEN] xan](https://gnusocial.jp/avatar/43531-48-20250829025252.webp){kind=small}
[HANDMAIDEN] xan
@soatok @dalias @david_chisnall @inex not to toot my own horn or anything, it can be done, only because the following are not optional for me:
• Valgrind/Address Sanitizer
• gcov
• Obsessive use of RAII
• Insane number of tests
and this philosophy must be present from the beginning. look at Monocypher...good lord
Rich Felker
@xan @soatok @david_chisnall @inex I'm confused about the value of test harnesses being in another language. Do you just mean not executing in the same process domain where memory corruption in the code being tested could impact the test harness and its detection/reporting of failures? Because that's easily handled just by separating these domains. Or do you have some other reason?
[HANDMAIDEN] xan
@soatok @dalias @david_chisnall @inex oh and also: maintain your test harnesses in another language, preferably through a memory profiling+debugging tool because no leaks, no use-after-free, no out-of-explicit-allocation-access should be acceptable. oh, and your memory profiling tools should know about any custom allocators you've made, too, and yes, that means your little arena and buddy allocators
Rich Felker
@xan @soatok @david_chisnall @inex That's kinda what I figured. Thanks for replying to clarify.
[HANDMAIDEN] xan
@dalias @soatok @david_chisnall @inex yeah the domain/process isolation is the main thing here; i guess i specified "language" here because i'm putting the final touches on the FFI portions of a programming language i'm implementing with a very thin/general VM and so i've got all that on my mind
professional box/furniture thrower
@soatok Someone mentioned libhydrogen as what you would use if you considered using monocypher, and I'd like to point out: Reading libhydrogen's code, they have very simple input validation that would be easily replicable here, and yet the developer says "No, it would break portability to check" ?????
Libhydrogen is portable, so ？？？？？
Orange Lizard Girlthing
@soatok @dalias @david_chisnall @inex Secure C and C++ code is a lie made up by Keith the Rat to make you bring him more cheese.
abadidea
@soatok I am truly baffled that someone who considers themselves an engineer — a CRYPTOGRAPHIC engineer! — would read “the value MUST be between x and y” and consider it not their implementation’s responsibility to enforce but the user’s
Zip
@soatok
Remind me never to get on your bad side lmao
Sayuri 💛⬜️💜🖤 ΘΔ
@vfrmedia @soatok and even then I would not be surprised if someone found an exploit in my game, its the attitude upon being made aware of said exploit that is very very important.
I'd trust software that had 1000s of reported vulns if the author was responsibly mitigating them vs. one with like 3 but the author was like "meh you're just using it wrong"
Sayuri 💛⬜️💜🖤 ΘΔ
@vfrmedia @soatok everything* starts with c, if you're writing a fundamental library, a video game engine, part of an operating system, etc. you do want to be as lightweight as possible.
you do want to fight the attitude of not optimizing because then we get Electron apps and e-waste.
not buffer checking (for whatever reason) however saves you very little vs. how dangerous it is, i'll even range check when i'm writing Z80 or 6502 programs just to save headaches.
Alex@rtnVFRmedia Suffolk UK
@wolfcoder @soatok hang on what /century/ are we in? not like we are still programming Z80 or 6502 and trying to squeeze out every last bit of performance, surely a few extra clock cycles won't break the bank these days?
Soatok Dreamseeker
I guess I should just tap the sign whenever I encounter this sort of personality:
https://soatok.blog/2026/02/25/cryptography-engineering-has-an-intrinsic-duty-of-care/
Botch Frivarg
@soatok in this article you in passing mention something that has frustrated me for some time in software engineering as someone with a bit more of a hardware background, and that is how much important stuff doesn't build on formal specifications, even big infrastructure projects! And when I have brought this up I'm often met with something along the lines of "but that is not very agile" or "we moved away from waterfall". Sure that small backyard shed you can yolo together, but why are we doing the same thing for the highway bridges of the software world?
Bersl
@deetwenty @soatok I think the most frustrating thing I heard from my boss on Monday is the sentiment of "Oh, the transition to AI coding means that we have to throw away all of the Agile we've been working on and basically go back to waterfall. The best way to use it is to write out your specifications first."
So, the planning that we should have been doing a long time ago is only worth bothering to do once the robots are here?
This is how I know we're in hell.
Soatok Dreamseeker
@NohatCoder @f4grx Right, the main reason the Matrix thing was an issue was because of how group key management was implemented, and the all-zero DH broke secrecy for everyone else using Megolm
Jacob Christian Munch-Andersen
@f4grx @soatok The thing is you can reasonably argue that it is not important, the cost of doing the check is just so low that doing it simply to eliminate some analysis complexity is worth it.
The mere fact that someone can break the secrecy of a transaction in which they partake is not really a vulnerability, because that is always the case, no protocol can prevent that someone simply chooses to share their private key with the world.
F4GRX Sébastien
@NohatCoder @soatok if an important protection is easy to check, it has to be implemented. Not implementing the simple checks is... Somewhat... Criminal, in a way? Like, you know you should do it, it's easy to do, the consequences could be critical... And yet you dont do it. Why!
Jacob Christian Munch-Andersen
@f4grx @soatok There is this argument that even if a zero key is in some way bad, you don't really need to check if your rng produces all zeroes when generating a key, because the probability that this happens is so low as to be effectively impossible.
However, when you accept someone else's key as part of some interaction they could have maliciously set it to 0. It is not obvious that that bestows any major ability, but the threat analysis gets complicated, it is easier to just do the check.
F4GRX Sébastien
@soatok wow I did not check your original link before.
>in my opinion such a tiny threat is not worth the additional complexity of even a single if statement.
WHAT THE FLYING FUCK
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.