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.
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!
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.