New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
also, you should publish a docker image, id prefer to not run an installer
Thanks for the suggestion.
For now, Marix is designed as a native desktop application that relies on system integrations (SSH agent, filesystem, GUI, RDP), which makes Docker a poor fit for the primary use case.
A containerized option might be considered later for specific workflows, but native packages are the intended way to run Marix.
The point I was making is someone who you have never heard of before is offering feature rich but low security app - are you really going to trust this with your server auth which leads to your most important data? Risk of compromise high.
That’s a fair concern, and I don’t expect blind trust.
Marix doesn’t introduce a backend or remote secret storage — all credentials stay local and are encrypted before any backup leaves the device.
The project is fully open-source so the security model, threat boundaries, and implementation can be reviewed directly.
Ultimately, users should only run software they’re comfortable auditing or understanding, and it’s completely fine if Marix isn’t a fit for everyone.
Is it intentional to name being one letter off from matrix?
I'll stick with windows terminal to my jumpbox vm & tmux I guess. I don't think I'm the target audience here, but it looks pretty.
Sure, but what you said was confusing and misleading when not obviously taken as a joke.
Infosec expert here. I would strongly urge everyone to stay away from this client, or any brand-new SSH client, especially if it is vibe coded. Even a quick skim shows me several issues, such as using Argon2id with 16-64 MiB (which is severely insufficient) with only 3 (yes, three) iterations. That is insanely bad, combined with referring to it as "military-grade", shows an utter lack of understanding of cryptography.
The adage "don't roll your own" doesn't only apply to primitives, but even cryptosystems built upon established primitives. If you, or your LLM, are typing the name of any primitive into the code you use and you do not know off the top of your head when to use a PRP and when to use a PRF, why a public exponent of 3 is fine with OAEP padding, or the difference between AE and AEAD, please stay far away from cryptographic code.
You (or the LLM you use) also makes some beginner terminology mistakes, such as referring to GCM as tamper-proof (authenticated encryption provides IND-CCA2 security and would be better referred to as tamper-evident). Likewise, zero-knowledge is being misused when client-side encryption would be preferable. I'm sorry, but your claim that you do not use LLMs for cryptographic decisions is false, as it is clearly being used and, as is typical, choosing horrible parameters.
I suggested you read some posts related to PBKDFs on the Cryptography Stack Exchange, where I am a moderator.
Mate-rick react and pin it
Thanks for taking the time to provide detailed feedback from a cryptography perspective.
Some of the points you raised — particularly around Argon2id parameters and terminology usage — are valid, and I take them seriously.
The current parameters should not be considered final and will be adjusted in line with established best practices, with clearer documentation to avoid ambiguity. I also agree that marketing-style terms like “military-grade” are unhelpful in a cryptographic context and will be revised.
The goal of Marix is not to invent new cryptographic primitives or teach cryptography, but to apply well-known constructions in a way that is usable for non-expert users. The entire codebase is open-source specifically so that feedback like this can surface early and lead to concrete improvements.
I appreciate the technical critique and will address it in code and documentation rather than turning this thread into a prolonged cryptography debate.
Claiming entire codebase is open source doesn't add much trust. Most users are not tech savvy enough to understand the logic behind the written code.
There are some really high claims of manual code for core functionality vs llm driven code for non core functionality but its been debunked atleast one time. So either your knowledge/ understanding about security/ cryptography is different from what you claim vs what you know.
An independent third-party audit would be credible rather than asking community users to check the code.
Something to ponder on in your free time when not vibe coding.
Good luck 👍
There's no room for debate. You should not be releasing anything that uses cryptographic primitives if you don't have this understanding. This may be a fun pet project, but suggesting that others use it is grossly irresponsible, open source or not.
If I was able to see such major flaws within 30 seconds of skimming the codebase, who knows what else lurks there?
I disagree with the framing, but I take responsibility for addressing concrete issues.
Since your earlier comment, the cryptographic parameters and documentation have been materially updated:
• Argon2id memory has been raised to 64–512 MB, auto-tuned by system RAM, with a documented minimum floor exceeding OWASP guidance
• Iterations increased and parameter tiers made explicit
• Terminology corrected (client-side encryption, tamper-evident)
• A clear threat model and explicit non-goals have been added
The codebase is open-source precisely so early scrutiny can lead to measurable improvements. That process has happened here.
At this point, further discussion is best grounded in the current code and documentation, not assumptions based on earlier revisions. Users remain free to audit the implementation and decide whether it meets their own risk tolerance.
This entire conversation feels so familiar.
I'd recommend a fixed 256 or 512 MiB of memory with iteration count auto-tuned to take one second on the system. Your project is very heavy, so everything running on it will easily have that much memory.
In cryptography and information security, the burden of proof relies on the person making the claim of security, not the person doubting it. Even if I had found no issues whatsoever, it would not change the fact that it is highly irresponsible to suggest that users use a vibe coded project that directly calls cryptographic primitives and is security-critical.
Any project that's related to cryptography or security needs serious scrutiny, and this particular project has exactly zero eyes on it (you are not reading it of course, and the LLM doesn't count as an eye). This is dangerous and irresponsible.
Btw, a threat model, in the formal sense, is something that takes weeks to produce and lots of analysis. It's not something you can throw into a prompt, see output that looks vaguely like a threat model, and call it a day.
That’s fair. These discussions tend to repeat themselves in open-source security contexts.
The suggestion to auto-tune Argon2 to a ~1 second target is reasonable, and I’m considering it as a follow-up improvement.
I agree that in cryptography the burden of proof lies with the party making security claims. That is precisely why the project is open-source, why the threat model and non-goals are explicitly documented, and why concrete parameter changes have already been made in response to review.
I don’t expect users to “trust” the software or the author. The intent is to provide a locally-encrypting, auditable tool whose guarantees and limitations are clearly stated, so users can make their own risk assessment.
At this point, we fundamentally disagree on whether a project must meet a personal threshold of expertise before it may exist at all. I’m comfortable letting the current code, documentation, and future improvements speak for themselves.
What ever could you mean? 🌸
See my last sentence.
You didn't simply publish this on GitHub. You stated that you finished a security-related tool and advertised it for others to use. It can exist, sure. Hell, I've written my own block ciphers just as a learning experience, but I would absolutely never suggest that anyone actually uses them.
This isn't a personal opinion. All competent infosec professionals and cryptographers will echo what I am saying. It is like being an amateur chemist who knows how to synthesize organic compounds and has decided to release a new medication and suggested that people should try it out on themselves. You may know how to code (or rather, the people your LLM was trained on knew how to code), but you are not an infosec professional. This is an entirely different world where typical common sense maxims are useless.
We clearly disagree on the premise. I’ve stated the project’s guarantees, limitations, and intended use, and I’m comfortable letting users evaluate the current code and documentation on that basis. I don’t have anything further to add here.
I suggest you look at how https://lowendtalk.com/discussion/212947/release-zero-trust-lite-tiny-secure-zero-trust-gateway-for-your-vps went down before stating with such confidence that this vibe coded project has any guarantees that it can make.
Thanks for the reference.
Just to clarify: Marix does not make any absolute security guarantees — all security properties and limitations are documented and open for audit. Marix’s threat model is local client encryption for SSH backup workflows, and not an enterprise zero-trust gateway or global network trust system.
Comparisons between very different project goals may not always be directly applicable, but I appreciate the point that clear communication about security assumptions is important.
The slippery responses indicative of LLM output won't do anyone any favors. This response completely misses the point.
I understand your concern.
To keep this concrete: Marix does not claim universal security guarantees. Its scope, threat model, and cryptographic parameters are explicitly documented and open to review in the repository.
If there are specific, actionable technical issues you believe remain unaddressed, I’m happy to review them via an issue or pull request. Otherwise, I’ll leave it here.
And just like that, the entire point I was trying to make went woosh.
I'll reiterate my last point: It's irresponsible to release cryptographic code and code that deals with authentication without a solid understanding of the fundamentals. In the last few minutes just skimming the code, I've found several other serious vulnerabilities. But if you would really like to avoid the burden of proof being on you, so be it.
To anyone else who wants to use this LLM project, caveat emptor.
I think we’re talking past each other at this point.
I’ve documented the project’s scope, assumptions, and limitations as clearly as I can, and I’ll leave it there.
Update 1.0.7 https://github.com/marixdev/marix/blob/main/CHANGELOG.md
I don't want to be a dick as I've not looked at this beyond the screenshot.
He's not saying you haven't documented the scope and assumptions, he's saying that from a superficial look at the code he's identified multiple issues with the implementation that make it not fit-for-purpose as described.
If you describe your product as ultra-secure, but somebody can trivially crack the encryption because you made a stupid mistake somewhere (and not saying you have, just that you haven't proved that you haven't), it's all smoke and mirrors and doesn't actually provide any security. In fact, it's worse than no security, because people might rely on it and think they're protected when they might as well be storing their secrets in plaintext.
But like I say, I've not actually looked at what you've done. But I don't think I'd use it anyway, as I'm ultra paranoid and would only use stuff that's sufficiently well used and studied that people believe it's safe. So for me, that's limited to the standard ssh command line client and PuTTY for Windows.
I actually wondered if it was the same guy but didn't have a minute to go look for the other thread lol.
Same vibe I guess!
That’s a fair concern, and I largely agree with the principle you’re pointing out.
I’m very careful not to claim “perfect” or “unbreakable” security. The goal here is to clearly define the threat model and scope, and to avoid giving users a false sense of protection. If the implementation were fundamentally flawed, that would indeed be worse than having no encryption at all.
This is why the project is fully open source, the cryptographic design and parameters are documented, and changes are tracked transparently in the changelog. I fully accept that any security-sensitive software should be scrutinized, challenged, and improved over time.
That said, I also understand and respect your position as an ultra-paranoid user. Marix is not trying to replace OpenSSH or PuTTY, nor is it intended for users who require only the most battle-tested tools. It’s aimed at a different audience with different trade-offs.
Thanks for raising the concern in a constructive way — this kind of feedback is important, even when it comes from outside the target user group.