This commit is contained in:
jude 2023-04-17 19:47:04 +01:00
parent c87f88b287
commit ea217af596
3 changed files with 17 additions and 14 deletions

View File

@ -189,7 +189,7 @@
function RSABench() {
console.log("Warming up")
const ROUNDS = 250;
const ROUNDS = 10000;
for (let i = 0n; i < 100n; i++) {
window.rsa.pubKey.encrypt(i);
@ -209,7 +209,7 @@
function PaillierBench() {
console.log("Warming up")
const ROUNDS = 250
const ROUNDS = 500
for (let i = 0n; i < 100n; i++) {
window.paillier.pubKey.encrypt(i);
@ -230,7 +230,7 @@
console.log("Warming up")
const cipherText = paillier.pubKey.encrypt(0n)
const ROUNDS = 20;
const ROUNDS = 50;
for (let i = 0; i < 5; i++) {
cipherText.proveNI();
@ -249,7 +249,7 @@
function ZeroProofVerifierBench() {
console.log("Warming up")
const ROUNDS = 20
const ROUNDS = 50
const cipherText = paillier.pubKey.encrypt(1n)
const readOnly = cipherText.asReadOnlyCiphertext();

Binary file not shown.

View File

@ -591,9 +591,11 @@ Taking this idea further, one may simply cache $r^n$ for a number of randomly ge
\textbf{Alternative Paillier scheme.} \cite[Section~2.3.1]{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.
Using this scheme alone reduced the time to encrypt by a half. Greater optimisations are possible through pre-computation of fixed-base exponentials, but this takes a considerable amount of time, and I found it infeasible within my implementation, since keypairs are only used for a single session.
Using this scheme alone reduced the time to encrypt by a half. Greater optimisations are possible through pre-computation of fixed-base exponentials, but the time and memory consumption of this exceeds what my browser was capable of for key sizes of 4096-bit and greater.
In practice gains were closer to a reduction by a third, since in the modified scheme additional computation must be performed to attain the $r$ that would work with normal Paillier, in order to perform the zero-knowledge proofs from before.
In practice, using the scheme alone gave gains close to a reduction by a third, since in the modified scheme additional computation must be performed to attain the $r$ that would work with normal Paillier, in order to perform the zero-knowledge proofs from before.
Using pre-computation on top of this yielded much greater gains, being around four times faster. This is likely due to avoiding the slowdown from general overhead around my JavaScript implementation of modular exponentiation.
Other research such as \cite{10.1145/3485832.3485842} suggests ways to speed up encryption further that could be utilised.
@ -617,31 +619,32 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
\fontsize{10pt}{10pt}\selectfont
\caption{Time to encrypt}
\label{table1}
\begin{tabularx}{\textwidth}{c *3{>{\Centering}X}}
\begin{tabularx}{\textwidth}{c *4{>{\Centering}X}}
\toprule
Modulus size & Na\"ive encrypt & Jacobi encrypt & RSA encrypt \\
Modulus size & Na\"ive encrypt & Jacobi encrypt & Jacobi encrypt with pre-computation & RSA encrypt \\
\midrule
$|n| = 1024$ & 6ms & 4ms & <1ms \\
$|n| = 2048$ & 34ms & 22ms & <1ms \\
$|n| = 4096$ & 189ms & 128ms & <1ms \\
$|n| = 1024$ & 6.0ms & 4ms & 1.4ms & 0.015ms \\
$|n| = 2048$ & 34ms & 22ms & 7.6ms & 0.040ms \\
$|n| = 4096$ & 189ms & 128ms & -- & 0.093ms \\
\bottomrule
\end{tabularx}
\end{table}
\begin{table}[htp]
\fontsize{10pt}{10pt}\selectfont
\caption{Time to process proofs}
\caption{Time\parnote{$|n| = 4096$ uses a less-optimised encryption method, as the browser frequently timed out attempting to pre-compute for the more-optimised version.} to process proofs}
\begin{tabularx}{\textwidth}{c *6{>{\Centering}X}}
\toprule
\multirow{2}{*}{Modulus size} & \multicolumn{2}{c}{Proof-of-zero non-interactive} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 48$} \tabularnewline
\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}
& Prover & Verifier & Prover & Verifier & Prover & Verifier \\
\midrule
$|n| = 1024$ & 10ms & 18ms & 1,740ms & 2,190ms & 3,380ms & 4,270ms \\
$|n| = 2048$ & 44ms & 68ms & 8,170ms & 8,420ms & 16,100ms & 16,200ms \\
$|n| = 1024$ & 10ms & 18ms & 1,420ms & 2,140ms & 2,900ms & 4,270ms \\
$|n| = 2048$ & 44ms & 68ms & 6,390ms & 8,140ms & 13,200ms & 16,200ms \\
$|n| = 4096$ & 225ms & 292ms & 41,500ms & 34,400ms & 83,200ms & 68,400ms \\
\bottomrule
\end{tabularx}
\parnotes
\end{table}
\begin{table}[htp]