Hello all

A draft of the Triptych preprint is complete! It's awaiting initial review from suraeNoether, and then off to the IACR preprint archive for broader review

Based on other discussions with suraeNoether about the CLSAG security model, we'll likely continue with its modifications in a way slightly different from the Backes et al. paper, to accommodate the inability to use a corruption oracle in the same way with DDH triples

Such is life

The definition that I think will work has the challenger supply a set of (DDH-supplied) keys to the player, has the player choose two such keys as "target keys", has the player supply the rest of the ring with arbitrary keys that could be maliciously generated, and continue from there

So it effectively replaces the corruption oracle (which doesn't work with the DDH setup) with the player's ability to include keys of its own construction

suraeNoether: in the updated definition, it seems the signing oracle also needs to be effectively removed

Previously, the LA player could query it on a non-target key in the ring

But if the challenger's key set is only DDH triples, do we want to remove this capability from the oracle, or just have the oracle proceed by backpatching?

So maybe "needs to be removed" should be replaced by "could be removed, depending on the model we wish to capture"

brief update on linkable anonymity

the Backes definition models the adversary's ability to corrupt keys, which models an adversary like a custodial exchange or an entity capable of persuading users to hand over their private keys. This is a very strong adversary, more strong than what we need...

we are modifying Backes' definition to model the adversary's ability to learn the key images associated with a given public key, rather than the secret key.

this models what happens when users hand over key images in the event of a subpoena or audit, but is allowed to keep their private keys; the auditors or legal system shouldn't gain an advantage in breaking the anonymity of other monero user's signatures

this way, the linkable anonymity solver reduces to an algorithm that plays the 1-more computational diffie-hellman game

our old proof attempted to reduce linkable anonymity to the vanilla version of decisional diffie-hellman, and that's not correct

Got it! The use of OMCDH allows for the use of such a linking tag oracle

which the master algorithm can use directly and pass to the LA player

Thereby avoiding the problem where the player's choice of target keys is important

Hmm, not sure this method works

It's not clear if the OMCDH player has enough information from the game to pass on to the LA player in order to set a key image for a simulated signature

With the OMDDH player, it made sense since the tuples received were already of the correct distribution to set ring members and key images

^ suraeNoether

If the OMDDH player can simulate a key image corruption oracle by simply returning the corresponding tuple point (which may or may not be the DDH point), and simulating corresponding signatures correctly, would that work?

If the signature simulation plays nicely with such an oracle, the LA player can see that it verifies correctly

and the same index identification method as for the old definition would tell the OMDDH player which bit to return to finish its game

suraeNoether: or what if there was no key image oracle, but the OMDDH player simply returned the list of all non-target-point DDH points (R_{i,3}) to the LA player?

Seems to simplify the game definition a bit