<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Comments on snippet: 'A Symmetric Somewhat Homomorphic Encryption Implementation'</title>
    <description>Snipplr comments feed</description>
    <link>https://snipplr.com/</link>
    <lastBuildDate>Tue, 07 Apr 2026 07:55:45 +0000</lastBuildDate>
    <item>
      <title>weilawei said on 06/May/2012</title>
      <link>https://snipplr.com/view/64194/a-symmetric-somewhat-homomorphic-encryption-implementation</link>
      <description>&lt;p&gt;Hi latot, thank you for taking the time to look this over! I'm sorry it's been so long since you commented, but I didn't think anyone would be interested. So...&#13;
&#13;
#1: I am aware of this problem. I selected the noise and modulus to be the minimum values I thought would consistently work without error. Clearly, I must have set them too low.&#13;
&#13;
#2: I understand the reason for the selection of the modulus of 2, but I'm looking for an explanation as to why any other modulus is particularly bad. Most of my examples use the modulus of 2, and I certainly wouldn't suggest anyone use this in production, and especially not with a different modulus. It's a wild idea that sorta seems to have worked. But I wouldn't trust it. &#13;
&#13;
It does indeed break the homomorphic properties of the original, but it seems to work fine for a cipher otherwise. The real attraction of homomorphic encryption, as I understand it, is to perform computations on encrypted data (and perform encrypted operations), but it seemed interesting that other moduluses would decrypt correctly, so I kept the example. &#13;
&#13;
The rest of the examples are more in line with what I expect homomorphic encryption to be used for. As for the code itself, I'm leaving in the option to specify the modulus, with a default value of 2, should it be unspecified. I've updated the examples and order of the parameters to reflect this.&#13;
&#13;
#3: These are serious problems, so I've incorporated a check to make sure that the key is less than the modulus raised to the noise squared minus 1 and isn't -1.  However, the key should not generally be negative, as I'm using getrandbits() which should simply return bits, with no notion of signedness.&#13;
&#13;
#4: I think I addressed this in #2.&#13;
&#13;
As for integers greater than one, you can't encrypt an integer greater than 1 within a single bit. Expanding the modulus allows for us to use more bits per digit. That was the original motivation for altering the modulus. If you want to encrypt a multi-bit number in this scheme, with a modulus of 2, you need to perform the encryption operation for each bit. &#13;
&#13;
 Thank you for taking the time to try this out, and thank you for pointing out my mistakes with the keygen. I'm updating the code to reflect the changes. There's also a simple right-rotate example that's new.&lt;/p&gt;</description>
      <pubDate>Sun, 06 May 2012 23:18:32 UTC</pubDate>
      <guid>https://snipplr.com/view/64194/a-symmetric-somewhat-homomorphic-encryption-implementation</guid>
    </item>
  </channel>
</rss>
