Padding of g

[yallie]

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?

[yallie]

A couple of notes:

1. Fixing the padding of g won't affect existing credentials: k is not used to derive the private key.
2. RFC5054 uses sha1, so the test vectors are not directly applicable (unless params.js also use sha1).

[LinusU]

Nice API, very clean code, so easy to follow

Thank you 🙌

RFC5054 specifies that g should be left-padded with zeros to be the same length as N.

Hmm, yeah this should probably be fixed. Although RFC5054 specifies specifically how to use SRP as an authentication strategy for the TLS protocol, it seems like most libraries are following it so that seems to be the de facto standard for SRP.

It also seems that A and B should be padded when calculating u.

I'm trying to look at a few other libraries to see what they are doing:

Libray	k	u	M	H(A, M, K)	ping
RFC5054	padded	padded
pysrp (rfc5054_enable)	padded	padded	only g	not
srp-client	padded	padded	?	padded	@symeapp
srp-rb	padded	padded	padded	padded	@lamikae
go-srp	not	not	not	?	@opencoff
SRP.swift	padded	padded	not	not
srptools	padded	padded	not	not
srp-6a-demo (PHP)	not	not	not	not	@RuslanZavacky
DragonSRP	padded	padded	not	not
srp4net	padded	padded	not	not
Eneter	padded	not	not	not	not on Github

Feels quite clear that we should pad k and u.

I've pinged the authors of implementations that don't follow that here, feel free to chime into the discussion here!

It's going to be a pain to update this for me though, already have multiple clients in production that are distributed in different channels 😂

[yallie]

Thanks for the detailed analysis! 👍
My 2 cents:

Library	k	u	M	H(A, M, K)
srp4net	padded	padded	not	not
Eneter	padded	not	not	not

It also seems that A and B should be padded when calculating u.

Good catch, I missed that!
I only looked at numbers that didn't match the test vectors.

It's going to be a pain to update this for me though, already have multiple clients in production

That's the problem :)

[LinusU]

My 2 cents

Awesome, adding them to the list!

That's the problem :)

I wrote a migration guide in #13, it's a bit inconvenient, but not too bad ☺️

[LinusU]

So I tried getting pysrp to output all the values, and then plug them in here to see that everything works. Turns out that they are doing another padding which makes it incompatible:

https://github.com/cocagne/pysrp/blob/9d43e9a35e354a1ff1c6abdf12276922cadef97e/srp/_pysrp.py#L196-L205

Instead of doing

M = H(H(N) xor H(g), H(I), s, A, B, K)

they are doing:

M = H(H(N) xor H(PAD(g)), H(I), s, A, B, K)

🤔

@yallie any idea which one is correct?

[LinusU]

Lib
pysrp (rfc5054_enable)	H(PAD(g))
SRP.swift	H(g)
srptools	H(g)
DragonSRP	H(g)

Seems like maybe pysrp is the outlier here 🤔

ping @cocagne

[yallie]

Looks like RFC5054 doesn't specify how M is calculated.
And the original SRP-RFC doesn't specify where padding is required.
Too bad 😕

I'd say that g should be padded anywhere its value is hashed.
If k uses padded g, then M should also use padded g.

UPD. Wikipedia SRP example doesn't use padding:

print("6. client sends proof of session key to server")
M_c = H(H(N) ^ H(g), H(I), s, A, B, K_c)

[LinusU]

Hmm, yeah potentially, although one other way to see it is that it was padded in the other case to make it as long as the other part of the concatenation...

🤔

I'm going to leave this open for a while to see if anyone of the pinged persons responds. Whatever we decide on, I could go and submit pull requests to all the linked repositories so that at least everyone uses the same.

also ping @Bouke, @idlesign, @slechta and @osorin

[opencoff]

I just saw this; let me do some additional reading of RFC5054. I will respond in the next few hours. -- S

…

