LocalIdProvider uses TOTP as salt


The current implementation of the LocalIdProvider uses a Timed OTP token as salt.
If, later, a decryption is done, a new TOTP token is generated.
This token is equivalent to the token used in the salt (i.e. verify( token(instant(encrypt)),token(instant(decrypt)) = true ).
However, since the totp-token is essentially a division operation on the timestamp, the verification considers the fact that the two tokens can differ a single timestep, and thus, two tokens differing in value can be similar enough to be valid.
However, as said, these tokens are used as salt, which leads to the possibility that two differing salts are used... and this then leads to failed decryption.

The correct usage would be to add the token to the message to be encrypted (thereby also salting it), and using a plain AES encryption on it. Upon decryption, a verification of the token can then verify that the time has not surpassed the desired stepsize.

Arguably it is also possible to just use a timestamp and compare that manually as that shows its intent just as clearly.


Jan Willem Janssen
December 5, 2017, 10:39 AM

Refactored the local ID provider to no longer use TOTPs as salt, but use a JWT + JWE combination instead.





Koos Gadellaa