Naive secret sharing would allow for "jamming" on a non-physical level

[mariusfrinken]

While you suggest secret sharing to prevent an attacker from gathering EphIDs from a remote location or during short, close encounters, I think it should be considered that this allows for a method of "jamming" i.e. disturbing the exchange/broadcasting of EphIDs.

As described in #156 , all shares sent from A need to be linkable to A to compute the EphID.
In a naive setting, the packages would look like "MAC || share_i", where the MAC is obviously randomized at the beginning of every epoch.
What prevents an attacker, that successfully eavesdrops only one of these packages, to simply spoof the MAC and send multiple messages structured like this "MAC || bogus-share"?

To mitigate the issue, maybe verifiable secret sharing may work...

The issue is, the whitepaper argues that an attacker may not see enough (>= k) shares to successfully compute an EphID, but in such a naive setting, seeing one share may be enough to prevent someone from computing the correct EphID.

In the approaches without secret sharing, jamming can only happen on a physical level, if B does not get what A sends.
But with secret sharing, A sends s_0,s_1,s_2,s_3, ..., s_n and if C is allowed to implant s_e and B cannot distinguish, that is verifying a proof, whether s_e was sent from A or not, C has found a way to potentially jam the whole EphID exchange, resulting in B storing an incorrect EphID for A.

This form of jamming does not rely on physical jamming (i.e. sending a stronger signal on the same frequency) and appears to be rather hard to detect to me.