the openssl SRP implementation seems to handle salts with leading
zero-bytes incorrectly.
salts are internally passed around as BIGNUM, and converted back
to uchar* before using them. however, they are only ever needed
as uchar*: only used for SHA1-ing. so my guess is the conversion
to BIGNUM, and back to uchar* strips leading zeroes.
i encountered this when testing a new client+server tls-srp implementation
(in golang) against openssl. the authentication fails with salts with
leading zeroes (it succeeds with other salts). fwiw, i also tested
against gnutls, and could authenticate just fine with such salts.
for example, compare, in file crypto/srp/srp_lib.c (openssl-1.0.1g):
BIGNUM *SRP_Calc_x(BIGNUM *s, const char *user, const char *pass)
with http://tools.ietf.org/html/rfc5054#section-2.4
x = SHA1(s | SHA1(I | : | P))
v = g^x % N
where I stands for identity, or user.
the use of x (bytes from sha1) in the calculation of v is allowed
due to an implicit conversion to a number, as defined at the bottom of
paragraph 2.1, http://tools.ietf.org/html/rfc5054#section-2.1
however, for salt s, no such implicit conversion is needed.
and the same goes for (same file):
char *SRP_create_verifier(const char *user, const char *pass, char
**salt,
char **verifier, const char *N, const char *g)
which calls:
int SRP_create_verifier_BN(const char *user, const char *pass, BIGNUM
**salt, BIGNUM **verifier, BIGNUM *N, BIGNUM *g)
thoughts? does conversion from uchar* to bignum, and back to uchar*
indeed strip leading zeroes?
i think the salt should always be passed around as just bytes. in SRP
it is never used for calculations with bignums.
cheers,
mechiel
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
