Could Diffie-Hellman protocol serve as a zero-knowledge proof of knowledge of discrete logarithm?Schnorr Identification protocol sometimes wrong?Why is the definition of Special-honest verifier zero-knowledge probabilistic?How does the simulator of the special-honest verifier zero-knowledge property works?Schnorr protocol: how does malicious verifier win?ZK proof of “element in subgroup” protocolHow is the zero-knowledge proof definition violated, here?Schnorr identification protocol security proofSchnorr protocol - Proof or argument?Disjunction of several instances of sigma protocolHow to make the interactive Schnorr identification protocol become non-interactive

Multi tool use
Multi tool use

Is 'contemporary' ambiguous and if so is there a better word?

What happens if I accidentally leave an app running and click "Install Now" in Software Updater?

Determine if a grid contains another grid

Would a small hole in a Faraday cage drastically reduce its effectiveness at blocking interference?

What was the first story to feature the plot "the monsters were human all along"?

It isn’t that you must stop now

My large rocket is still flipping over

Is throwing dice a stochastic or a deterministic process?

Counting the Number of Real Roots of A Polynomial

All of my Firefox add-ons been disabled suddenly, how can I re-enable them?

All superlinear runtime algorithms are asymptotically equivalent to convex function?

How can a hefty sand storm happen in a thin atmosphere like Martian?

Is it normal for gliders not to have attitude indicators?

Which US defense organization would respond to an invasion like this?

weird pluperfect subjunctive in Eutropius

How do I allocate more memory to an app on Sheepshaver running Mac OS 9?

How can I get people to remember my character's gender?

Meaning of the (idiomatic?) expression "seghe mentali"

Has the United States ever had a non-Christian President?

Who filmed the Apollo 11 trans-lunar injection?

Dangerous workplace travelling

Has the Hulk always been able to talk?

Speed up this NIntegrate

How to display number in triangular pattern with plus sign



Could Diffie-Hellman protocol serve as a zero-knowledge proof of knowledge of discrete logarithm?


Schnorr Identification protocol sometimes wrong?Why is the definition of Special-honest verifier zero-knowledge probabilistic?How does the simulator of the special-honest verifier zero-knowledge property works?Schnorr protocol: how does malicious verifier win?ZK proof of “element in subgroup” protocolHow is the zero-knowledge proof definition violated, here?Schnorr identification protocol security proofSchnorr protocol - Proof or argument?Disjunction of several instances of sigma protocolHow to make the interactive Schnorr identification protocol become non-interactive













4












$begingroup$


The Schnorr identification protocol is widely recognized as the simplest ZKPoK of the discrete logarithm (more clearly, Honest-Verifier ZKPoK).



However, I can't figure out why this simple protocol, which is actually just a Diffie-Hellman key establishment protocol, is not an HVZKPoK also
(I understand that if it would be the case, I would see it everywhere in literature as an example of HVZKPoK).



Common input: generator $g$ of group $G$;



Prover's input: secret random $x$, and $y=g^x$;



Verifier's input: $y$;



Verifier is getting proof that the prover knows $x$ so that $y=g^x$ in 2-steps protocol:



  1. Verifier $V$ selects randomly $k$, and sends $v = g^k$ to the prover.

  2. Prover evaluates $r = v^x$ and sends it to the verifier.

  3. Verifier accepts iff $r = y^k$.

Completeness of this protocol is obvious.
Soundness is based on the assumption of hardness of Diffie-Hellman problem.



Honest-verifier zero-knowledgeness seems easy to show: in order to simulate correct transcripts, simulator just selects random $k$, and outputs $(g^k, y^k)$ as a valid transcript.



