[dlc-dev] Security of Discreet Log Contract Attestation Schemes

[Lloyd Fournier]

Hey Nadav,

Thanks for the corrections! Will fix them shortly.

I think the only other aspect on the oracle side I wanted to touch on was:

- Punishable equivocation: Malicious oracle creating two conflicting
attestations should yield their secret key -- hint: This will rely on
collision resistance of H in Dryja's scheme but is unconditional in the
simplified scheme.

Of course, there is the security of the 2-tx adaptor signature protocol
itself on the user side which is pretty crucial to explore. I think the
idea we all have in our heads about that is correct though: If the
adversary claims funds with a CET the oracle didn't attest to then from
that we can extract the attestation scalar from adaptor signature. It is
then clear that we have forged an attestation the oracle didn't release and
contracted the unforgeability property.

LL

On Wed, Feb 3, 2021 at 8:45 AM Nadav Kohen <nadavk25 at gmail.com> wrote:

> Hi Lloyd,
>
> Thanks for doing this! It is really nice to have :)
>
> Before I leave my comments/review from having read the paper, I was
> curious if you could elaborate/enumerate what aspects of security may also
> be worth looking into? I agree that unforgeability is the most important
> but I'm drawing blanks when trying to think of other security properties.
>
> Now some mostly nit comments:
>
> * In definition 2, is it meant to be Pr[Forge = 1] \geq eps? (as opposed
> to \leq)
> * In definition 2 under Forge, I believe that n* is meant to be a* and
> under Att n_i is meant to be a_i?
> * Fig. 1's Attest and Verify also have n in place of a
> * "solves the OMDL problem *and* breaks collision resistance"
>     * Shouldn't this be *or*?
> * It might be nice, just as a reference for discussion, to write down a
> figure like figure 1 for your proposal at the bottom under (or above) your
> explanation of it and why it is secure by the same proof.
>
> Best,
> Nadav
>
> On Tue, Feb 2, 2021 at 12:14 AM Lloyd Fournier via dlc-dev <
> dlc-dev at mailmanlists.org> wrote:
>
>> Hi List,
>>
>> This week I've done some work on defining security for DLC oracles.
>> Please see: https://github.com/LLFourn/dlc-sec/blob/master/main.pdf
>>
>> The point I've touched on so far is "unforgeability" -- an adversary
>> cannot forge an oracle attestation without the secret key.
>> I guess it seemed obvious to everyone that the original scheme was secure
>> in this respect but a precise answer had never been given until now.
>> My result is interesting as it implies that we can show the scheme from
>> the original  paper secure in the plain model (not random oracle model) by
>> reduction from the *one-more* discrete logarithm problem. Or said another
>> way the security is more straightforward than Schnorr signatures
>> themselves. Another thing that becomes clear is that the security depends
>> on the collision resistance of the hash function (Schnorr doesn't normally
>> depend on this).
>>
>> The proof can easily be modified to work with the simplified scheme I
>> suggested here [1]. Apart from being more efficient the simplified scheme
>> does not rely on the collision resistance of a hash function since it
>> doesn't use a hash function.
>>
>> There are more aspects of DLC security to consider but I felt this was
>> the most important. The paper is very terse -- please let me know where you
>> think I should expand upon it.
>>
>> Cheers,
>>
>> LL
>>
>> [1] https://mailmanlists.org/pipermail/dlc-dev/2020-December/000002.html
>>
>>
>> dlc-dev mailing list
>> dlc-dev at mailmanlists.org
>> https://mailmanlists.org/mailman/listinfo/dlc-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/mailman/private/dlc-dev/attachments/20210203/f685dd28/attachment.htm>