jacobi based paillier
This commit is contained in:
parent
2700cb2792
commit
1d9ab1d601
@ -1,22 +1,17 @@
|
||||
import { cryptoRandom, generate_prime } from "./random_primes.js";
|
||||
import { mod_exp } from "./math.js";
|
||||
import { gcd, mod_exp } from "./math.js";
|
||||
|
||||
class Ciphertext {
|
||||
constructor(key, plainText, r) {
|
||||
if (r === undefined) {
|
||||
r = cryptoRandom(4096);
|
||||
|
||||
// Resample to avoid modulo bias.
|
||||
while (r >= key.n) {
|
||||
r = cryptoRandom(4096);
|
||||
}
|
||||
r = cryptoRandom(2048);
|
||||
}
|
||||
|
||||
// Compute g^m by binomial theorem.
|
||||
let gm = (1n + key.n * plainText) % key.n2;
|
||||
|
||||
// Compute g^m r^n from crt.
|
||||
this.cipherText = (gm * mod_exp(r, key.n, key.n2)) % key.n2;
|
||||
// Compute g^m h^r.
|
||||
this.cipherText = (gm * mod_exp(key.hn, r, key.n2)) % key.n2;
|
||||
|
||||
// Force into range.
|
||||
while (this.cipherText < 0n) {
|
||||
@ -206,10 +201,25 @@ class ValueProofSessionVerifier {
|
||||
window.ReadOnlyCiphertext = ReadOnlyCiphertext;
|
||||
|
||||
export class PaillierPubKey {
|
||||
constructor(n) {
|
||||
constructor(n, h) {
|
||||
this.n = n;
|
||||
this.n2 = this.n ** 2n;
|
||||
|
||||
if (h === undefined) {
|
||||
let x = cryptoRandom(4096);
|
||||
|
||||
while (x >= this.n) {
|
||||
x = cryptoRandom(4096);
|
||||
}
|
||||
|
||||
this.h = ((-1n * x ** 2n) % this.n) + this.n;
|
||||
} else {
|
||||
this.h = h;
|
||||
}
|
||||
|
||||
this.g = this.n + 1n;
|
||||
|
||||
this.n2 = this.n ** 2n;
|
||||
this.hn = mod_exp(this.h, this.n, this.n2);
|
||||
}
|
||||
|
||||
encrypt(m, r) {
|
||||
@ -219,11 +229,12 @@ export class PaillierPubKey {
|
||||
toJSON() {
|
||||
return {
|
||||
n: "0x" + this.n.toString(16),
|
||||
h: "0x" + this.h.toString(16),
|
||||
};
|
||||
}
|
||||
|
||||
static fromJSON(data) {
|
||||
return new PaillierPubKey(BigInt(data.n));
|
||||
return new PaillierPubKey(BigInt(data.n), BigInt(data.h));
|
||||
}
|
||||
}
|
||||
|
||||
@ -241,22 +252,48 @@ class PaillierPrivKey {
|
||||
}
|
||||
}
|
||||
|
||||
function check_gcd(primes, new_prime) {
|
||||
for (let prime of primes) {
|
||||
if (gcd(prime - 1n, new_prime - 1n) === 2n) {
|
||||
return prime;
|
||||
}
|
||||
}
|
||||
return null;
|
||||
}
|
||||
|
||||
export function generate_keypair() {
|
||||
let p, q, pubKey, privKey;
|
||||
|
||||
if (window.sessionStorage.getItem("p") === null) {
|
||||
p = generate_prime();
|
||||
window.sessionStorage.setItem("p", p);
|
||||
} else {
|
||||
if (
|
||||
window.sessionStorage.getItem("p") !== null &&
|
||||
window.sessionStorage.getItem("q") !== null
|
||||
) {
|
||||
p = BigInt(window.sessionStorage.getItem("p"));
|
||||
q = BigInt(window.sessionStorage.getItem("q"));
|
||||
} else {
|
||||
let p1 = generate_prime();
|
||||
while (p1 % 4n !== 3n) {
|
||||
p1 = generate_prime();
|
||||
}
|
||||
|
||||
let primes = [p1];
|
||||
|
||||
while (
|
||||
check_gcd(primes.slice(0, primes.length - 1), primes[primes.length - 1]) ===
|
||||
null
|
||||
) {
|
||||
q = generate_prime();
|
||||
while (q % 4n !== 3n) {
|
||||
q = generate_prime();
|
||||
}
|
||||
primes.push(q);
|
||||
}
|
||||
|
||||
p = check_gcd(primes.slice(0, primes.length - 1), primes[primes.length - 1]);
|
||||
}
|
||||
|
||||
if (window.sessionStorage.getItem("q") === null) {
|
||||
q = generate_prime();
|
||||
window.sessionStorage.setItem("q", q);
|
||||
} else {
|
||||
q = BigInt(window.sessionStorage.getItem("q"));
|
||||
}
|
||||
window.sessionStorage.setItem("p", p);
|
||||
window.sessionStorage.setItem("q", q);
|
||||
|
||||
pubKey = new PaillierPubKey(p * q);
|
||||
privKey = new PaillierPrivKey(p, q);
|
||||
|
||||
@ -339,3 +339,45 @@ doi={10.1109/SP.2014.36}}
|
||||
DOI = {10.6028/NIST.FIPS.202},
|
||||
year = {2015},
|
||||
}
|
||||
|
||||
@inproceedings{Jurik2003ExtensionsTT,
|
||||
title={Extensions to the Paillier Cryptosystem with Applications to Cryptological Protocols},
|
||||
author={Mads Jurik},
|
||||
year={2003}
|
||||
}
|
||||
|
||||
@inproceedings{10.1145/3485832.3485842,
|
||||
author = {Ma, Huanyu and Han, Shuai and Lei, Hao},
|
||||
title = {Optimized Paillier’s Cryptosystem with Fast Encryption and Decryption},
|
||||
year = {2021},
|
||||
isbn = {9781450385794},
|
||||
publisher = {Association for Computing Machinery},
|
||||
address = {New York, NY, USA},
|
||||
url = {https://doi.org/10.1145/3485832.3485842},
|
||||
doi = {10.1145/3485832.3485842},
|
||||
abstract = {In this paper, we propose a new optimization for the Paillier’s additively homomorphic encryption scheme (Eurocrypt’99). At the heart of our optimization is a well-chosen subgroup of the underlying , which is used as the randomness space for masking messages during encryption. The size of the subgroup is significantly smaller than that of , leading to faster encryption and decryption algorithms of our optimization. We establish the one-wayness and semantic security of our optimized Paillier scheme upon those of an optimization (i.e., “Scheme 3”) made by Paillier in Eurocrypt’99. Thus, our optimized scheme is one-way under the partial discrete logarithm (PDL) assumption, and is semantically secure under the decisional PDL (DPDL) assumption. On the other hand, we present a detailed analysis on the concrete security of our optimized scheme under several known methods. To provide 112-bit security, our analysis suggests that a 2048-bit modulus N and a well-chosen subgroup of size 448-bit would suffice. We compare our optimization with existing optimized Paillier schemes, including the Jurik’s optimization proposed by Jurik in his Ph.D. thesis and the Paillier’s optimization in Eurocrypt’99. Our experiments show that, – the encryption of our optimization is about 2.7 times faster than that of the Jurik’s optimization and is about 7.5 times faster than that of the Paillier’s optimization; – the decryption of our optimization is about 4.1 times faster than that of the Jurik’s optimization and has a similar performance with that of the Paillier’s optimization.},
|
||||
booktitle = {Annual Computer Security Applications Conference},
|
||||
pages = {106–118},
|
||||
numpages = {13},
|
||||
keywords = {public-key encryption, homomorphic encryption, optimization, provable security},
|
||||
location = {Virtual Event, USA},
|
||||
series = {ACSAC '21}
|
||||
}
|
||||
|
||||
@inproceedings{10.1145/2809695.2809723,
|
||||
author = {Shafagh, Hossein and Hithnawi, Anwar and Droescher, Andreas and Duquennoy, Simon and Hu, Wen},
|
||||
title = {Talos: Encrypted Query Processing for the Internet of Things},
|
||||
year = {2015},
|
||||
isbn = {9781450336314},
|
||||
publisher = {Association for Computing Machinery},
|
||||
address = {New York, NY, USA},
|
||||
url = {https://doi.org/10.1145/2809695.2809723},
|
||||
doi = {10.1145/2809695.2809723},
|
||||
abstract = {The Internet of Things, by digitizing the physical world, is envisioned to enable novel interaction paradigms with our surroundings. This creates new threats and leads to unprecedented security and privacy concerns. To tackle these concerns, we introduce Talos, a system that stores IoT data securely in a Cloud database while still allowing query processing over the encrypted data. We enable this by encrypting IoT data with a set of cryptographic schemes such as order-preserving and partially homomorphic encryption. In order to achieve this in constrained IoT devices, Talos relies on optimized algorithms that accelerate order-preserving and partially homomorphic encryption by 1 to 2 orders of magnitude. We assess the feasibility of Talos on low-power devices with and without cryptographic accelerators and quantify its overhead in terms of energy, computation, and latency. With a thorough evaluation of our prototype implementation, we show that Talos is a practical system that can provide a high level of security with a reasonable overhead. We envision Talos as an enabler of secure IoT applications.},
|
||||
booktitle = {Proceedings of the 13th ACM Conference on Embedded Networked Sensor Systems},
|
||||
pages = {197–210},
|
||||
numpages = {14},
|
||||
keywords = {homomorphic encryption, cloud computing, data security, internet of things, computing on encrypted data},
|
||||
location = {Seoul, South Korea},
|
||||
series = {SenSys '15}
|
||||
}
|
||||
Binary file not shown.
@ -564,11 +564,17 @@ There is little room for optimisation of the mathematics in Paillier encryption.
|
||||
|
||||
\textbf{Smaller key size.} The complexity of Paillier encryption increases with key size. Using a smaller key could considerably reduce the time taken \cite{paillier1999public}.
|
||||
|
||||
\textbf{Pre-computation.} As the main values being encrypted are 0 or 1, a peer could pre-compute the encryptions of these values and transmit these instantly. Pre-computation may be executed in a background "web worker". A consideration is whether a peer may be able to execute a timing-related attack by first exhausting a peer's pre-computed cache of a known value, and then requesting an unknown value and using the time taken to determine if the value was sent from the exhausted cache or not.
|
||||
\textbf{Caching.} As the main values being encrypted are 0 or 1, a peer could maintain a cache of encryptions of these values and transmit these instantly. Caching may be executed in a background "web worker". A consideration is whether a peer may be able to execute a timing-related attack by first exhausting a peer's cache of a known plaintext value, and then requesting an unknown value and using the time taken to determine if the value was sent from the exhausted cache or not.
|
||||
|
||||
Taking this idea further, one may simply pre-compute $r^n$ for a number of randomly generated $r$ (as this is the slowest part of encryption). This eliminates the timing attack concern, and grants full flexibility with the values being encrypted.
|
||||
Taking this idea further, one may simply cache $r^n$ for a number of randomly generated $r$ (as this is the slowest part of encryption). This eliminates the timing attack concern, and grants full flexibility with the values being encrypted.
|
||||
|
||||
\textbf{Restructuring plaintexts.} The maximum size of a plaintext is $|n|$: in our case, this is 4096 bits. By considering this as a vector of 128 32-bit values, peers could use a single ciphertext to represent their entire state. \hyperref[protocol1]{Protocol~\ref*{protocol1}} can be modified by instead testing that the given ciphertext is contained in a set of valid ciphertexts. There would still be a large number of Paillier encryptions required during this proof.
|
||||
\textbf{Alternative Paillier scheme.} \cite{Jurik2003ExtensionsTT} presents an optimised encryption scheme based on the subgroup of elements with Jacobi symbol $+1$. This forms a group as the Jacobi symbol is multiplicative, being a generalisation of the Legendre symbol.
|
||||
|
||||
I used this scheme to reduce the time to encrypt to half. Greater optimisations are possible through pre-computation of fixed-base exponentials, but this takes a considerable amount of time, and I found it unfeasible within my implementation, since keypairs are only used for a single session.
|
||||
|
||||
\textbf{Vectorised plaintexts.} The maximum size of a plaintext is $|n|$: in our case, this is 4096 bits. By considering this as a vector of 128 32-bit values, peers could use a single ciphertext to represent their entire state. \cite{10.1145/2809695.2809723} uses this process to allow embedded devices to make use of the homomorphic properties of Paillier.
|
||||
|
||||
\hyperref[protocol1]{Protocol~\ref*{protocol1}} can be modified by instead testing that the given ciphertext is contained in a set of valid ciphertexts. There would still be a large number of Paillier encryptions required during this proof.
|
||||
|
||||
The other proofs do not translate so trivially to this structure however. In fact, in some contexts the proofs required may be considerably more complicated, becoming round-based proofs which may be slower and use more Paillier encryptions to achieve the same effect.
|
||||
|
||||
@ -605,7 +611,7 @@ The obvious issue is P2P data storage. Users could host their own platforms, but
|
||||
|
||||
The ability to prove the contents of a dataset to a second party without guaranteeing authenticity to a third party is another potential application of the protocol presented. Handling of confidential data is a critical concern for pharmaceutical companies, where a data leak imposes serious legal and competitive consequences for the company. A second party does however need some guarantee that the data received is correct. Proofs are one way of achieving this, although other techniques such as keyed hashing may be more effective.
|
||||
|
||||
Another consideration in this domain is the use of fully-homomorphic encryption schemes to allow a third party to process data without actually viewing the data.
|
||||
Another consideration in this domain is the use of homomorphic encryption schemes to allow a third party to process data without actually viewing the data. This protects the data from viewing by the third party, and the processing methods from viewing by the first party. \cite{10.1145/3485832.3485842} states for example that common statistical functions such as regression can be performed on data that is encrypted under the Paillier scheme.
|
||||
|
||||
\section{Limitations}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user