Updates to encryption#56
Conversation
The biggest change is moving to add an indicator for the type of event (source or trigger).
| encode(key_id, 1), | ||
| encode(epoch, 2)) | ||
| encode(epoch, 2), | ||
| encode(event_type, 1)) |
There was a problem hiding this comment.
If we are sending an event_type here then do we still need secret shares of is_trigger_bit to be passed? Since now all helpers would know that in clear?
There was a problem hiding this comment.
That is absolutely right. The helper parties can share the is_trigger bit. No savings to be had from it being sparse though because we only single it at first
|
Curious about possible attack vectors if we don't authenticate with event type. It does not seem possible to misinterpret source event as trigger and vice versa, so there must be something more sophisticated |
|
@akoshelev , I think if we don't have the is_trigger bit in the associated data there isn't a good way to enforce that a source-fan-out query only contains source events from the site which is submitting the query, since if source/trigger bit were encrypted the source site submitting the query could include source events from other source sites disguised as trigger reports. See also discussion here. |
4 participants
The biggest change is moving to add an indicator for the type of event (source or trigger).
The rest is cleanup.