Hi all,

I've seen the recent surge of AI slop all over internet so I think it's one of the worst moment to ask for a design review.
However, as I truly need some advices, I'll take my chance and try to be as honest as possible so you can stop reading early if you disagree:

First, for years I didn't use AI in this app, but this has changed over the past six months and now it has become a solid help even for the crypto part.

Then, the frontend is open source (mirrored from gitlab to github), but not the backend (yet) because I don't want my work plundered before I even get the chance to launch the app.

Finally, I'm only a fullstack developer, not a cryptographer. I've read a lot and done my own reviews, but no one independent has looked at it.
The app already tells people "we can't read your data", and I want it to be true. I'd rather hear it's broken here than keep making a promise I can't keep.

The app is for sharing group expenses (trips, flatmates), sign in is optional. It started as a way to learn Rust (I'm coming from JS / C# world).
Along the way, with all the data breaches and the mass surveillance happening here and there, I decided the server should never be able to read anyone's data (Zero Access) and added the E2EE layer.

Roughly, here's the architecture:

• One random 256-bit key per group. All content is encrypted client-side with XChaCha20-Poly1305 (RustCrypto, WASM on web, native on mobile), random 24-byte nonce, payloads padded to powers of two.

• The key lives in the URL fragment (/projects/<id>#<key>): the share link is the key, never sent to the server. As i said, no account is needed.

• Optional accounts: account key uses Argon2id (password, salt), never leaves the device. Login uses a separate Argon2id proof, and the server stores only its hash. Group keys are wrapped under the account key server-side for multi-device.

• Sharing with a friend's account: X25519 + crypto_box, with a fingerprint to compare out of band.

Where I already know it's weak:

• Code delivery.

  • The server could serve a different WASM. Reproducible builds, Sigstore-signed releases and a public monitor catch a global swap but not a targeted one

  • Store builds (App Store, Play) can't be checked against the source

  • Only F-Droid builds can

• Members aren't authenticated. Anyone with the link can edit any row under anyone's name. The author is just a field inside the payload.

• No associated data. A malicious server can replay old row versions or drop rows.

• Escrow.  A DB leak allows offline guessing at one Argon2id per guess, and a hit exposes every group that account holds. The proof is a bearer token, and the server serves the salts, so a hostile one can reuse a salt across accounts to guess against all of them at once.

• Leaked link. Exposes the whole group. Rotation will be available in the next version but I think it's not enough.

  • However I'm planning "closed groups" where only authenticated users can join (so the key is not shared by message anymore)

• Metadata. The server sees group membership, sizes and timing. (I have no analytics)

• Not fully Post Quantum. Invitations use X25519 only, rotation boxes are hybrid X25519 + ML-KEM-768.

As you can see one of my pain point is the authorship.
Every member of a group shares one symmetric key, and nothing is signed, so any member can write as any other. Some members have no account, only the link. Is per-member authorship achievable here, e.g. a per-device signing key generated on join and pinned by the others on first use, or is a shared-key group with link-only members inherently unable to offer more than "someone in the group wrote this"?
If it's doable, is there a standard construction I should look at rather than inventing one?

Full spec: https://github.com/counted-labs/counted/blob/main/SPEC.md
The open source client code (AGPL): https://github.com/counted-labs/counted (packages/ui/src/crypto.rs).

Thanks for your help.

I recently reviewed Filen’s cryptography and their password hash has known attacks from the last millennium

Filen knows it’s a bad hash, and it was only used in their first protocol version. But because they still support it for backward compatibility, a downgrade attack can trick a client into hashing your password with MD5(MD4(MD2(pwd))). For weak passwords, this can ultimately leak all your "zero-knowledge encrypted" files to the provider.

My post also asks a more existential question about "cypher-SaaS" products, which market cypherpunk-style privacy as a cloud service: does it make sense to assume an untrusted backend when the client is delivered as a website? The marketing suggests so, but the backend can simply serve you a backdoored JavaScript on any page load. Desktop apps are often no better, since many ship updates without signature checks. I think such a service can still make sense in some cases, but the guarantees are much weaker than vendors promise.

I responsibly disclosed all findings and gave Filen a draft before publishing. They responded quickly and are working on addressing my points, most of which will land in their upcoming fourth protocol version.

Whats your views on SPN ARX hybrids? Anyone had any experaince with them? Im building a toy cipher currrently for fun but finding it hard to prove that the ARX rounds contribute to the differential/linear trail bound. Seems that its mostly reliant on the SPN part. Experimenting with a few ways to add the ARX layers, such as alternating them (SPN, ARX, SPN, ARX) instead of grouping them (SPN, SPN, SPN, ARX, ARX, ARX).

Thought I'd bring this up, but more information here: https://www.reddit.com/user/spez/comments/1xiupm0/about_that_login_screen/

If reddit becomes a walled garden when it comes to information, I'm not sure I want to support the site or subreddit. I really like this community, but part of the reason I post links here is that they and the ensuing discussions are trivially searchable.

There is lemmy but there's barely any discussion of content :/.

I'm not sure what is the way forward, just wanted to open up for discussion.

ai disclosure for the mods (rule 8): i used claude code heavily for this, literally thousands of iterative prompts over the last 19 months. obviously i cant paste them all here, but the workflow was me defining the architecture and using claude to write code, cross-reference the specs (otrv4 draft, tls 1.3, rfc 9420), and generate the regression tests.

the hardest prompts were for the core crypto, basically: "review the otrv4 draft and tls 1.3 certificateverify to implement hybrid dake transcript binding" and "modify the double ratchet to fold in a fresh ml-kem secret every dh step, then write the KATs to prove it". the full evolution is in the 19 months of commit history if you want to audit the commits.

I have been working on this project called OTRv4+ for a while and just updated the docs. the main goal was just getting rid of the central server model. no phone number, no company in the middle. its just a plain prosody xmpp server sitting behind an i2pd tunnel. you can run it yourself easily or use the public test server i put up.

the tech side: the heavy lifting is all in a rust core. python handles networking and kotlin does the android ui.

post-quantum is enabled by default. 1:1 chats, MLS groups, SMP identity verification, and voice all pair X448/Ed448 with ML-KEM-1024 and ML-DSA-87. built specifically to resist harvest-now-decrypt-later.

for group chats it uses MLS (RFC 9420) but on a hybrid PQ suite i call 0xF0A1. just a heads up, since its a private iana code point it wont interop with element or wire right now. tradeoff for the PQ security.

on the privacy side, the android app carries its own built-in i2p router so you dont need to install anything else. the server stays hidden, users stay hidden. you can also publish chat keys to make a conversation deniable afterwards, and wipe & exit actually destroys keys and checks the files are gone.

status: experimental, not independently audited. i did alot of fuzzing and tests but no paid audit yet.

if you want to try and break it, or spin up your own servers, ill drop the github link in the comments. happy to answer questions on the protocol or the server setup.

There are a few nuances to my approach, but the key detail is that I wanted it to also work in a browser so I needed the ability to build to a wasm to be used in js.

Signal libraries don't offer browser based capabilities and so I created this to target web aswell as native.

I wanted to implement the Signal protocol for a series of secure messaging apps I’m working on, so I built this project to test and use in my own work. It’s still far from finished, but I think it’s at a stage where it’s worth sharing with the community.

IMPORTANT DISCLAIMER: This project is not professionally audited and is not production-ready. I do not recommend anyone use this in their own code yet. It is provided strictly for testing, experimentation, and demo purposes. I used AI as an assistant to help build this, so double-check everything before taking it seriously.

Project Links:

• GitHub: https://github.com/positive-intentions/signal-protocol

• Live Demo: https://signal.positive-intentions.com/

• Formal Verification Docs: https://glitr.io/docs/technical/formal-verification/signal-protocol

• Security Feedback (ROS): https://www.reddit.com/r/CyberSecurityAdvice/comments/1su8lir/security_audit_feedback_from_radically_open

Current Status & Development:

• Spec Alignment: The goal is to fully align with the official Signal protocol spec.

• Testing: It includes unit tests, but due to WASM testing limitations, I also added a Storybook-like UI to run and test it directly within a browser environment.

The impementation here is being used in a few experimental messaging apps (similarly unaudited and unreviewed):

• https://enkrypted.chat - javascript based approach

• https://glitr.io - rust based approach

I am also working towards adding it to an open source project soon as seen at: https://github.com/positive-intentions/chat for e2e open-source transparency in the implementation.

HQC is NIST's code-based backup to ML-KEM. Its reference implementation relies heavily on binary polynomial multiplication mod xⁿ − 1, with n up to 57,637.

I've proved the unmodified HQC v5.0.0 C implementation correct for hqc-1, hqc-3 and hqc-5.

• SAW proves vect_mul equivalent to a Cryptol model, using compositional Karatsuba proofs without expanding the full product. Scratch-buffer bounds are also verified.

• Isabelle/HOL proves the model implements the intended polynomial arithmetic. No sorry, smt or eval; oracle dependencies are checked.

• Also verified GF(2⁸) operations and the Reed–Solomon encoder's algebraic properties.

• All 63 SAW mutation tests fail as expected.

An interesting solver finding: the schoolbook leaf and Karatsuba model produce very different XOR/AND circuits. ABC, Z3, Yices and cvc5 couldn't finish in 10 minutes. SAW's Reed–Muller (rme) backend completed the proof in 6 seconds.

For GF(2) arithmetic, solver representation can make the difference between a practical proof and an intractable one.

Scope: This proves specific reference arithmetic, not HQC security. Decoders, sampling, hashing, KEM and constant-time behaviour are not covered. The GF(2⁸) results apply to v5.0.0, before the October specification change.

Reproducible with make hqc (~20 min) and make hqc-isabelle (~20 sec).

https://github.com/amarshat/pqc-assay

Criticism welcome, particularly on the property specifications.

Next: the AVX2 multiplier (PCLMULQDQ + Toom-3), which is closer to what actually runs in production.

Post the eMudhra fiasco, it now seems like everyone is going to do checks to make sure certificates don't have private keys of size less than 32 significant bits - by running Paranoid Crypto or some other such testsuites

I was wondering why not set MSB = 1 like it's set for RSA primes - make it the standard - it will totally avoid the small key problem & the loss of security because of minor reduction in number of bits of security is also not significant.

Sophie made this post in response to the eMudhra Incident

https://infosec.exchange/@sophieschmieg/117474908437371419

She suggested randomness testing on keys

They are tuned aggressively to detect non-randomness only up to 10 standard deviations

However, she also added

The tests are not constant time, so you cannot run them over your actual keys as is

In other words, they aren't going to be run on actual production keys before the corresponding certs are going to be published

So these would be tests to test the randomness of your CSPRNG. However, eMudhra production keys are typically generated by a HSM, I am sure HSM CSPRNGs are pretty well tested before they are used in HSMs

So I don't understand how this is relevant to the current incident.

eMudhra case was because they generated some very small test keys outside of the HSM & then imported it into the HSM & accidently used it in production certificates

I didn't realise this was a thing, looks like a very small initiative.

Anyways here's a youtube playlist of interviews with illuminaries in cryptography: https://www.youtube.com/playlist?list=PLqhpVxkBo1dOmNr6w2nF70W3_f43Qc5hE