Rework needed for decoy digest generation

[markuskreusch]

The purpose of decoy digests is, according to draft 05 of the spec to avoid side channels through the number of claims in the SD-JWT.

The current implementation adds a minimum of 2 and maximum of 5 decoy digests. A random number of decoy digests in this range will be added to the SD-JWT when issued.

This mechanism does not sufficiently hide the information on the number of claims. Lets consider the following example:

Claims if user is a premium member:

{
  "name": "Markus",
  "premiumMembershipNumber": 1234
}

Claims if user is not a premium member:

{
  "name": "Markus"
}

In this case the number of claims (1 or 2) discloses the information if the holder is a premium member. We assume that the membership number is made selectively disclosable. Thus the resulting digest number for members will be 3 - 6 digests while 2 - 5 for non members. The presence of 2 or 6 digests discloses information about the membership.

Any digest number from 3 - 5 does not directly disclose information. It may happen though, that over time the holder sends several SD-JWTs all with the same data but different number of digests to a verifier. This can happen for privacy reasons to prevent correlation or over time after the SD-JWTs expire and are reissued. The verifier could then compute the average number of digests which will be 3.5 for non members and 4.5 for members.

A suitable mechanism to prevent this side channel is needed. The following should work: On each level of the claims the maximum number of claims must be known. The implementation should always add as many decoy digests that this maximum is reached. This way the number of digests visible to a third party will be always the same and no information is revealed.

[fabian-hk]

Thanks for pointing this out. I would treat this as a new feature. If this is important to you, please feel free to open a pull request.