Open boaks opened 3 years ago
This can be easily be done.
However, this raises other questions and highlights potential issues.
There needs to be consistency for keys and hints as well. I think keys consistency for TinyDTLS could be a challenge as it is limited to 16.
The underlying (D)TLS library requests the identity, key and hint as appropriate, but indicate a maximum size. If the maximum size is not sufficient, the code currently silently returns 0 as the length of the returned entity. What should happen to an entity if the (D)TLS library storage space is not sufficient?
There needs to be consistency for keys and hints as well.
Indeed.
I think keys consistency for TinyDTLS could be a challenge as it is limited to 16.
If I remember that well, this is more a common misinterpretation, which made it into tinydtls. It was an assumption that using aes128 causes the the PSK secret to be limited to 16 bytes as well. See tinydtls, crypto.h
#define DTLS_KEY_LENGTH 16 /* AES-128 */
/* This is the maximal supported length of the pre-shared key. */
#define DTLS_PSK_MAX_KEY_LEN DTLS_KEY_LENGTH
The AES keys are the output of PRF and there length is not related to the length of the secret. RFC4279 defines
Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely,
struct { opaque other_secret<0..2^16-1>; opaque psk<0..2^16-1>; };
as input of PRF for the premaster-secret, which indicates much larger possible secrets.
FMPOV, a definition in tinydtls guarded by #ifndef
for DTLS_PSK_MAX_KEY_LEN
would be a start to overcome this. On the other side, 16 bytes are anyway secure enough, considering, that the secret is too often not stored in a HSM.
libcoap: v4.3.0-rc4 (tinydtls binding):
MAX_USER
in coap-client.c limits the identity to 128 bytesDTLS_PSK_MAX_CLIENT_IDENTITY_LEN
is set to 32 bytes in crypto.h.I would prefer consistent lengths, e.g. by overwriting the default
DTLS_PSK_MAX_CLIENT_IDENTITY_LEN
using a definition in the makefile.