Timing Issues

[Patrick Hayes]

The library, as it is currently implemented, leaks limited amounts of information about the message being hashed via timing side-channels.

Specifically, if an attacker has access to a timing side-channel and a rainbow table for the message/hash-function, each iteration of the FDH algorithm leaks the equivalent of one bit of information about the message.

This happens because, if the digest of the message is not within target domain, the FDH will perform additional iterations to find a digest within the target domain, leaking the information that the hash of the message is not within the target domain initially.

This can be fixed by hashing the message together with a random IV before performing the FDH.

[Konrad Komorowski]

Hey @phayes, some applications depend on the signature of a message being deterministic.

For example, Encrypted Bloom Filters mentioned in https://signal.org/blog/contact-discovery/ rely on both parties being able to construct the same signatures (directly, or using a blind signature scheme).

I understand that the proposed solution would make the signature generation process non-deterministic. Do you think it's possible to solve the timing attack in a deterministic way?

PS: This issue may or not may be a source of inspiration: briansmith/ring#264

[Patrick Hayes]

Hi @kkom,

Two things you could do here:

1. Use a static salt for each party - not super great since a rainbow table could still be constructed, but it might be acceptable depending on your specific use / application.

2. Use the experimental Moving Window Full Domain Hash, which should be constant-time, but is still experimental.