Could you point me to a mistake in my logic, or assert that this protocol is correct HVZKPoK (in the latter case, why it's not preferred than Schnorr one).










share|improve this question









$endgroup$











  • $begingroup$
    Not sure about the actual zero-knowledgeness and soundness, but there's one reason to prefer the standard Schnorr protocol: it's a standard $Sigma$-protocol, and can be easily transformed using Fiat-Shamir into something non-interactive.
    $endgroup$
    – Ruben De Smet
    Apr 26 at 14:57










  • $begingroup$
    @RubenDeSmet you're right, but it's probably not the crucial factor.
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:07















4












$begingroup$


The Schnorr identification protocol is widely recognized as the simplest ZKPoK of the discrete logarithm (more clearly, Honest-Verifier ZKPoK).



However, I can't figure out why this simple protocol, which is actually just a Diffie-Hellman key establishment protocol, is not an HVZKPoK also
(I understand that if it would be the case, I would see it everywhere in literature as an example of HVZKPoK).



Common input: generator $g$ of group $G$;



Prover's input: secret random $x$, and $y=g^x$;



Verifier's input: $y$;



Verifier is getting proof that the prover knows $x$ so that $y=g^x$ in 2-steps protocol:



  1. Verifier $V$ selects randomly $k$, and sends $v = g^k$ to the prover.

  2. Prover evaluates $r = v^x$ and sends it to the verifier.

  3. Verifier accepts iff $r = y^k$.

Completeness of this protocol is obvious.
Soundness is based on the assumption of hardness of Diffie-Hellman problem.



Honest-verifier zero-knowledgeness seems easy to show: in order to simulate correct transcripts, simulator just selects random $k$, and outputs $(g^k, y^k)$ as a valid transcript.



Could you point me to a mistake in my logic, or assert that this protocol is correct HVZKPoK (in the latter case, why it's not preferred than Schnorr one).










share|improve this question









$endgroup$











  • $begingroup$
    Not sure about the actual zero-knowledgeness and soundness, but there's one reason to prefer the standard Schnorr protocol: it's a standard $Sigma$-protocol, and can be easily transformed using Fiat-Shamir into something non-interactive.
    $endgroup$
    – Ruben De Smet
    Apr 26 at 14:57










  • $begingroup$
    @RubenDeSmet you're right, but it's probably not the crucial factor.
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:07













4












4








4


2



$begingroup$


The Schnorr identification protocol is widely recognized as the simplest ZKPoK of the discrete logarithm (more clearly, Honest-Verifier ZKPoK).



However, I can't figure out why this simple protocol, which is actually just a Diffie-Hellman key establishment protocol, is not an HVZKPoK also
(I understand that if it would be the case, I would see it everywhere in literature as an example of HVZKPoK).



Common input: generator $g$ of group $G$;



Prover's input: secret random $x$, and $y=g^x$;



Verifier's input: $y$;



Verifier is getting proof that the prover knows $x$ so that $y=g^x$ in 2-steps protocol:



  1. Verifier $V$ selects randomly $k$, and sends $v = g^k$ to the prover.

  2. Prover evaluates $r = v^x$ and sends it to the verifier.

  3. Verifier accepts iff $r = y^k$.

Completeness of this protocol is obvious.
Soundness is based on the assumption of hardness of Diffie-Hellman problem.



Honest-verifier zero-knowledgeness seems easy to show: in order to simulate correct transcripts, simulator just selects random $k$, and outputs $(g^k, y^k)$ as a valid transcript.



Could you point me to a mistake in my logic, or assert that this protocol is correct HVZKPoK (in the latter case, why it's not preferred than Schnorr one).










share|improve this question









$endgroup$




The Schnorr identification protocol is widely recognized as the simplest ZKPoK of the discrete logarithm (more clearly, Honest-Verifier ZKPoK).



However, I can't figure out why this simple protocol, which is actually just a Diffie-Hellman key establishment protocol, is not an HVZKPoK also
(I understand that if it would be the case, I would see it everywhere in literature as an example of HVZKPoK).



Common input: generator $g$ of group $G$;



Prover's input: secret random $x$, and $y=g^x$;



Verifier's input: $y$;



Verifier is getting proof that the prover knows $x$ so that $y=g^x$ in 2-steps protocol:



  1. Verifier $V$ selects randomly $k$, and sends $v = g^k$ to the prover.

  2. Prover evaluates $r = v^x$ and sends it to the verifier.

  3. Verifier accepts iff $r = y^k$.

Completeness of this protocol is obvious.
Soundness is based on the assumption of hardness of Diffie-Hellman problem.



Honest-verifier zero-knowledgeness seems easy to show: in order to simulate correct transcripts, simulator just selects random $k$, and outputs $(g^k, y^k)$ as a valid transcript.



Could you point me to a mistake in my logic, or assert that this protocol is correct HVZKPoK (in the latter case, why it's not preferred than Schnorr one).







diffie-hellman zero-knowledge-proofs discrete-logarithm schnorr-identification






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Apr 26 at 13:23









Mihas KoypishMihas Koypish

1895




1895











  • $begingroup$
    Not sure about the actual zero-knowledgeness and soundness, but there's one reason to prefer the standard Schnorr protocol: it's a standard $Sigma$-protocol, and can be easily transformed using Fiat-Shamir into something non-interactive.
    $endgroup$
    – Ruben De Smet
    Apr 26 at 14:57










  • $begingroup$
    @RubenDeSmet you're right, but it's probably not the crucial factor.
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:07
















  • $begingroup$
    Not sure about the actual zero-knowledgeness and soundness, but there's one reason to prefer the standard Schnorr protocol: it's a standard $Sigma$-protocol, and can be easily transformed using Fiat-Shamir into something non-interactive.
    $endgroup$
    – Ruben De Smet
    Apr 26 at 14:57










  • $begingroup$
    @RubenDeSmet you're right, but it's probably not the crucial factor.
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:07















$begingroup$
Not sure about the actual zero-knowledgeness and soundness, but there's one reason to prefer the standard Schnorr protocol: it's a standard $Sigma$-protocol, and can be easily transformed using Fiat-Shamir into something non-interactive.
$endgroup$
– Ruben De Smet
Apr 26 at 14:57




$begingroup$
Not sure about the actual zero-knowledgeness and soundness, but there's one reason to prefer the standard Schnorr protocol: it's a standard $Sigma$-protocol, and can be easily transformed using Fiat-Shamir into something non-interactive.
$endgroup$
– Ruben De Smet
Apr 26 at 14:57












$begingroup$
@RubenDeSmet you're right, but it's probably not the crucial factor.
$endgroup$
– Mihas Koypish
Apr 29 at 14:07




$begingroup$
@RubenDeSmet you're right, but it's probably not the crucial factor.
$endgroup$
– Mihas Koypish
Apr 29 at 14:07










1 Answer
1






active

oldest

votes


















9












$begingroup$

This is an interesting question. In fact, cryptographers have been using this exact protocol on many occasions, and there are two important reasons to prefer Schnorr over this protocol in most situations.



  1. The soundness of the protocol is not based on the Diffie-Hellman problem.

This is probably the most important point to address. What does it mean for this protocol to be sound? Informally, soundness can deal with two types of statements: you might want to prove membership in a language, or (this is stronger) you might want to prove knowledge of a witness. An example of the first statement could be "I claim that $(g,h,u,v)$ is a DDH-tuple", while an example of the second statement can be "I know the discrete logarithm of $y$ in base $g$".



Let's go back to your protocol now: you should be easily convinced that it cannot be expressed as a statement related to membership to some language: this would be a trivial statement (think "$y$ does have a discrete log in base $g$": if $g$ is a generator, this is always trivially true). What you truly care about is showing that the prover does know the discrete log of $y$ in base $g$. Formally, I know a witness is defined in cryptography as the witness can be efficiently learned from me, or more precisely: there exists a polynomial-time extractor that, given the code of the prover, can extract a valid witness from the code.



Now, how would you do that with your protocol? With Schnorr's protocol, it's fairly easy: given the code of the prover, run it to get the first flow $g^r$, then put a breakpoint, fork it, and run it twice on two different challenges $e,e'$ from the verifier. You get back two answers $d,d'$ which satisfy (with non-negligible probability) the verification equation: $y^ecdot g^r = g^d$ and $y^e'cdot g^r = g^d'$. From the two equations, you easily get $g^(d-d')cdot (e-e')^-1 = y$ (assuming you have a prime order group), hence you've just extracted the witness $x = (d-d')cdot (e-e')^-1$.



I would suggest that you spend a minute or two convincing yourself that there is no clear way to do the same thing with your protocol. Given the code of the prover, it is not clear at all how one would extract $x$.



But now, this is unsatisfying, right? Intuitively, it seems clear that the only way for the prover to answer correctly the challenge of the verifier in your protocol is by knowing $x$. This seems obvious, but we cannot prove it. This issue has been acknowledge long ago in the crypto community - it was first identified by Damgård in this paper, published in 1991. The best cryptographers could do was to formalize this belief in the form of an assumption, which is called the Knowledge-of-Exponent Assumption (KEA). This assumption states exactly that our intuition must be right: "for any polytime algorithm A that successfully replies (with good probability) with $y^k$ given as input $g^k$, there exists a polytime extractor that, given the code of A, outputs $x$ such that $g^x = y$."



Assumptions of this style are now widely used in cryptography - for example, very similar assumptions are at the core of SNARGs and SNARKs, which have gained a widespread attention due to their efficiency and their use in anonymous cryptocurrencies. Still, they are weird assumptions. For one thing, they are not even falsifiable: to break the factorization assumption, just give me a polytime algorithm that factors number, and I can easily check that it works. But for KEA, it's not even clear how one could verify that you have broken the assumption - this cannot just be an efficient algorithm, it has to be somehow an algorithm, together with a convincing argument that no extractor can exist for this algorithm.



Getting back to your protocol, then: it is believed to be sound, but only under the KEA assumption (tautologically). This is a weird and not well understood assumption. It does not even come close to being comparable to the Diffie-Hellman assumption, it's just a strange object in itself. In comparison, note that the soundness of Schnorr's protocol is just unconditional. Not based on a weird assumption, but also not even based on an assumption at all.



  1. The protocol is only HVZK, not ZK, and it is not clear how to make it ZK

Before moving on with this point, a quick digression: a simple modification of your protocol can be used to prove that a tuple is a DDH tuple (meaning: fix generators $(g,h)$, and now the prover wants to demonstrate that some pair $(u,v)$ is of the form $(g^x,h^x)$). Proving DDH relations is widely used in crypto. But unlike your protocol, we can now be happy with a membership proof: in most situations, it suffices to show that the witness $x$ exist (it's a non-trivial relation), no need to show that the prover knows it. So, suppose you modify your protocol as follows:



Verifier: send $g^k_1cdot h^k_2 = w$



Prover: answer with $z = w^x$



Verifier: check that $u^k_1cdot v^k_2 = z$



Then, interestingly, the previous issue disappears entirely: although it would still require KEA to prove that the prover must know $x$, it does not require any assumption at all to prove that $x$ exists, and this suffices to show that $(u,v)$ is a DDH tuple! In other words: in appropriate settings, for a slightly different language, a variant of your protocol does actually not have any problem with soundness anymore. So, why do we still not use it often?



This has to do with zero-knowledge. As you correctly pointed out, your protocol (and the variant above) satisfies honest-verifier zero-knowledge (as does Schnorr's protocol), meaning that it is zero-knowledge as long as the verifier is honest.



Sure, but why do we even care about HVZK? In practice, we are not really happy with something being secure only when the opponent is honest, right? The answer is that what we truly care about is indeed full-fledged ZK, but HVZK is often a good first step: we know very general and very efficient transformations that can convert a large class of HVZK protocols into full-fledged ZK protocol. Hence, we can just build HVZK protocols, prove that they satisfy this property, and they can be compiled into real ZK protocols when needed.



What is this large class of HVZK protocols that we can transform efficiently into ZK protocols? They are the so-called public coin protocols: all protocols in which all the randomness used by the verifier is fully revealed to the prover. Take one minute to convince yourself that this property is satisfied by Schnorr's protocol (and by essentially any HVZK protocol in the literature, up to a few exceptions), but not by your protocol. This means that even though your protocol is HVZK, this does not suffice to make it ZK through general techniques!



Of course, there are known methods that can transform your protocol into a ZK protocol, introducing additional rounds and complexity. But then, they end up loosing any clear advantage over Schnorr's protocol in terms of efficiency... So we usually simply stick to Schnorr and its variants :)






share|improve this answer









$endgroup$












  • $begingroup$
    Thanks for your extended answer! Got your reasoning regarding difficulties with soundness property. Could you also provide me with links to generic converting of public coin HVZK to full ZK? Also, it would be especially cool if you point me how to transform my DH protocol to ZK, even with additional rounds?
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:04










  • $begingroup$
    The usual references for that are Jens Groth's thesis, and this paper. Regarding your protocol, a standard approach is to use an "OR trick": prove, with a variant of your protocol, that either your statement hold (e.g. you know a discrete log), OR a given tuple is a DDH tuple. Then make this DDH tuple a CRS, where in the real world no one knows the corresponding witness (hence the statement actually proven is the one you want), but the simulator in the ZK game has the witness.
    $endgroup$
    – Geoffroy Couteau
    Apr 29 at 14:27












Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f70074%2fcould-diffie-hellman-protocol-serve-as-a-zero-knowledge-proof-of-knowledge-of-di%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









9












$begingroup$

This is an interesting question. In fact, cryptographers have been using this exact protocol on many occasions, and there are two important reasons to prefer Schnorr over this protocol in most situations.



  1. The soundness of the protocol is not based on the Diffie-Hellman problem.

This is probably the most important point to address. What does it mean for this protocol to be sound? Informally, soundness can deal with two types of statements: you might want to prove membership in a language, or (this is stronger) you might want to prove knowledge of a witness. An example of the first statement could be "I claim that $(g,h,u,v)$ is a DDH-tuple", while an example of the second statement can be "I know the discrete logarithm of $y$ in base $g$".



Let's go back to your protocol now: you should be easily convinced that it cannot be expressed as a statement related to membership to some language: this would be a trivial statement (think "$y$ does have a discrete log in base $g$": if $g$ is a generator, this is always trivially true). What you truly care about is showing that the prover does know the discrete log of $y$ in base $g$. Formally, I know a witness is defined in cryptography as the witness can be efficiently learned from me, or more precisely: there exists a polynomial-time extractor that, given the code of the prover, can extract a valid witness from the code.



Now, how would you do that with your protocol? With Schnorr's protocol, it's fairly easy: given the code of the prover, run it to get the first flow $g^r$, then put a breakpoint, fork it, and run it twice on two different challenges $e,e'$ from the verifier. You get back two answers $d,d'$ which satisfy (with non-negligible probability) the verification equation: $y^ecdot g^r = g^d$ and $y^e'cdot g^r = g^d'$. From the two equations, you easily get $g^(d-d')cdot (e-e')^-1 = y$ (assuming you have a prime order group), hence you've just extracted the witness $x = (d-d')cdot (e-e')^-1$.



I would suggest that you spend a minute or two convincing yourself that there is no clear way to do the same thing with your protocol. Given the code of the prover, it is not clear at all how one would extract $x$.



But now, this is unsatisfying, right? Intuitively, it seems clear that the only way for the prover to answer correctly the challenge of the verifier in your protocol is by knowing $x$. This seems obvious, but we cannot prove it. This issue has been acknowledge long ago in the crypto community - it was first identified by Damgård in this paper, published in 1991. The best cryptographers could do was to formalize this belief in the form of an assumption, which is called the Knowledge-of-Exponent Assumption (KEA). This assumption states exactly that our intuition must be right: "for any polytime algorithm A that successfully replies (with good probability) with $y^k$ given as input $g^k$, there exists a polytime extractor that, given the code of A, outputs $x$ such that $g^x = y$."



Assumptions of this style are now widely used in cryptography - for example, very similar assumptions are at the core of SNARGs and SNARKs, which have gained a widespread attention due to their efficiency and their use in anonymous cryptocurrencies. Still, they are weird assumptions. For one thing, they are not even falsifiable: to break the factorization assumption, just give me a polytime algorithm that factors number, and I can easily check that it works. But for KEA, it's not even clear how one could verify that you have broken the assumption - this cannot just be an efficient algorithm, it has to be somehow an algorithm, together with a convincing argument that no extractor can exist for this algorithm.



Getting back to your protocol, then: it is believed to be sound, but only under the KEA assumption (tautologically). This is a weird and not well understood assumption. It does not even come close to being comparable to the Diffie-Hellman assumption, it's just a strange object in itself. In comparison, note that the soundness of Schnorr's protocol is just unconditional. Not based on a weird assumption, but also not even based on an assumption at all.



  1. The protocol is only HVZK, not ZK, and it is not clear how to make it ZK

Before moving on with this point, a quick digression: a simple modification of your protocol can be used to prove that a tuple is a DDH tuple (meaning: fix generators $(g,h)$, and now the prover wants to demonstrate that some pair $(u,v)$ is of the form $(g^x,h^x)$). Proving DDH relations is widely used in crypto. But unlike your protocol, we can now be happy with a membership proof: in most situations, it suffices to show that the witness $x$ exist (it's a non-trivial relation), no need to show that the prover knows it. So, suppose you modify your protocol as follows:



Verifier: send $g^k_1cdot h^k_2 = w$



Prover: answer with $z = w^x$



Verifier: check that $u^k_1cdot v^k_2 = z$



Then, interestingly, the previous issue disappears entirely: although it would still require KEA to prove that the prover must know $x$, it does not require any assumption at all to prove that $x$ exists, and this suffices to show that $(u,v)$ is a DDH tuple! In other words: in appropriate settings, for a slightly different language, a variant of your protocol does actually not have any problem with soundness anymore. So, why do we still not use it often?



This has to do with zero-knowledge. As you correctly pointed out, your protocol (and the variant above) satisfies honest-verifier zero-knowledge (as does Schnorr's protocol), meaning that it is zero-knowledge as long as the verifier is honest.



Sure, but why do we even care about HVZK? In practice, we are not really happy with something being secure only when the opponent is honest, right? The answer is that what we truly care about is indeed full-fledged ZK, but HVZK is often a good first step: we know very general and very efficient transformations that can convert a large class of HVZK protocols into full-fledged ZK protocol. Hence, we can just build HVZK protocols, prove that they satisfy this property, and they can be compiled into real ZK protocols when needed.



What is this large class of HVZK protocols that we can transform efficiently into ZK protocols? They are the so-called public coin protocols: all protocols in which all the randomness used by the verifier is fully revealed to the prover. Take one minute to convince yourself that this property is satisfied by Schnorr's protocol (and by essentially any HVZK protocol in the literature, up to a few exceptions), but not by your protocol. This means that even though your protocol is HVZK, this does not suffice to make it ZK through general techniques!



Of course, there are known methods that can transform your protocol into a ZK protocol, introducing additional rounds and complexity. But then, they end up loosing any clear advantage over Schnorr's protocol in terms of efficiency... So we usually simply stick to Schnorr and its variants :)






share|improve this answer









$endgroup$












  • $begingroup$
    Thanks for your extended answer! Got your reasoning regarding difficulties with soundness property. Could you also provide me with links to generic converting of public coin HVZK to full ZK? Also, it would be especially cool if you point me how to transform my DH protocol to ZK, even with additional rounds?
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:04










  • $begingroup$
    The usual references for that are Jens Groth's thesis, and this paper. Regarding your protocol, a standard approach is to use an "OR trick": prove, with a variant of your protocol, that either your statement hold (e.g. you know a discrete log), OR a given tuple is a DDH tuple. Then make this DDH tuple a CRS, where in the real world no one knows the corresponding witness (hence the statement actually proven is the one you want), but the simulator in the ZK game has the witness.
    $endgroup$
    – Geoffroy Couteau
    Apr 29 at 14:27
















9












$begingroup$

This is an interesting question. In fact, cryptographers have been using this exact protocol on many occasions, and there are two important reasons to prefer Schnorr over this protocol in most situations.



  1. The soundness of the protocol is not based on the Diffie-Hellman problem.

This is probably the most important point to address. What does it mean for this protocol to be sound? Informally, soundness can deal with two types of statements: you might want to prove membership in a language, or (this is stronger) you might want to prove knowledge of a witness. An example of the first statement could be "I claim that $(g,h,u,v)$ is a DDH-tuple", while an example of the second statement can be "I know the discrete logarithm of $y$ in base $g$".



Let's go back to your protocol now: you should be easily convinced that it cannot be expressed as a statement related to membership to some language: this would be a trivial statement (think "$y$ does have a discrete log in base $g$": if $g$ is a generator, this is always trivially true). What you truly care about is showing that the prover does know the discrete log of $y$ in base $g$. Formally, I know a witness is defined in cryptography as the witness can be efficiently learned from me, or more precisely: there exists a polynomial-time extractor that, given the code of the prover, can extract a valid witness from the code.



Now, how would you do that with your protocol? With Schnorr's protocol, it's fairly easy: given the code of the prover, run it to get the first flow $g^r$, then put a breakpoint, fork it, and run it twice on two different challenges $e,e'$ from the verifier. You get back two answers $d,d'$ which satisfy (with non-negligible probability) the verification equation: $y^ecdot g^r = g^d$ and $y^e'cdot g^r = g^d'$. From the two equations, you easily get $g^(d-d')cdot (e-e')^-1 = y$ (assuming you have a prime order group), hence you've just extracted the witness $x = (d-d')cdot (e-e')^-1$.



I would suggest that you spend a minute or two convincing yourself that there is no clear way to do the same thing with your protocol. Given the code of the prover, it is not clear at all how one would extract $x$.



But now, this is unsatisfying, right? Intuitively, it seems clear that the only way for the prover to answer correctly the challenge of the verifier in your protocol is by knowing $x$. This seems obvious, but we cannot prove it. This issue has been acknowledge long ago in the crypto community - it was first identified by Damgård in this paper, published in 1991. The best cryptographers could do was to formalize this belief in the form of an assumption, which is called the Knowledge-of-Exponent Assumption (KEA). This assumption states exactly that our intuition must be right: "for any polytime algorithm A that successfully replies (with good probability) with $y^k$ given as input $g^k$, there exists a polytime extractor that, given the code of A, outputs $x$ such that $g^x = y$."



Assumptions of this style are now widely used in cryptography - for example, very similar assumptions are at the core of SNARGs and SNARKs, which have gained a widespread attention due to their efficiency and their use in anonymous cryptocurrencies. Still, they are weird assumptions. For one thing, they are not even falsifiable: to break the factorization assumption, just give me a polytime algorithm that factors number, and I can easily check that it works. But for KEA, it's not even clear how one could verify that you have broken the assumption - this cannot just be an efficient algorithm, it has to be somehow an algorithm, together with a convincing argument that no extractor can exist for this algorithm.



Getting back to your protocol, then: it is believed to be sound, but only under the KEA assumption (tautologically). This is a weird and not well understood assumption. It does not even come close to being comparable to the Diffie-Hellman assumption, it's just a strange object in itself. In comparison, note that the soundness of Schnorr's protocol is just unconditional. Not based on a weird assumption, but also not even based on an assumption at all.



  1. The protocol is only HVZK, not ZK, and it is not clear how to make it ZK

Before moving on with this point, a quick digression: a simple modification of your protocol can be used to prove that a tuple is a DDH tuple (meaning: fix generators $(g,h)$, and now the prover wants to demonstrate that some pair $(u,v)$ is of the form $(g^x,h^x)$). Proving DDH relations is widely used in crypto. But unlike your protocol, we can now be happy with a membership proof: in most situations, it suffices to show that the witness $x$ exist (it's a non-trivial relation), no need to show that the prover knows it. So, suppose you modify your protocol as follows:



Verifier: send $g^k_1cdot h^k_2 = w$



Prover: answer with $z = w^x$



Verifier: check that $u^k_1cdot v^k_2 = z$



Then, interestingly, the previous issue disappears entirely: although it would still require KEA to prove that the prover must know $x$, it does not require any assumption at all to prove that $x$ exists, and this suffices to show that $(u,v)$ is a DDH tuple! In other words: in appropriate settings, for a slightly different language, a variant of your protocol does actually not have any problem with soundness anymore. So, why do we still not use it often?



This has to do with zero-knowledge. As you correctly pointed out, your protocol (and the variant above) satisfies honest-verifier zero-knowledge (as does Schnorr's protocol), meaning that it is zero-knowledge as long as the verifier is honest.



Sure, but why do we even care about HVZK? In practice, we are not really happy with something being secure only when the opponent is honest, right? The answer is that what we truly care about is indeed full-fledged ZK, but HVZK is often a good first step: we know very general and very efficient transformations that can convert a large class of HVZK protocols into full-fledged ZK protocol. Hence, we can just build HVZK protocols, prove that they satisfy this property, and they can be compiled into real ZK protocols when needed.



What is this large class of HVZK protocols that we can transform efficiently into ZK protocols? They are the so-called public coin protocols: all protocols in which all the randomness used by the verifier is fully revealed to the prover. Take one minute to convince yourself that this property is satisfied by Schnorr's protocol (and by essentially any HVZK protocol in the literature, up to a few exceptions), but not by your protocol. This means that even though your protocol is HVZK, this does not suffice to make it ZK through general techniques!



Of course, there are known methods that can transform your protocol into a ZK protocol, introducing additional rounds and complexity. But then, they end up loosing any clear advantage over Schnorr's protocol in terms of efficiency... So we usually simply stick to Schnorr and its variants :)






share|improve this answer









$endgroup$












  • $begingroup$
    Thanks for your extended answer! Got your reasoning regarding difficulties with soundness property. Could you also provide me with links to generic converting of public coin HVZK to full ZK? Also, it would be especially cool if you point me how to transform my DH protocol to ZK, even with additional rounds?
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:04










  • $begingroup$
    The usual references for that are Jens Groth's thesis, and this paper. Regarding your protocol, a standard approach is to use an "OR trick": prove, with a variant of your protocol, that either your statement hold (e.g. you know a discrete log), OR a given tuple is a DDH tuple. Then make this DDH tuple a CRS, where in the real world no one knows the corresponding witness (hence the statement actually proven is the one you want), but the simulator in the ZK game has the witness.
    $endgroup$
    – Geoffroy Couteau
    Apr 29 at 14:27














9












9








9





$begingroup$

This is an interesting question. In fact, cryptographers have been using this exact protocol on many occasions, and there are two important reasons to prefer Schnorr over this protocol in most situations.



  1. The soundness of the protocol is not based on the Diffie-Hellman problem.

This is probably the most important point to address. What does it mean for this protocol to be sound? Informally, soundness can deal with two types of statements: you might want to prove membership in a language, or (this is stronger) you might want to prove knowledge of a witness. An example of the first statement could be "I claim that $(g,h,u,v)$ is a DDH-tuple", while an example of the second statement can be "I know the discrete logarithm of $y$ in base $g$".



Let's go back to your protocol now: you should be easily convinced that it cannot be expressed as a statement related to membership to some language: this would be a trivial statement (think "$y$ does have a discrete log in base $g$": if $g$ is a generator, this is always trivially true). What you truly care about is showing that the prover does know the discrete log of $y$ in base $g$. Formally, I know a witness is defined in cryptography as the witness can be efficiently learned from me, or more precisely: there exists a polynomial-time extractor that, given the code of the prover, can extract a valid witness from the code.



Now, how would you do that with your protocol? With Schnorr's protocol, it's fairly easy: given the code of the prover, run it to get the first flow $g^r$, then put a breakpoint, fork it, and run it twice on two different challenges $e,e'$ from the verifier. You get back two answers $d,d'$ which satisfy (with non-negligible probability) the verification equation: $y^ecdot g^r = g^d$ and $y^e'cdot g^r = g^d'$. From the two equations, you easily get $g^(d-d')cdot (e-e')^-1 = y$ (assuming you have a prime order group), hence you've just extracted the witness $x = (d-d')cdot (e-e')^-1$.



I would suggest that you spend a minute or two convincing yourself that there is no clear way to do the same thing with your protocol. Given the code of the prover, it is not clear at all how one would extract $x$.



But now, this is unsatisfying, right? Intuitively, it seems clear that the only way for the prover to answer correctly the challenge of the verifier in your protocol is by knowing $x$. This seems obvious, but we cannot prove it. This issue has been acknowledge long ago in the crypto community - it was first identified by Damgård in this paper, published in 1991. The best cryptographers could do was to formalize this belief in the form of an assumption, which is called the Knowledge-of-Exponent Assumption (KEA). This assumption states exactly that our intuition must be right: "for any polytime algorithm A that successfully replies (with good probability) with $y^k$ given as input $g^k$, there exists a polytime extractor that, given the code of A, outputs $x$ such that $g^x = y$."



Assumptions of this style are now widely used in cryptography - for example, very similar assumptions are at the core of SNARGs and SNARKs, which have gained a widespread attention due to their efficiency and their use in anonymous cryptocurrencies. Still, they are weird assumptions. For one thing, they are not even falsifiable: to break the factorization assumption, just give me a polytime algorithm that factors number, and I can easily check that it works. But for KEA, it's not even clear how one could verify that you have broken the assumption - this cannot just be an efficient algorithm, it has to be somehow an algorithm, together with a convincing argument that no extractor can exist for this algorithm.



Getting back to your protocol, then: it is believed to be sound, but only under the KEA assumption (tautologically). This is a weird and not well understood assumption. It does not even come close to being comparable to the Diffie-Hellman assumption, it's just a strange object in itself. In comparison, note that the soundness of Schnorr's protocol is just unconditional. Not based on a weird assumption, but also not even based on an assumption at all.



  1. The protocol is only HVZK, not ZK, and it is not clear how to make it ZK

Before moving on with this point, a quick digression: a simple modification of your protocol can be used to prove that a tuple is a DDH tuple (meaning: fix generators $(g,h)$, and now the prover wants to demonstrate that some pair $(u,v)$ is of the form $(g^x,h^x)$). Proving DDH relations is widely used in crypto. But unlike your protocol, we can now be happy with a membership proof: in most situations, it suffices to show that the witness $x$ exist (it's a non-trivial relation), no need to show that the prover knows it. So, suppose you modify your protocol as follows:



Verifier: send $g^k_1cdot h^k_2 = w$



Prover: answer with $z = w^x$



Verifier: check that $u^k_1cdot v^k_2 = z$



Then, interestingly, the previous issue disappears entirely: although it would still require KEA to prove that the prover must know $x$, it does not require any assumption at all to prove that $x$ exists, and this suffices to show that $(u,v)$ is a DDH tuple! In other words: in appropriate settings, for a slightly different language, a variant of your protocol does actually not have any problem with soundness anymore. So, why do we still not use it often?



This has to do with zero-knowledge. As you correctly pointed out, your protocol (and the variant above) satisfies honest-verifier zero-knowledge (as does Schnorr's protocol), meaning that it is zero-knowledge as long as the verifier is honest.



Sure, but why do we even care about HVZK? In practice, we are not really happy with something being secure only when the opponent is honest, right? The answer is that what we truly care about is indeed full-fledged ZK, but HVZK is often a good first step: we know very general and very efficient transformations that can convert a large class of HVZK protocols into full-fledged ZK protocol. Hence, we can just build HVZK protocols, prove that they satisfy this property, and they can be compiled into real ZK protocols when needed.



What is this large class of HVZK protocols that we can transform efficiently into ZK protocols? They are the so-called public coin protocols: all protocols in which all the randomness used by the verifier is fully revealed to the prover. Take one minute to convince yourself that this property is satisfied by Schnorr's protocol (and by essentially any HVZK protocol in the literature, up to a few exceptions), but not by your protocol. This means that even though your protocol is HVZK, this does not suffice to make it ZK through general techniques!



Of course, there are known methods that can transform your protocol into a ZK protocol, introducing additional rounds and complexity. But then, they end up loosing any clear advantage over Schnorr's protocol in terms of efficiency... So we usually simply stick to Schnorr and its variants :)






share|improve this answer









$endgroup$



This is an interesting question. In fact, cryptographers have been using this exact protocol on many occasions, and there are two important reasons to prefer Schnorr over this protocol in most situations.



  1. The soundness of the protocol is not based on the Diffie-Hellman problem.

This is probably the most important point to address. What does it mean for this protocol to be sound? Informally, soundness can deal with two types of statements: you might want to prove membership in a language, or (this is stronger) you might want to prove knowledge of a witness. An example of the first statement could be "I claim that $(g,h,u,v)$ is a DDH-tuple", while an example of the second statement can be "I know the discrete logarithm of $y$ in base $g$".



Let's go back to your protocol now: you should be easily convinced that it cannot be expressed as a statement related to membership to some language: this would be a trivial statement (think "$y$ does have a discrete log in base $g$": if $g$ is a generator, this is always trivially true). What you truly care about is showing that the prover does know the discrete log of $y$ in base $g$. Formally, I know a witness is defined in cryptography as the witness can be efficiently learned from me, or more precisely: there exists a polynomial-time extractor that, given the code of the prover, can extract a valid witness from the code.



Now, how would you do that with your protocol? With Schnorr's protocol, it's fairly easy: given the code of the prover, run it to get the first flow $g^r$, then put a breakpoint, fork it, and run it twice on two different challenges $e,e'$ from the verifier. You get back two answers $d,d'$ which satisfy (with non-negligible probability) the verification equation: $y^ecdot g^r = g^d$ and $y^e'cdot g^r = g^d'$. From the two equations, you easily get $g^(d-d')cdot (e-e')^-1 = y$ (assuming you have a prime order group), hence you've just extracted the witness $x = (d-d')cdot (e-e')^-1$.



I would suggest that you spend a minute or two convincing yourself that there is no clear way to do the same thing with your protocol. Given the code of the prover, it is not clear at all how one would extract $x$.



But now, this is unsatisfying, right? Intuitively, it seems clear that the only way for the prover to answer correctly the challenge of the verifier in your protocol is by knowing $x$. This seems obvious, but we cannot prove it. This issue has been acknowledge long ago in the crypto community - it was first identified by Damgård in this paper, published in 1991. The best cryptographers could do was to formalize this belief in the form of an assumption, which is called the Knowledge-of-Exponent Assumption (KEA). This assumption states exactly that our intuition must be right: "for any polytime algorithm A that successfully replies (with good probability) with $y^k$ given as input $g^k$, there exists a polytime extractor that, given the code of A, outputs $x$ such that $g^x = y$."



Assumptions of this style are now widely used in cryptography - for example, very similar assumptions are at the core of SNARGs and SNARKs, which have gained a widespread attention due to their efficiency and their use in anonymous cryptocurrencies. Still, they are weird assumptions. For one thing, they are not even falsifiable: to break the factorization assumption, just give me a polytime algorithm that factors number, and I can easily check that it works. But for KEA, it's not even clear how one could verify that you have broken the assumption - this cannot just be an efficient algorithm, it has to be somehow an algorithm, together with a convincing argument that no extractor can exist for this algorithm.



Getting back to your protocol, then: it is believed to be sound, but only under the KEA assumption (tautologically). This is a weird and not well understood assumption. It does not even come close to being comparable to the Diffie-Hellman assumption, it's just a strange object in itself. In comparison, note that the soundness of Schnorr's protocol is just unconditional. Not based on a weird assumption, but also not even based on an assumption at all.



  1. The protocol is only HVZK, not ZK, and it is not clear how to make it ZK

Before moving on with this point, a quick digression: a simple modification of your protocol can be used to prove that a tuple is a DDH tuple (meaning: fix generators $(g,h)$, and now the prover wants to demonstrate that some pair $(u,v)$ is of the form $(g^x,h^x)$). Proving DDH relations is widely used in crypto. But unlike your protocol, we can now be happy with a membership proof: in most situations, it suffices to show that the witness $x$ exist (it's a non-trivial relation), no need to show that the prover knows it. So, suppose you modify your protocol as follows:



Verifier: send $g^k_1cdot h^k_2 = w$



Prover: answer with $z = w^x$



Verifier: check that $u^k_1cdot v^k_2 = z$



Then, interestingly, the previous issue disappears entirely: although it would still require KEA to prove that the prover must know $x$, it does not require any assumption at all to prove that $x$ exists, and this suffices to show that $(u,v)$ is a DDH tuple! In other words: in appropriate settings, for a slightly different language, a variant of your protocol does actually not have any problem with soundness anymore. So, why do we still not use it often?



This has to do with zero-knowledge. As you correctly pointed out, your protocol (and the variant above) satisfies honest-verifier zero-knowledge (as does Schnorr's protocol), meaning that it is zero-knowledge as long as the verifier is honest.



Sure, but why do we even care about HVZK? In practice, we are not really happy with something being secure only when the opponent is honest, right? The answer is that what we truly care about is indeed full-fledged ZK, but HVZK is often a good first step: we know very general and very efficient transformations that can convert a large class of HVZK protocols into full-fledged ZK protocol. Hence, we can just build HVZK protocols, prove that they satisfy this property, and they can be compiled into real ZK protocols when needed.



What is this large class of HVZK protocols that we can transform efficiently into ZK protocols? They are the so-called public coin protocols: all protocols in which all the randomness used by the verifier is fully revealed to the prover. Take one minute to convince yourself that this property is satisfied by Schnorr's protocol (and by essentially any HVZK protocol in the literature, up to a few exceptions), but not by your protocol. This means that even though your protocol is HVZK, this does not suffice to make it ZK through general techniques!



Of course, there are known methods that can transform your protocol into a ZK protocol, introducing additional rounds and complexity. But then, they end up loosing any clear advantage over Schnorr's protocol in terms of efficiency... So we usually simply stick to Schnorr and its variants :)







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 26 at 18:25









Geoffroy CouteauGeoffroy Couteau

9,44011835




9,44011835











  • $begingroup$
    Thanks for your extended answer! Got your reasoning regarding difficulties with soundness property. Could you also provide me with links to generic converting of public coin HVZK to full ZK? Also, it would be especially cool if you point me how to transform my DH protocol to ZK, even with additional rounds?
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:04










  • $begingroup$
    The usual references for that are Jens Groth's thesis, and this paper. Regarding your protocol, a standard approach is to use an "OR trick": prove, with a variant of your protocol, that either your statement hold (e.g. you know a discrete log), OR a given tuple is a DDH tuple. Then make this DDH tuple a CRS, where in the real world no one knows the corresponding witness (hence the statement actually proven is the one you want), but the simulator in the ZK game has the witness.
    $endgroup$
    – Geoffroy Couteau
    Apr 29 at 14:27

















  • $begingroup$
    Thanks for your extended answer! Got your reasoning regarding difficulties with soundness property. Could you also provide me with links to generic converting of public coin HVZK to full ZK? Also, it would be especially cool if you point me how to transform my DH protocol to ZK, even with additional rounds?
    $endgroup$
    – Mihas Koypish
    Apr 29 at 14:04










  • $begingroup$
    The usual references for that are Jens Groth's thesis, and this paper. Regarding your protocol, a standard approach is to use an "OR trick": prove, with a variant of your protocol, that either your statement hold (e.g. you know a discrete log), OR a given tuple is a DDH tuple. Then make this DDH tuple a CRS, where in the real world no one knows the corresponding witness (hence the statement actually proven is the one you want), but the simulator in the ZK game has the witness.
    $endgroup$
    – Geoffroy Couteau
    Apr 29 at 14:27
















$begingroup$
Thanks for your extended answer! Got your reasoning regarding difficulties with soundness property. Could you also provide me with links to generic converting of public coin HVZK to full ZK? Also, it would be especially cool if you point me how to transform my DH protocol to ZK, even with additional rounds?
$endgroup$
– Mihas Koypish
Apr 29 at 14:04




$begingroup$
Thanks for your extended answer! Got your reasoning regarding difficulties with soundness property. Could you also provide me with links to generic converting of public coin HVZK to full ZK? Also, it would be especially cool if you point me how to transform my DH protocol to ZK, even with additional rounds?
$endgroup$
– Mihas Koypish
Apr 29 at 14:04












$begingroup$
The usual references for that are Jens Groth's thesis, and this paper. Regarding your protocol, a standard approach is to use an "OR trick": prove, with a variant of your protocol, that either your statement hold (e.g. you know a discrete log), OR a given tuple is a DDH tuple. Then make this DDH tuple a CRS, where in the real world no one knows the corresponding witness (hence the statement actually proven is the one you want), but the simulator in the ZK game has the witness.
$endgroup$
– Geoffroy Couteau
Apr 29 at 14:27





$begingroup$
The usual references for that are Jens Groth's thesis, and this paper. Regarding your protocol, a standard approach is to use an "OR trick": prove, with a variant of your protocol, that either your statement hold (e.g. you know a discrete log), OR a given tuple is a DDH tuple. Then make this DDH tuple a CRS, where in the real world no one knows the corresponding witness (hence the statement actually proven is the one you want), but the simulator in the ZK game has the witness.
$endgroup$
– Geoffroy Couteau
Apr 29 at 14:27


















draft saved

draft discarded
















































Thanks for contributing an answer to Cryptography Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f70074%2fcould-diffie-hellman-protocol-serve-as-a-zero-knowledge-proof-of-knowledge-of-di%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







kRY06Q I3WOPr8qewEzW,YM,RvcnGB,kHoKx 4Ot uP DBDebTuL31nMJnu3T GPIKKp ljltFK6FxE
Q,dWlvuAJgmC4y7q,PIM,AYvm4caSiM 3V,poemMx dkb,BFmeHwFKx7gFVLeUqT1lpdNiQP hPlz,ZR4g5IBcm

Popular posts from this blog

Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020