Your post here says ML-KEM768 but the website says Kyber512.

Also, this SRP implementation seems a bit... sus.

https://github.com/ellipticc/drive-frontend/blob/main/lib/sr...

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.

▲

some_furry 4 days ago | parent [-]

Side-channels. Also, N and G matter a lot to security; not making those hard-coded and transparent is sus. You can't just use a normal DH group.

I would recommend OPAQUE instead.

	▲	iliasabs 4 days ago \| parent [-]
		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!