Anoma/Namada SSS Requirements

[kike]

@cwgoes

We haven’t investigated methods here much at all yet, but for example, I could imagine that general approaches may be similar to approaches for network-layer privacy – e.g. an onion-routed mixnet with additional tolerance for longer duration store-and-forward.

Not sure what exactly you have in mind, but the use of mixnets reminded me of the following idea to mitigate the impact of leaking FMD detection keys.

@kike

Making detection keys useless in the public shielded state pool \mathsf{BB}_0
This is blurry, but might be worth exploring. The idea is to use a mix layer before running through the detection layer.

• sender puts the flag ciphertext f_m in a ‘locked box’ in \mathsf{BB}_0
• unlock the boxes by passing \mathsf{BB}_0 through a mix-and-rencrypt layer. The output would be pool a \mathsf{BB}'_0 with all shielded states m_i locked in boxes (encrypted under receiver’s key), and all flag ciphertexts unboxed (decrypted) under the joint decryption key of the mix nodes
• pass \mathsf{BB}'_0 to the detection layer

The claim/goal is that at the detection layer, nodes can identify receiver’s private states using the unboxed flags, but do not know to which private states belong in \mathsf{BB}_0

Above, we may replace the entire pool of states with periodic batches, flag ciphertexts with actual user identities, and run the mixnet twice:

• In the output of the first run, user identities are revealed but states are encrypted under the mixnet joint public key.
• In the output of the second run, states for a given user are encrypted under the public key of the user.

The above may not meet the stated efficiency requirements, though. Also one may be reluctant to rely on mixnets for anonymity. (Just wanted to share.)