Open martinthomson opened 1 year ago
To recap my email at: https://mailarchive.ietf.org/arch/msg/ppm/mW_cY_BGNyamCRsYPoT5YAGROwk/
There are several kinds of bad reports, with the problematic one being a bogus secret share that causes the wrong key to be recovered. I believe this will be detectable because the legitimate ciphertexts will not be decryptable. However, then we need an algorithm for discarding the bogus share(s) that is more efficient than trying every possible subset of shares.
Agreed with the need for an algorithm that doesn't have exponential runtime.
Hi folks, we're using https://github.com/ShivanKaul/star-spec/issues/22 to track garbage reports (i.e. invalid ciphertext). I'm going to re-title this issue "corrupt reports", (i.e. invalid share), and we think verifiable secret sharing should address this kind of bad report.
How does that sound?
What measures, if any, does STAR have to protect itself from bad submissions from clients.
As far as I can tell, if a single client submits a bad report, your only chance of detecting it is if another client submits something at the same x-coordinate. Then you can just throw both out. But if k << n for secret sharing, the odds of that happening are very slim.
This seems like a very good way to attack a telemetry system and prevent any values from being collected at all.