On 05/23/2018 09:09 AM, Linus Unnebäck wrote: Hmm, yeah potentially, although one other way to see it is that it was padded in the other case to make it as long as the other part of the concatenation... 🤔 I'm going to leave this open for a while to see if anyone of the pinged persons responds. Whatever we decide on, I could go and submit pull requests to all the linked repositories so that at least everyone uses the same. also ping @Bouke <https://github.com/Bouke>, @idlesign <https://github.com/idlesign>, @slechta <https://github.com/slechta> and @osorin <https://github.com/osorin> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIPwW-4G5PKYNJPZ66W1Ofjzc8GILH0lks5t1W2DgaJpZM4UJc2H>.

[yallie]

Looks like Stanford reference SRP-6 implementation doesn't use padding in H(N) ^ H(g):

// srp6_client.c, line 94
static SRP_RESULT
srp6_client_params(SRP * srp, const unsigned char * modulus, int modlen,
		   const unsigned char * generator, int genlen,
		   const unsigned char * salt, int saltlen)
{
  int i;
  unsigned char buf1[SHA_DIGESTSIZE], buf2[SHA_DIGESTSIZE];
  SHA1_CTX ctxt;

  /* Fields set by SRP_set_params */

  /* Update hash state */
  SHA1Init(&ctxt);
  SHA1Update(&ctxt, modulus, modlen);
  SHA1Final(buf1, &ctxt);	/* buf1 = H(modulus) */

  SHA1Init(&ctxt);
  SHA1Update(&ctxt, generator, genlen); /* <------------------ g is not padded */
  SHA1Final(buf2, &ctxt);	/* buf2 = H(generator) */

  for(i = 0; i < sizeof(buf1); ++i)
    buf1[i] ^= buf2[i];		/* buf1 = H(modulus) xor H(generator) */

  /* hash: H(N) xor H(g) */
  SHA1Update(&CLIENT_CTXP(srp)->hash, buf1, sizeof(buf1));

  SHA1Init(&ctxt);
  SHA1Update(&ctxt, srp->username->data, srp->username->length);
  SHA1Final(buf1, &ctxt);	/* buf1 = H(user) */

  /* hash: (H(N) xor H(g)) | H(U) */
  SHA1Update(&CLIENT_CTXP(srp)->hash, buf1, sizeof(buf1));

  /* hash: (H(N) xor H(g)) | H(U) | s */
  SHA1Update(&CLIENT_CTXP(srp)->hash, salt, saltlen);

  return SRP_SUCCESS;
}

and

// srp6_server.c, line 98
static SRP_RESULT
srp6_server_params(SRP * srp, const unsigned char * modulus, int modlen,
		   const unsigned char * generator, int genlen,
		   const unsigned char * salt, int saltlen)
{
  unsigned char buf1[SHA_DIGESTSIZE], buf2[SHA_DIGESTSIZE];
  SHA1_CTX ctxt;
  int i;

  /* Fields set by SRP_set_params */

  /* Update hash state */
  SHA1Init(&ctxt);
  SHA1Update(&ctxt, modulus, modlen);
  SHA1Final(buf1, &ctxt);	/* buf1 = H(modulus) */

  SHA1Init(&ctxt);
  SHA1Update(&ctxt, generator, genlen); /* <--------------- same here, g is not padded */
  SHA1Final(buf2, &ctxt);	/* buf2 = H(generator) */

  for(i = 0; i < sizeof(buf1); ++i)
    buf1[i] ^= buf2[i];		/* buf1 = H(modulus) XOR H(generator) */

  /* ckhash: H(N) xor H(g) */
  SHA1Update(&SERVER_CTXP(srp)->ckhash, buf1, sizeof(buf1));

  SHA1Init(&ctxt);
  SHA1Update(&ctxt, srp->username->data, srp->username->length);
  SHA1Final(buf1, &ctxt);	/* buf1 = H(user) */

  /* ckhash: (H(N) xor H(g)) | H(U) */
  SHA1Update(&SERVER_CTXP(srp)->ckhash, buf1, sizeof(buf1));

  /* ckhash: (H(N) xor H(g)) | H(U) | s */
  SHA1Update(&SERVER_CTXP(srp)->ckhash, salt, saltlen);

  return SRP_SUCCESS;
}