1

The answer to this question might be trivial or very short, but I would like to ask it anyway. In both BCNS and NewHope Ring-LWE key-exchange protocol one party adds a secondary error to their calculated key. What is the reason? Is it just to increase entropy? Or is there another a reason behind it?

BCNS protocol (page 8): notice that $e''$ BCNS protocol

NewHope protocol (page 5): notice $e''$ NewHope protocol

Patriot
  • 3,162
  • 3
  • 20
  • 66
Node.JS
  • 322
  • 3
  • 16

1 Answers1

1

If $e''$ isn't there, then $v=bs'$ in both protocols, which means it would be easy to recover $s'$ given $v$ and $b$. Since $b$ is sent in the clear over the channel, and a (randomized) function of $v$ appears in the clear as $c$ (or $r$), without using $e''$ to hide $s'$, information about $s'$ would likely be leaked both to Alice and to any eavesdropper of the channel. Even if it wouldn't immediately leak all of $s'$, any leakage is clearly bad.

Somewhat related to this is the history of lattice signatures, which initially leaked "just a little bit" about the secret key, after which full breaks of these schemes were found. These schemes were only truly fixed once a way was found to make the output distribution completely independent of the secret key, so that nothing is leaked. In this case $e''$ is used to make sure that $v = bs' + e''$ is indistinguishable from random, i.e. the distribution of $v$ is independent of $s'$, assuming R-LWE is hard. See also the security proof in the BCNS paper, where Game 1 and Game 2 are assumed to be indistinguishable under the R-LWE assumption.

TMM
  • 343
  • 4
  • 13