Hash algorithm that will be used in REST API setup

[alexchow94]

Hello,
What will be the HMAC algorithm used by coturn? Is there a way to specify/set this in the config?
For eg: If the client sends the password with HMAC sha-256, will coturn be able to understand or know to use the same algo to generate its own HMAC to compare and validate?

[alexchow94]

Sorry, re-opening this issue.
Still couldn't find the info on how coturn understand/know to use the same algo to generate its own HMAC for comparison and validate.
Kindly help.
Thanks.

[alexchow94]

Hello,
I found out coturn uses only HMAC-sha1, will there be support for >SHA256 in the near future?

[maksimu]

I'm also curious about this. We are striving to be compliant with NIST and SHA1 is no longer recommended by them see HERE and also we will probably need to use other algorithm for FIPS compliance.

[alexg-axis]

I'm gauging the work required to add support for SHA-256 for the "REST API". Currently, the hash algorithm to use is controlled by the same logic as the message integrity (which is controlled by a specification). I haven't found anything about the auth secret logic being controlled by a specification, so are we free to change how the algorithm is used?

coturn/src/apps/relay/userdb.c

Lines 532 to 571 in 412788b

	if (turn_params.use_auth_secret_with_timestamp) {
	turn_time_t ctime = (turn_time_t)time(NULL);
	turn_time_t ts = 0;
	secrets_list_t sl;
	size_t sll = 0;
	init_secrets_list(&sl);
	if (get_auth_secrets(&sl, realm) < 0) {
	return ret;
	}
	ts = get_rest_api_timestamp((char *)usname);
	if (!turn_time_before(ts, ctime)) {
	uint8_t hmac[MAXSHASIZE];
	unsigned int hmac_len;
	password_t pwdtmp;
	hmac[0] = 0;
	stun_attr_ref sar = stun_attr_get_first_by_type_str(
	ioa_network_buffer_data(nbh), ioa_network_buffer_get_size(nbh), STUN_ATTRIBUTE_MESSAGE_INTEGRITY);
	if (!sar) {
	return -1;
	}
	int sarlen = stun_attr_get_len(sar);
	switch (sarlen) {
	case SHA1SIZEBYTES:
	hmac_len = SHA1SIZEBYTES;
	break;
	case SHA256SIZEBYTES:
	case SHA384SIZEBYTES:
	case SHA512SIZEBYTES:
	default:
	return -1;
	};

If that's the case it should be quite easy to make it configurable and not rely on the STUN attribute (which will always be SHA-1 anyway). So it's a nice backward-compatible change to just default to SHA-1.

[alexg-axis]

I've opened a really quick and dirty PoC here (#1447). I'm pretty sure I'm missing something. But it does work in practice with the peers I tested with. So the question is more or less, will this break compatibility when changed or is the token/hmac just used by coturn and whatever produced the token in the first place?

[GiantKs]

I've opened a really quick and dirty PoC here (#1447). I'm pretty sure I'm missing something. But it does work in practice with the peers I tested with. So the question is more or less, will this break compatibility when changed or is the token/hmac just used by coturn and whatever produced the token in the first place?

ohh, let me know when it's available or if there's any progress...