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

[Attila Molnar]

On Wed, Feb 19 at 7:19 AM, "Nikos Mavrogiannopoulos" <nmav at gnutls.org> wrote:
>
>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.

Agree, I will address this in a new patch.

>>>> +	_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).

Makes sense, changed it. Also added a SRP_FAKE_SALT_MAC
macro which is defined as GNUTLS_MAC_SHA1 and changed
both places to use it.

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

Done.

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

Now programs are allowed to use long salts (e.g. 40 bytes)
in gnutls_srp_verifier() etc. If a program happens to use salts
longer than 20 bytes we won't generate credible fake salts -
all fake salts will be 20 bytes; the real salts are longer, making
it easy to differentiate between real and fake.

This case would be solved by not limiting the fake salt length 
to the output size of the hmac. Programs would be able to use
long real salts and get credible fake salts.
In other words, gnutls would be more consistent:
if programs are allowed to use 40 byte salts -> programs are
also able to request 40 byte fake salts.

Even though I do not see benefits in using salts that long, gnutls
allows them and having a consensus among functions is generally a
good thing.
I agree that the best thing for now is to keep it simple, but I wanted to
explain the "_gnutls_mac(&ctx, "salt", 4);" step anyway.

I will submit the revised patch later today after I get a chance to
test it with the changes applied.

Regards, Attila