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

Nadav Kohen nadavk25 at gmail.com
Tue Feb 2 23:42:06 CET 2021


Lloyd,

Ah gotchya. My personal thoughts are that the equivocation penalty is nice
to have but not actually as interesting as I originally thought as
unforgeabiltity is the key to getting fraud proofs and in many cases you
only have access to the sum of many attestations which restricts
equivocation leaking results.

On this topic, I think I agree with and follow your points on correctness,
but one thing I think would really be nice to have is a proof that our
attestation aggregation scheme works and isn't vulnerable to any rogue key
attacks, I think having this would put a lot of minds at ease :)

- Nadav

On Tue, Feb 2, 2021, 4:24 PM Lloyd Fournier <lloyd.fourn at gmail.com> wrote:

> 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/20210202/30dcc528/attachment.htm>


More information about the dlc-dev mailing list