Padding of g

Hello,

I'd like to thank for the excellent SRP-6a implementation!
Nice API, very clean code, so easy to follow 👍
I have a .NET backend, so I've converted the code to C#.

While porting the code I noticed that the library doesn't pad the value of g.
RFC5054 specifies that g should be left-padded with zeros to be the same length as N.

The leads to the miscalculated value of the k multiplier: k = H(N | PAD(g)).
As a result, the code doesn't pass the SRP test vectors (RFC5054, Appendix B).
Namely, the values of k, B and S don't match.

The library works just fine without the padding as long as the same code
is used on both client and server. But if the server code strictly follows the RFC,
the client won't be able to authenticate because of the different values of k.

Shouldn't it be fixed?

Start by comparing the library's SRP calculations with RFC5054 Appendix B, focusing on the padded value of g and the resulting k, B, and S values. Confirm that the implementation matches the RFC test vectors and that authentication remains interoperable with an RFC-compliant peer.