[gnutls-devel] [PATCH] srp: Add resistance against guessing usernames

[Nikos Mavrogiannopoulos]

On 02/19/2014 12:04 AM, Attila Molnar wrote:
> On Tue, Feb 18, 2014 at 7:52 PM, "Nikos Mavrogiannopoulos" <nmav at gnutls.org> wrote:
>>
>>>  	entry->v.data = gnutls_malloc(20);
>>>  	entry->v.size = 20;
> The verifier is always 20 bytes long regardless of the salt or
> the seed.

Ok, I see that this was set to 20 originally as well. Having a macro
would be more readable though.

>>> +	_gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed-
>>> size);
>>> +	cred->fake_salt_length = (salt_length < 20 ? salt_length : 20);
>>
>> Shouldn't they be DEFAULT_FAKE_SALT_SEED_SIZE?
> The 20 in this case refers to the output size of the hmac and is
> always the same unless hmac-sha1 is changed to something
> else with a different output size.

You can get the used MAC's output size from mac_entry_st (as
me->output_size).

> Changing DEFAULT_FAKE_SALT_SEED_SIZE means changing the size
> of the default (random) seed that is generated for each srp server
> credentials upon allocation (which is used unless the program provides
> its own seed using gnutls_srp_set_server_fake_salt_seed()).
> If this is changed for some reason, we would still allow for the
> application to request up to 20 byte long fake salts because the
> hmac output size would stay the same regardless.
> Want me to change it anyway, or introduce a new #define for this?

I believe that adding some comment describing that would be sufficient.

> On a related note, we could allow applications to request longer
> fake salts than the output size of the hmac if we wanted to by
> doing more hashing:
> _gnutls_mac(&ctx, "salt", 4);
> This constant part can be modified and the operation repeated
> to generate arbitrarily long fake salts.

Would there be any particular advantage on that? If not I think the best
would be to keep it simple.

regards,
Nikos