First of all, thanks for the thoughtful comment and link.
You're right that rotating every crypto algo to PQC right away might be a bit too aggressive. The actual best practice (like you said) is hybrid: layer ML-KEM/ML-DSA on top of RSA/ECC for redundancy.
Classical algos aren't dead yet, but Shor's clock is ticking, and for now those NIST-standardized (FIPS203 for ML-KEM, FIPS204 for ML-DSA) PQC algos didn't break for now.
That's why Cloudflare for example uses ML-KEM alongside X25519 for their TLS key exchange (https://cyberpress.org/cloudflare-enhances-security/).
And yeah.. presenting a single algo as the perfect solution. That gives Dual_EC vibes, perfect spot for a backdoor.
Hi, thanks for pointing this out, code sample has been fixed (using mlkem library now, pqcrypto.kem.kyber768 was deprecated late 2022 and fully removed from PyPi in early 2023).
I tried only the RSA code but not the Kyber one, lesson learned.
Thanks again for taking your time to read, test and report.
No worries, I totally get it.
The style definitely came off too polished rather than being authentic, raw.
I’ll stick closer to my own voice in the future.
Appreciate the advice.
Totally get the fatigue around SaaS posts. This one was to explain the differences in simple terms, polished/rewritten with AI.
The CTA was optional, I’ll make it clearer next time.
Thanks for the feeeback.
Fair point on the writing style, I’ll try to make it better next time.
The post itself hasn’t been AI-generated but rewritten/polished with AI.
Appreciate you taking the time to read it and giving feedback.
This seems like a solid embeddable option. Have you tried it in a real-time analytics or caching scenario yet? Curious how it behaves under heavy write loads.
Yep, that’s correct—none of the companies listed are actual clients. They were just placeholders to make the landing page look a bit more complete while we’re still early in the product’s journey. Appreciate you pointing it out—I’ll make the site more accurate soon.
You’re right—integrating remote storage would improve the experience. WebDAV is an option, but I’ll need to explore ways to make it work while keeping true E2EE intact.
Regarding the testimonials, the companies listed in the marquee were just placeholders to make the landing page cleaner. I appreciate the example you shared—it’s helpful to see what real testimonials look like, and I’ll consider updating ours to be more genuine.
The repo is the frontend — it includes all the client-side encryption, authentication, and UI logic.
It’s still a bit rough around the edges design-wise, but the core logic and crypto implementation are solid and fully functional. Some features like settings and user profile are just placeholders for now(in dev.)
Thanks a lot for the feedback — that was really helpful!
I’ve just pushed an update addressing your points:
commit d94969a(https://github.com/ellipticc/drive-frontend/commit/d94969a63...)
— N and G are now public, hard-coded RFC 5054 constants (3072-bit for new users, keeping 2048-bit compatibility), and I fixed the session key calculation length.
I’ll definitely look into OPAQUE later on — I did some early testing, but ran into a WASM-related crash on the server side, so I’m holding off until I can debug that properly.
Really appreciate you pointing this out — it helped tighten things up!
Thanks for the feedback — to clarify, only the frontend is open-sourced at the moment, sorry for any confusion.
I’ve also just added an MIT License to make that explicit.
The backend isn’t public yet, but we may open parts of it later.
Thanks for pointing that out! Could you elaborate on what specifically looks off about the SRP implementation?
I tried to follow RFC 5054 with some minor adjustments for the frontend (using hash-wasm and fixed-length encoding to match the server), but I’d really appreciate feedback if something looks wrong or insecure.
Yes, sorry — I’ve focused more on the actual logic of the dashboard rather than the landing page, which still lacks polish.
Regarding the data, all your files are stored on Backblaze B2 servers (EU-central), with their data centers located in Amsterdam, Netherlands.
I hope I’ve answered your question correctly.
You're right that rotating every crypto algo to PQC right away might be a bit too aggressive. The actual best practice (like you said) is hybrid: layer ML-KEM/ML-DSA on top of RSA/ECC for redundancy. Classical algos aren't dead yet, but Shor's clock is ticking, and for now those NIST-standardized (FIPS203 for ML-KEM, FIPS204 for ML-DSA) PQC algos didn't break for now. That's why Cloudflare for example uses ML-KEM alongside X25519 for their TLS key exchange (https://cyberpress.org/cloudflare-enhances-security/).
And yeah.. presenting a single algo as the perfect solution. That gives Dual_EC vibes, perfect spot for a backdoor.