[tor-dev] Shared random value calculation edge cases (proposal 250)

[George Kadianakis]

s7r <s7r at sky-ip.org> writes:

> Hello,
>
> Saw the content of this section in master was corrected, yet the
> subtitle is little confusing:
>
> 4.1.6. Including the ed25519 shared randomness key in votes [SRKEY]
>
> From the content of this section I understand that we are going to
> include the ed25519 medium term signing key, certificate and master
> identity key. The content is clear, but maybe we should change the
> subtitle too, since there's no SR key:
>
> 4.1.6. Including the ed25519 medium term signing key and master
> identity key in votes [ED25519ID]
>

You are right. We need to fix this. Noted.

> Edge cases are the main reason I suggested in my previous emails to
> require at least 2 or 3 reveal rounds in order to allow a dirauth to
> participate in the shared randomness calculation for that day. However
> this won't help in case a dirauth needs to vote at 01:00 UTC and
> doesn't know anything.
>
> The idea of adding flags in the votes so each dirauth can advertise if
> it is participating (has an opinion for the <current> SR or not) is
> great and helps us build more defenses, probably make it easier in the
> future too if we decide to change anything.
>
> What if the consensus for SR calculation would define majority based
> on dirauths actually participating (and advertising so with a flag in
> the vote). Also, the participating or not participating flag should be
> used per vote/consensus and split into:
>
> a) we know current SR value for today so we vote it
> or
> we know previous SR value and we know for sure if we should follow the
> disaster protocol or not (in case we are about to vote at 01:00 UTC).
> so
> We participate in the vote for <current SR>.
>
> b) we are able to participate in this protocol run which will
> calculate the SR value for next day (after 00:00 UTC) so we send our
> commits/reveals.
>

I'm not sure exactly what you are suggesting here. That the participation flag
should not simply be 0 or 1, and that it should have more purposes?

> This is useful in case we are a dirauth that joined at 00:30 UTC and
> we couldn't get the _latest_ consensus (to find out if the 00:00 UTC
> consensus was created, and if not, previous SR value so we can follow
> the disaster procedure) we will not have an opinion for the <current>
> SR value at 01:00 UTC, but we can start participating in the protocol
> run for the next day - send our commit values. Once we decided on a
> <current> SR value for that day we save it and vote normally next time.
>
> So, if we have 5 dirauths running/signing consensus in total, out of
> which only 4 participate in the shared randomness protocol, the 4
> participating ones should be able to create a valid consensus
> themselves with the insurance that the 5th one won't break consensus.
>
> One way to do this is: the dirauth which is not participating will
> take the SR value voted by the majority of the participating dirauths
> and include that in its consensus and sign. We need at least 3
> dirauths agreeing on a SR value in order to accept it.
>
> Is this crazy? It shouldn't open the door new attacks, since this
> doesn't allow a single actor to game it, only the majority could game it.
>

Yes, that *could* be a way to do it. Have dirauths who don't know the
current/previous SRV get it from votes.

I think we all agree that dirauths who don't know the current/previous SRV
should get it from the previous consensus (even though this logic has not been
implemented yet). Getting it directly from the votes would be a different scheme
that maybe we should think about.