search

ShivanKaul / star-spec

IETF Internet Draft for STAR
https://shivankaul.com/star-spec/draft-dss-star.html
Other
3 stars 1 forks source link

Corrupt reports #27

Open martinthomson opened 1 year ago

martinthomson commented 1 year ago

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.

ekr commented 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.

chris-wood commented 1 year ago

Agreed with the need for an algorithm that doesn't have exponential runtime.

ShivanKaul commented 1 year ago

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?