# Tag Info

5

To answer your question: no this is not homomorphic encryption because one of the plaintexts is used unencrypted. There may be times when it is a useful property, but the only uses I know of it are to demonstrate the malleability of xor ciphers. To be a homomorphic encryption function, it should be possible to calculate the encryption of some function of ...

4

We typically refer to a homomorphic cipher if we can take two ciphertexts and combine them in a way that has a predictible result on the plaintexts. In your example you have taken one ciphertext and one plaintext. Using a stream cipher correctly you should never have 2 ciphertexts encrypted with the same portion of a keystream. So, combining two ciphertexts ...

6

The LWE assumption I think we should start from the LWE assumption. Let $n$ and $q$ be integers and let $\chi$ be a distribution over $\mathbb{Z}_q$. We often take $\chi$ as a Gaussian with small variance. (We take an error $e$ from this distribution $\chi$ and assume that $|e| \ll q$.) The LWE assumption states that any efficient adversary cannot ...

4

So is it possible for homomorphic encryption to actually filter and return a small encrypted subset of a larger encrypted database based on a query? Sure it is. Say we have a database with (encrypted) test scores and student id and want to query the DB for the student with the highest score. Using FHE we can do comparison that for our purposes assume ...

0

Part (a) above makes me believe there is a risk with FHE security being damaged. Is it possible to use another encryption scheme where this risk is mitigated ? I'm not sure what you mean by that. In what way is security damaged? All ciphers risk security being damaged by leakage. For example if the key leaks, security is damaged. I think what they are ...

3

I'll do this backwards If a database has two data types - TEXT (character arrays) and INTEGER (4 or 8 byte integral values), will 'p' ever be 'small' enough to transform an INTEGER value in-situ or in place? No. Homomorphic ciphertexts are still way to big to be stored in a 32 or 64 bit integer. You would likely store the ciphertexts in a string ...

2

Well, it has the obvious problem that if the UA has both $d_1H(r)^{k_1}$ (from the party) and $H(r)^{S-k_1}$ (from the UA), it can compute $d_1$ directly.

2

I may have found an answer (welcoming any comment on whether I missed something) which works, given certain size restrictions on the input $x$ and $y$: Say, party A has Enc(x) and Enc(y): A flips a coin: b in {-1, 1} A computes: $Enc(c) = (Enc(y) Enc(-x))^{b*r} Enc(-r') = Enc(b*r*(y-x)-r')$ where (r, r') are a pair of random obfuscating values such that: ...

Top 50 recent answers are included