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

[Nadav Kohen]

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/687df633/attachment.htm>