CC BY
14
ПРИКЛАДНАЯ ДИСКРЕТНАЯ МАТЕМАТИКА
2023 Математические методы криптографии № 61
МАТЕМАТИЧЕСКИЕ МЕТОДЫ КРИПТОГРАФИИ
УДК 003.26 + 004.056 + 001.99 DOI 10.17223/20710410/61/3
ЗАЩИЩЁННОЕ ФОРМИРОВАНИЕ ПУБЛИЧНЫХ ПАРАМЕТРОВ И УСТРАНЕНИЕ УЯЗВИМОСТЕЙ КРАТКИХ НЕИНТЕРАКТИВНЫХ АРГУМЕНТОВ С НУЛЕВЫМ РАЗГЛАШЕНИЕМ
И. В. Мартыненков
АО «КВАНТ-ТЕЛЕКОМ», г. Москва, Россия
E-mail: mivpost@vandex.ru
Рассматриваются известные методы устранения уязвимостей кратких неинтерактивных аргументов с нулевым разглашением на основе корректировки уравнений верификации доказательств, значений публичных параметров в виде главных ссылочных строк и ключей формирования доказательств. Описаны способы защищенного формирования главных ссылочных строк с использованием доверенной третьей стороны и многостороннего взаимодействия.
Ключевые слова: краткие неинтерактивные аргументы, публичные параметры, главные ссылочные строки, защищённость.
SECURE FORMATION OF PUBLIC PARAMETERS AND ELIMINATION OF VULNERABILITIES OF ZERO-KNOWLEDGE SUCCINT NON-INTERACTIVE ARGUMENTS OF KNOWLEDGE
I. V. Martynenkov
JSC "KVANT- TELECOM", Moscow, Russia
The methods of eliminating vulnerabilities of zero-knowledge succinct non-interactive arguments of knowlede are considered. The methods are based on the security of public parameters formation in the form of common reference strings using a trusted third party and multilateral interaction. The multilateral formation of the common reference strings uses the only honest party with a fixed and unlimited set of participants, as well as verification of the reliability of the results. Examples of increasing the level of security of zero-knowledge succinct non-interactive arguments of knowledge based on the correction of proof verification equations and the values of the common reference strings, eliminating redundant elements from the common reference strings and the keys of proof formation are given. The protocols that develop the construction of the common reference strings from static to updatable and universal versions are mentioned.
Keywords: succinct non-interactive arguments, public parameters, common reference strings, security.
Введение
Описаны способы устранения уязвнмостей протоколов zk-SNARK [1], основанных на защищенном формировании публичных параметров в виде главных ссылочных строк (Common Reference String, CRS) с использованием доверенной третьей стороны и многостороннего взаимодействия. Для протоколов zk-SNARK [2, 3], используемых в криптовалюте Zcash [4], рассматривается многостороннее формирование CRS [5] с единственной честной стороной. Для протокола zk-SNARK [6] на примере [7] рассмотрено более защищенное формирование CRS с неограниченным набором сторон в расширяемом онлайн-режиме, верификацией результатов и единственной честной стороной. Повышение уровня защищённости протокола zk-SNARK [6] также представлено переработанной версией [8], в которой выполнена корректировка уравнений верификации и значений, включаемых в CRS. Согласно источникам [9, 101. указывается ошибка описания протокола zk-SNARK [3], основанного на протоколе zk-SNARK «Pinoeehio» [2]. Уязвимость [9, 10] опирается на избыточные элементы, включаемые в CRS и ключ формирования доказательств, которые позволяют строить доказательства для произвольных открытых входов. Приводится метод [9] устранения указанной уязвимости.
В качестве упоминания приводится набор протоколов [11-13], развивающий формирование CRS [7] от статической до обновляемой и универсальной версий, в том числе для протокола zk-SNARK [6] и криптовалюты Zcash [4]. Согласно источникам [14, 15], кратко отмечена возможность повышения уровня защищённости протокола zk-SNARK [2] для случая сговора всех сторон формирования CRS нри условии предварительной проверки доказательств.
1. Протокол надёжного формирования CRS с фиксированным набором сторон
В [14] представлен метод формирования CRS для случая сговора всех задействованных сторон, при котором нарушители способны реконструировать «лазейку» т и подделывать доказательства п. В работе [5] устраняются проблемы защищённости [14] и приведён многосторонний протокол формирования CRS для протоколов zk-SNARK [2, 3], используемых в криптовалюте Zcash [4]. Если хотя бы одна сторона является честной, то конструирование мошеннических доказательств становится невозможным. Дополнительно обеспечивается свойство нулевого разглашения (Zero-Knowledge, ZK), даже если все стороны являются нарушителями.
В протоколе формирования CRS [5] принимают участие n сторон, координатор и верификатор. Роль последних может выполняться одним сервером. Проверка корректности результатов протокола происходит после его полного выполнения, что может оказаться недостатком и потребует перевыполнения всего тяжеловесного процесса формирования CRS, Протокол состоит из четырёх раундов, где каждая сторона Pi.J i = 1,..., n, может отправить своё сообщение после получения сообщения от Pi-\.J a P\ начинает работу после приёма сообщения инициализации. В пределах каждого раунда стороны могут отправлять сообщения для координатора параллельно. Таким образом, протокол формирования CRS [5] имеет вид:
Раунд № 1. Для i = 1,..., п стороны Pi выполняют следующие шаги: 1, Выводятся наборы случайных элементов из F* (для наглядности здесь и далее i-индексы вида pB,i не приводятся, а подразумеваются по умолчанию):
secretsi = [т,рА,рв ,ал,ав ,ac ,в,!}, ^
elementSi = {т, pa,Pb , a а, ав, ac, в, Y, Pa^a, рв ав ,PaPb ,PaPb ac, в! }i.
Pi
fi, /2, /3 S G2 \ {0}, f4, f5, f6, f7, f8 S Gi \ {0}, а затем сохраняет наборы элементов G2 и Gi соответственно:
e(2) = {/1,/1PA, fi pAaA, fipApB aC, fipApB, fipApB aB, f2, /2в, /2вY, /3, f3 т}, e(1) = {/4, f4aA, /5, f5aC, /6, f6pB, f7, f7pA-, f8, f8Y}.
3, Вычисляется результирующий вектор ei = (e(i) || e(2)),
4, Стороны Pi широковещательно передают hi = COMMIT(ei), соответствующее вычислению хеш-функции (в работе [5] используется BLAKE-2),
Относительно ei требуется, чтобы для каждого s S secretsi (1) при s S F* всегда присутствовала необходимая s-парa (p,q), где s ■ p = q. Для конкретной группы используется термин G-s-napa, Например, по fi, fipA, fiрАрв строятся рА-парa (fi, fipA), рв-нарa (fipA, fipApB) и рАРв-парa (/i,/ipApB)■
Раунд № 2.
Pi
ковещательно передают ei; а верификатор проверяет соответствие hi = COMMIT(ei), Далее elementsi (1) принимают наименование зафиксированных элементов, так как к текущему моменту выполнения протокола для каждого s S elementsi стороны отправили s-пары для Gi и G2 в виде rpj и rp^ Для представленных ниже значений
Pi s
т (rpi, rp22) = (g,тg), Y К, rP2) = (g,Yg),
pA (ГРрА, rppA ) = (g,pAg), pAaA (rPpA«A , rPP>A»A ) = (g,РAaAg),
Рв KB , rPpB ) = (д,рв g), Рв aB (rPpBaE , rPpEaE ) = (PAg,PApBaBg),
aA (rP^A,ГР1А) = (pAg,pAaAg), PaPb KAPB , rP2pAPE ) = (g,PApBg),
ав (гР1в , гР1Е ) = (PaPb g,PAPB а в g), PaPbac (rPpAPEac , rP2PAPEac ) = (g,PAРвacg),
ac (rpic,гР^с ) = (PaPb g,PAPB ac g), вY (rPe7, rPe7) = (g,eYg).
в (rPe, rPe) = (Yg,вYg),
Часть 2 , Проверяется факт фиксации сторонами Р^ пар элементе в из Gl и G2, входящих в гр1 и гр2, соответствующих в-парам одинаковых элементов в Е Е*. Для г Е Е {1,...,п}, в Е е!етеп1з^ верификатор запускает проверку
БатеРайо^р1, гр2) = БатеРа1ю((р, q), (/, Н)). (3)
Проверка (3) успешна, если при р^ Е G1 и /, Н Е G2 все четыре элемента не равны 0 и е(р, Н) = е^, /) для билинейного епаривания е(ад1, Ьд2) = д^.
Часть 3 , Выполняется доказательство и проверка знаний дискретных логарифмов, Сторона Р1 вычисляет дайджест сообщений раунда № 1 Л = СОММЩЛ^ || ... || || кп) и широковещательно его передаёт. Затем для г = 1,... ,п выполняются следующие шаги:
1, Для s G secret (1) фиксируется hi,s = (h || rp1^, Все стороны Pi и верификатор имеют элементы для вычисления текущего шага,
2, Для каждого s G secretsi сторонами Pi широковещательно передаются доказательства ni,s:
пм = NIZK(rp1,hi,s). (4)
Функция NIZK (4) основана на протоколе Шнорра [16, 17], которая по s-nape rps = (f, H = sf) и строке h выводит рандомизированную строку — доказательство знания строки s. Для функции (4) выбирается случайное a и R = af. Вычисляется c = COMMIT(R || h), которое интерпретируется как элемент Fr, например взятием первых log г бит, а также u = а + cs. Результатом является пара (R,u),
3, Для каждого s G secretsi верификатором проводится проверка
1/0 = VERIFY - NIZK(rp1,nM,hM). (5)
Функция (5) проверяет, действительно ли доказательство соответствует заданному h, Для этого вычисляется c = COMMIT(R || h) и доказательство принимается, если u/ = R + cH,
Часть 4 , Для т = т\,..., тп (2) вычисляется вектор
POWERSr = ((1,т,т 2,...,Td)gi, (1,т,т2 ,...,Td)g2).
1, Стороной P1 выполняется широковещательная передача V1 = (1, т, т2,..., тd)g1 и V/ = (1, т, т2,..., тd)g2, а для i = 2,..., n — широковещательная передача сторонами Pi значений V = powerMult(Vi-1, тг) и V/ = powerMult^/, тг-1), Например, для вектора V G Gd+1 и a G Fr функция powerMult(V, a)ie{0,...,d} = {aiV : i = 0,...,d} G Gd+1.
2, Для i G {2,..., n} верификатор подтверждает корректность ранее переданных векторов. Выполняются проверки
SameRatioSeq(V1, rp^f), SameRatioSeq(V1/, (V1,0, V1,1)),
SameRatioSeq(V, (V'0, Vi,1)), SameRatioSeq(V/, (V,o, VM)), (6)
SameRatio((V-1,1,Vi,1), rpT2)).
Если проверки (6) выполняются, то на выход подаются компоненты ключа доказательства (PKH = Vn, PKH = VI). Функция подтверждения соответствия s SameRatio() SameRatioSeq()
для V G Gf и rps G G2 проверяет, что каждые два последовательных элемента V являются s-парой. Она соответствует вызову SameRatio(V', rps) для V' = ((Vo, V1), (V1, V2),..., (Vd-1, VO).
3, Выполняется проверка корней Z(x). Для обеспечения нулевого разглашения требуется, чтобы т являлось корнем Z(ж) = — 1, Для этого верификатор и все Pi проверяют равенство Z(т)g1 = (т^ — 1)g1 = Vn,d — Vn,0 = 1, иначе протокол перезапускается,
4, Используется набор векторов квадратичной арифметической программы (Quadratic Arithmetic Program, QAP), Координатор вычисляет QAP-векторы доказательства A, B, B2, С в точке т, где, в отличие от [3], Am+1 = Bm+1 = Cm+1 = = Z [т ]g1 = (тd — 1)01:
A = 01{Д(т) : i = 0,...,m + 1}, B = ^{ВДт) : i = 0,...,m + 1},
B2 = 02{Вг(т): i = 0,...,m +1}, С = 01{Сг(т): i = 0,...,m + 1}. U
Раунд № 3.
Часть 1 , Координатор широковещательно передает векторы А, В, В2, С (7),
Часть 2 , Для получения различных элементов ключей выполняется подпрото-кол выработки случайных коэффициентов RCPC, Для элементов а = (а,..., € € elementsi (1) вычисляются элементы ключей
ркА = RCPC(A, рА), ркБ = RCPC(B2,pБ), РКс = RCPC(C,PAPБ), РКА = RCPC(A,pAаA), РКВ = RCPC(B,pБ аБ), РКС = RCPC(C,PAPБ ас), ¿етрБ = RCPC(B,pБ), ^ = RCPC(g2Z(т) = ^ - 1),рАрБ), ука = RCPC(g2, аА), укБ = RCPC(gl, ав), = RCPC(g2, ас).
Для расчётов (8) не требуется в-пара для каждого 5 € secretsi каждой группы. Например, требуется только С2-рА-пара, которая используется для вычиеления рка, а СгрА-пара не используется,
Подпротокол RCPC (8) покоординатно умножает вектор элементов из С1 на скаляр а € Е*. Перед вызовом подпротокола для каждого г € {1,..., п} стороны Р^ передали С2-а^-пары фа., доступные верификатору. Таким образом, RCPC(V, а) принимает V € и а^ € Е* для г € {1,..., п}. Сторон а Р1 вычисляет У1 = а1 V, а для г = 2,..., п стороны Р^ широковешательно передают Vi = а^^, В итоге стороны выводят УП = аУ,
Раунд № 4. Вычисляются компоненты ключей, содержащие элемент в; для чего стороны Р^ или только координатор рассчитывают V = рка + ¿етрБ + РКс, Затем стороны вычисляют
РКк = RCPC(V, в), = RCPC(g2,7), УКв1^ = RCPC(gl, вт), VKв27) = RCPC(g2,в7).
В заключение верификатор запускает функцию verifyRCPC() на входных параметрах в виде результатов работы раундов № 3, 4, Верификация успешна, если все вызовы подтверждены,
Для векторов $, Т € и С2-а-пары фа функция sаmeRаtio((S, Т), фа) (3) возвращает sameRatio(V, rpa) где V = ($г,Тг). Функция verifyRCPC(V, а) принимает V, а также ^..^К, € и С2-а^-пары фа. для г € {1,...,п}, Затем запускается sameRatio((V, V!), фа1), а для г = 2,..., п запускается sameRatio((Vi-1, фа.), Если все итерации успешны, верификация подтверждается,
В работе [15] отмечается, что злонамеренный выбор секретных параметров, зависящих от т,рА,рБ,аА,ас,7,в € Е*, может нарушить свойство нулевого разглашения протокола [2], Даже при отсутствии честных сторон Р^ формирование СПБ способом [5] устраняет данную уязвимость протокола [2] при условии проверки доказательства перед его отправкой,
2. Протокол надёжного формирования СИБ с неограниченным и расширяемым набором сторон
По сравнению с работой [5], в [7] рассмотрено более защищённое формирование СПБ протокола /к-ЯХАНК [6], Алгоритмы формирования доказательства и верификации соответствуют протоколу /к-Я.\ЛН1ч [6]. Протокол [7] работает с неограниченным набором сторон в расширяемом онлайн-режиме без их предварительного выбора, не требует хранения конфиденциальных значений в течение длительного времени и предварительной фиксации случайных значений. Доказательства будут достоверны, если
хотя бы одна из N сторон является честной. Дополнительную роль играет ненадёжный координатор — детерминированная функция, причём любая сторона способна проверить корректность его сообщений. В частности, верификатор формирования С ES [7] независимо вычисляет сообщения координатора и проверяет их достоверность. В роли верификатора может выступать как координатор, так и любая сторона протокола.
В [7] арифметическая схема С над Fp рассматривается как чередующиеся слои умножения/деления С,..., Cd и их линейные комби нации Li,..., Ld, Вход exe мы x разделяется на непересекающиеся наборы x1,..., xd, соответствующие слоям. Целью вычислений является вывод C(x)g для произвольного входа x. Детальнее, рассматривается произведение x = (x1 •... • xN • x'), где xi e (Fp)4 — вход стороны Pi, a x' — выход функции рандомизации RB. Уровни схемы обозначаются как С1, L1,..., Cd, Ld, и протокол выполняет d рабочих фаз. Для выполнения одной фазы фиксируется уровень l e {1,..., d}, С = Q и L = Li. Предполагается, что для всех вентилей g предыдущих
уровней С1, L1,..., Ci-1, Li-1 уже вычислен набор значений [g] e G = G1 x G2,
-{xi : i = n,..., 2n - 2}, {axi : i =1,...,n - 1}, {ßxi : i =1,...,n - 1} (9)
и убраны элементы {(ßui(x) + avi(x) + wi(x))/Y : i = 0,... ,l}, 7, которые являются линейной комбинацией компонентов С ES и добавленных элементов (9). В [7] протокол
С1
вход x1 = {x, a, ß} и вычисляет (9). Слой L1 вычисляет {xit(x) : i = 0,... ,n - 2} как линейные комбинации x\ i e {0,..., 2n — 2} где deg(t(x)) = n, а также {(ßui(x) + + avi(x) + wi(x)) : i = 0,... ,m} как линейные комбинации результатов С ь Слой С2 имеет вход x2 = {#} и вычисляет {(ßui(x) + avi(x) + wi(x))/S : i = l + 1,... ,m}, {xit(x)/ö : i = 0,... ,n - 2}.
Для упрощения надёжное формирование CES [7] для протокола zk-SNAEK [6] представлено для одной группы и аналогично для других групп. Используются сле-
n [x]
тых входов; {1,..., 1} — индексы открытых входов; {l + 1,..., m} — индексы секретных входов. Значение М является вычисляемым выходом в G1; G2 или G = G1 x G2; Pj — стороны протокол а при j e {1,...,N}; не M после внесения сто-
ронами P1,..., Pj долей распределённых вычнсленнй; [М]0 — ^^^^^тое значение; g = = (g1, g2) _ элементы групп G1, G2. Выполняются два раунда протоко-
ла [7].
Раунд № 1. Используются следующие вспомогательные функции. Формирование доказательства знания a e Fp выполняется функцией POK(a, v^, которая строит r = = R([a]1, v) e G2 и на выход подает ([a]1 ,ar), вде ^^^^^^ункцня; [a]1 = ag1 при (g1) = Gb Верификация доказательств а знания a e Fp выполняется за счёт функции CheckPOK(a, v,b) при a e G1, b e G2, которая строит r = R(a, v) e G2 и на выход подаёт SameRatio((g1, a), (r, b)). ^такцпя SameRatio (3) соответствует [5].
Функция Consistent(A, B, C) [7] использует (A, B) e G2 ми (A, B) e G1 x G2 = = G2, а также C e Gp или C e (G2)^. Если C e (G2)2, то вычисляется r = = SameRatio((A1,B1), (C1 ,C2)), иначе r = SameRatio((A1, B1), (g2,C)). Если (A,B) e e G2, то на выход подаётся r, иначе выводится r и SameRatio((A1 ,B1), (A2,B2)). Верификатор протокола для j e {1,... ,N} ^^^тасляет ra,j = R([aj]1, transcript1j-1) rß,j =
= R([ßj]1,transcript1j-1) rx,j = R([xj]1,transcript1j-1^. ^такция transcript1j-1 выводит
Pj
Функция RB принимает временной слот целое число к и возвращает случайное а € Ер Пусть (7 — 1) — временной интервал, в который Р^ отправляет сообщение. Выполняются следующие шаги:
1, Для каждого входа х схемы С выполняется инициализация значений
{И0 = g : г = 1,... , п — 1}, {[х*]° = ^ : г = п,... , 2п — 2}, {[ах*]° = 01 : г = 0,...,п — 1}, [в]° = g, {[вх*]° = 01 : г =1,...,п — 1}.
2, Для ] € {1,..., N} стороны протокола Р.,- вычисляют набор значений
[а, ]l, [в, ]l, [х, ]l, = POK(аj, transcript1,j-1), ув,, = POK(вj, transcript1,j-1), ух,, = POK(xj, transcript1,j-1), {[х^ = х,[х^-1 : г = 1,..., 2п — 2}, {[ах*, = а,х,[ах*,-1 : г = 0,..., п — 1}, {[вх? = в,х,[вх?-1 : г = 0,... , п — 1}.
3, Координатор выводит (х',а',в') = RB(J, 3), определяются значения
{[х*] = х'г[хг]м : г = 1,..., 2п — 2}, {[ах*] = а'х*[ахг]м : г = 0,... ,п — 1}, {[вхг] = в'х'ЧвхГ : г = 0,... , п — 1}.
4, Достоверность полученных значений выполняется проверками
CheckPOK([а ,]1,transcript1,j-1,у«,,), CheckPOK([вj]1,transcript1,j-1,ув,,), CheckPOK([xj ]1, transcript1,j-1 , ух,,), consistent([а]j-1 — [а]-7, (га,-,уа,,)), consistent([в,-1 — [вГ, (гв,,,Ув,,)), consistent([x]j-1 — [х]^, (Гх,,,Ух,,)), {consistent([xi-1]j — [х?, [х]^) : г = 1,..., 2п — 2}, {consistent([xг]'1 — [ахгр, [а,) : г = 1,..., п — 1}, {consistent([xi]i — [вхг]^', [в,) : г = 1,... ,п — 1}.
5, На выход раунда 1 подаётся набор значений
М1 = {{[х*] : г = 0,... ,п — 1}, {[х*Ь : г = п,... , 2п — 2}, {[ах*]1 : г = 0,...,п — 1}, [в], [5], {[в^Ь : г =1,...,п — 1}}.
Раунд № 2. Выполняются следующие шаги:
1, Для каждого входа ^мы С вычисляются
К = {виДх) + а^(х) + од(х))/5 : г = I + 1,..., т},
Щ = {¿(х)х*/5 : г = 0,... , п — 2}.
2, Выполняется инициализация необходимых для раунда 2 значений:
{[Кг]° = К* : г = I + 1,...,т}, {[Яг]° = Щ : г = I + 1,...,т}, [5]° = g.
(10)
3, Для j e {1,..., N} стороны протокола Pj вычисляют набор значений
[5^, ys,j = POK(5j, transcript2,j-1), [5]j = [S]j-1/5j, {[Ki]j = ([Ki]j-1)/8j : i = l + 1,...,m}, {[Hi]j = ([Hi ]j-1)/5j : i = 0,...,n - 2}.
4, Аналогично раунду 1, пусть (J - 1) — временной интервал, в который PN отправляет сообщение. Выводится 5' = RB( J, 1) и определяются значения
[5] = [5]N/5', [Ki]1 = [Ki]N/5', [Hi]1 = [Hi]N/5'.
5, Верификатор для j e {1,..., N} вычисляет rs,j = R([5j]1, transcript2j-1). Достоверность полученных значений выполняется проверками
CheckPOK([5j ] 1, transcript2 1,ys,j), consistent([5]j - [5]j, (r$,j,ys,j)), {consistent([Ki]j - [Ki]j-1, [5j ]) : i = l + 1,...,m}, {consistent([Hi]j - [Hi]j-1, [5j ]) : i = 0,...,n - 2}.
6, На выход раунда JVS 2 подаётся следующий набор значений:
М2 = {[5], {[Ki]1 : i = l + 1,...,m}, {[Hi]1 : i = 0,...,n - 2}}. (11)
M1 M2
{[xi] : i = 0,... ,n - 1}, {[xi]1 : i = n,... , 2n - 2}, {[ax^ : i = 0,...,n - 1}, [ß], {[ßx% : i = 1,...,n - 1}, {[xit(x)/5]1 : i = 0,...,n - 2}, {[(^Ui(x) + avi(x) + Wi(x))/5]1 : i = l + 1,... ,m}.
По сравнению с работой [7], в [11] представлено альтернативное доказательство защищённости информации, содержащейся в CRS протокола zk-SNARK [6]. Для этого используется 2-раундовая процедура формирования и проверки корректности публичных значений. Протокол [И] формирует надёжную С RS и сохраняет конфиденциальность секретного входа для случая с единственной честной стороной. Защищённость сохраняется даже при доступе злоумышленников ко всем этапам рерандомизации CRS, кроме одного. В результате протокол [11] формирует новые обновляемые публичные параметры С RS для Zcash [4] и проводит их верификацию, развивая идеи [7] на основе протокола zk-SNARK [6]. Свойство обновляемое™ С RS позволяет динамичному набору сторон вносить в публичные параметры секретную случайность неограниченное количество раз.
На каждом этапе протокола [7] требуется наличие хотя бы одной честной стороны. При этом второй этап [7] зависит от первого, поэтому формируемая CRS не может обновляться. В протоколе [12] любая сторона в любое время способна обновить и подтвердить корректность обновлённой CRS. Это верно, если одна из старых CRS достоверна и/или одна из сторон обновления является честной. Таким образом, CRS [12] может непрерывно рерандомизироваться с сохранением результатов всех предыдущих обновлений, удовлетворяя доверию всех сторон, заинтересованных в надёжности формируемых публичных значений. Кроме того, С RS [12] не привязывается к конкретной дискретной функции, поэтому является универсальной CRS (Universal CRS, lCHS) и подходит для различных дискретных функций. В определённом смысле протокол формирования С RS [12] всё ещё использует доверенную третью сторону, однако уверенность в защищённости CRS повышается, потому что только одна предыдущая сторона должна уничтожать введённую секретную случайность.
Например, согласно [12], С ES протокола zk-SNARK [18] может быть обновлена, в то время как С ES протокола zk-SNARK «Pinocchio» [2] не является обновляемой и требует вмешательства доверенной третьей стороны. Источник [12] также демонстрирует способ нарушения защищённости исторически базового протокола zk-SNARK «Pinocchio» [2],
Работа [13] продолжает развитие идей [12], где используются обновляемые универсальные структурированные CRS (Structured UCRS, SUCRS) и приводится метод, в котором ненадёжные стороны повышают производительность пакетной верификации доказательств. Для произвольных дискретных функций доказательство протокола [13] составляет 256 байт, все компоненты которого принадлежат одной группе,
3. Устранение уязвимости протокола zk-SNARK Э. Бен-Сассона, А. Кьезы, Э. Тромера, М. Вирзы
Источник [9] раскрывает ошибку в описании протокола zk-SNARK [3], По сравнению с исходной версией протокола zk-SNARK «Pinocchio» [2], схема [3] включает в С RS избыточные элементы, которые важно не раскрывать. Уязвимость позволяет при наличии корректного доказательства для некоторого открытого входа создавать корректные доказательства для любого открытого входа, В [9] представлено также доказательство надёжности протокола zk-SNARK [3] при исключении из С RS данных элементов и удовлетворении QAP определённым алгебраическим условиям.
Источник [10] описывает отличия протоколов zk-SNARK [2] и [3], Показана уязвимость [3], в которой нарушитель представляет ложные открытый вход и доказательство, принимаемые верификатором. Согласно [10], устранение уязвимоетей [3] требует издержек и компромиссов производительности. На основе результатов [10] в исправленной версии работы [3] в виде [19] атака была ослаблена. Однако в [9] представлена более серьёзная уязвимость протокола zk-SNARK [3] на основе избыточных элементов ключа формирования доказательства. Протоколы zk-SNARK [5, 20, 21] и реализация [22] основаны на [3], поэтому унаследовали проблемы защищённости. Реализация [23] не использует избыточные элементы, поэтому не подвержена атаке [9],
Для описания устранения уязвимости [9] используется нотация протокола zk-SNARK [3], где m-разме р QAP; d-степень QAP;" и — размер от крытого входа x G Fn; QAP имеет форму {{A^X ),ВДХ ),Cj(X) : i = 0, ...,m},Z (X)}; степени Aj, Bj, Cj G F[X] не выше d; Z G F[X] и имеет степень d; [x]j = gf при (gj) = Gj.
Таким образом, в [3] элементы pkA j = [aApAAj(r)] i не используются доказывающим и верификатором, однако позволяют доказывающему заменять открытые входы на основе корректного доказательства. Это возможно за счёт введения множителя для компоненты доказательства па, что изменяет значение открытого входа, связанного с исходным доказательством, с x = (xi,... , xn) G FN на x' = (x1, ..., x^) G FN, Первое уравнение верификации [3] e(nA,g2) = e(nA, [a^b) для компонент доказательства
m n
ПА = [pAAmid(T )]i,nA = [a A PA Amid (T )]i, ГД6 Amid = Y, xjAj - xjAj, призвано недо-
j=0 j=0
пустить нежелательное поведение, но избыточные элементы также позволяют злонамеренному доказывающему добавить аналогичный множитель к пА- В результате для изменённого открытого входа верификация становится успешной. Подробности атаки приведены в [9],
Уязвимость протокола zk-SNARK [3] устраняется исключением из ключа доказательства набора pkA j = [aAPAAj(r)]1 и использованием QAP с линейно независимыми полиномами {Aj : i = 0,..., n} [10], которые не пересекаются в индексах i G {0,..., n}
иг G {n + 1,..., m}. В результате изменения протокола zk-SNARK [3] с учётом модификаций [9] принимают следующий вид:
Алгоритм формирования ключей
1, Выводятся случайные секретные значения т, Pa, Р в ,&a, ав , ас ,Y, ß G Fp
2, Для i G {0,..., d} вычисляютея тг.
3, Для i G {0,..., m} вычисляются компоненты ключа доказательства:
РаА (т), рвВг(т), авРвВг( т), РаРвСг(т), ас РаРв Сг(т), ß^Ai^) + рв Вг(т) + рАрв Сг(т)).
4, Формируется набор (аА, ав,ас,j, ß*y, рАрвZ(т)) и для i G {n + l,..., m} вычисляются аАрААг(т),
Алгоритм верификации
n
Вычисляется PI(x) = раа0(т) + Y1 хгрААг(т) и проверяется выполнение следующих
г=1
уравнений:
п'А = ах^А, п'в = а в пв, п'с = ас пс, 1Пк = ßY(PI(x) + ПА + пв + пс), (PI(x) + пх)пв = пс + пн Z (т )рАРв.
и
4. Устранение уязвимости протокола zk-SNARK И. Грота
Протокол zk-SNARK [8] основан на программах квадратичной арифметики (Square Arithmetic Program, SAP) и билинейном спаривании, В [8] приняты меры по устранению проблем защищённости протокола zk-SNARK [6, 1], в котором уравнение верификации для известного полинома f (ф) и секретыых а, ß, 5 имеет вид e(A,B) =
= e(ga, hß)e(gf, h)e(C, h5), В данном случае противник может изменить текущее до-
ф
(A, B, C)
В первом случае противник для некоторого r переназначает компоненты доказательства в виде A = Ar, B' = B1/r, C = C. Атака устраняется добавлением проверки e(A, h) = e(g, B), а для значения r = —1 уравнение верификации корректируется для
e (Aga5 ,Bhß5) e(A, B)
переназначение вида A' = A, B' = Bhr5, C = ArC. Для устранения атаки в CRS включаются h5 ,gl5w hl5, а g5 исключается. Но если противник устанавливает B' = Bhr5, то единственным возможным значением, удовлетворяющим представленному ниже уравнению верификации, будет A' = Agr5 вместо доступного A' = A, которое противник вычислить не способен ввиду отсутствия g5 в CRS, Значение r = Ф(т) соответствует значению полинома Ф в секретной «лазейке» т. Результирующие уравнения верификации представлены ниже в алгоритме верификации доказательств,
В работе [8] используется частный случай QAP под названием SAP, где иг(х) = ьг(х) i
R = (p, G1, G2, GT, e, l, {иг(х), тг(х) : i = 0,..., m}, t(x)).
Билинейная группа определяет конечное поле Zp для прост ого p > 2х-1, l ^ l ^ m, иг(х), и>г(х), t(x) G Zp[x] и иг(х), тг(х) имеют строго более низкую степень, чем n = = deg(t(x)). Множество S = {иг(х) : i = 0,..., 1} линейно независимо, всякий полином
Uj(x) € S линейно независим от множества {uj (x) : j = l + 1,..., m}. В результате при s0 = 1 программа SAP определяет следующее бинарное отношение:
R
{(ф,м) : ф = (si,... ,Si) € zp,w = (si+i, ...,Sm) € zm
3h(x) € Zp[x] ( deg(h) ^ n — 2 & ( SjWj(x)) = SjWj(x) + h(x)t(x)
i=0
i=0
(12)
Алгоритм формирования ключей (crssap,p) ^ Setup(1A,sap) На основе отношения R (12) и параметра защиты А вырабатываются CRS и р —
Setup
1, Выводятся случайные элементы для формирования ключа верификации т = = (а, в, 7,^, x) € Zp, такие, что t(x) = 0,
2, Вычисляется CRS
crssap = (g", gY, g", g^, g7*t(x), g7^^ , g(a+e)Y<5i(x) , h, , h*, he<5, h7<5t(x), h^ , {g7^, h7^, gY2^t(x)xi : i = 0, . . . , n — 1}, {gY^wi(x)+^(«+eH(x) : i = 0, ..., l}, (13)
{g
n
,725wi(x)+75(a+e)ui(x) :
:i
l + 1,... ,m})
3, Вычисляется ключ р без раскрытия значения предназначенный для проверки корректности CRS (13):
р = (ga,he ,gY ,gx).
4, На выход подаётся тройка (crs, т, р).
Строка CRS (13) содержит m + 2n + 5 элементов из G1 и n + 3 элементов из G2. Критически важно, чтобы CRS не содержала значений вида g, g6, в которых b является небольшой величиной, например битом, за счёт чего нарушитель может восстановить данную переменную и решить задачу дискретного логарифмирования.
Алгоритм проверки CRS-структуры 0/1 ^ UpdateVerify(1A, sap, crs^p,^) 1, Выполняется проверка набора уравнений
e(ga<5, h) = e(ga,h),
e(g7<5, h) = e(gY), e(g7<Si(x),h7<S) =
= e(g7^(i(x)-io)7Ö/x, h7Öx)e(g-io7^, h7^), e(g725i(x)2, ^) = e(g7<5i(x), h7<5i(x)),
e(gY ) = e(g,h7<5),
e(g7<5, he) = e(gY,he<5), e(g7<5) = e(gY, h^2), e(g7<Si(x), ) = e(g7<5, h7<5i(x)),
e(g(«+e)7^i(x), ) =
= e(ga<5, h7<5i(x))e(g7<5i(x), he<5).
(14)
2, Выполняется проверка набора уравнений для различных индексов г:
1+1 ),
0 ^ i ^ n — 2
1 ^ i ^ n — 1 0 < i < l
e(gx, h7") = e(g, h7x ), e(g7<5xi, h7<5x) = e(g7<5x
e(g725i(x)xi, h7^) = e(gY<5i(x), h7<5xi), e(g75wi(^)+5(a+e)ui(x) h^^) =
= e(g7^ h7^wi(x))e(gaö hY^ui(x))e(gYöui(x) h^)
e(g72^wi(®)+75(a+e)ui(x) ^) =
= e(g7^, h7<5wi(x))e(ga<5, h7<5ui(x))e(g7<5ui(x), he<5).
(15)
I + 1^ г^ т
3, Если все проверки (14) и (15) выполняются, то на выход подаётся 1, иначе 0,
Алгоритм доказывающего п ^ Prove(info, ф, w)
Алгоритм доказывающего анализирует публичные ф и приватные w значения входов-выходов логических элементов схемы (1,a1,..., am) и встраивает оценки SAP-полиномов aiui (x), полученные в случайной секрет ной точке x, в один элемент проверки в Gi и в один элемент проверки в G2, На их основе строится третий элемент доказательства, показателем которого является произведение показателей первых двух элементов; info = (bp, sap, crssap, е(даё ,he)), Алгоритм выполняет следующие шаги:
1, Выбирается случайный элемент r G Zp для обеспечения свойства ZK,
2, Выполняется выборка публичных и приватных значений входов-выходов логических элементов схемы (ф || w): (a0,a1,..., am) ^ Parse(1, ф, w).
3, Вычисляется многочлен-делитель
(/ m \ 2 m \
( Y ai Ui(x)\ - Y aiwi(x) j /t(x).
4, Вычисляются компоненты доказательства п = (A, B, C):
Y^ rt(x)+J] aiUi (x)
A = д \ i=0
/ m
Y^l rt(x)+J2 aiUi(x)
B = hY^rt(x)+i=0 aiUi(x)J, (16)
mm
yM J2 ai(jwi(x)+(a+e)ui(x))+r(a+e)t(x)+jt(x)(r2t(x)+h(x)+2r J2 aiUi(x)
C = д \i=l+1 i=0
5, На выход подаётся доказательство п = (A, B, C),
Размер доказательства (16) составляет два элемента из G1 и один элемент из G2, Алгоритм верификатора 0/1 ^ Verify(info, ф, п)
С использованием билинейного спаривания верификатор проверяет, что компонен-A B п
что показатель степени компонента C доказательства п является произведением показателей первых двух компонент. Алгоритм Verify выполняет следующие шаги:
1, Выполняется выборка открытых значений входов логических элементов схемы ф: (a0,a1,..., ai) ^ Parse(1, ф),
2, Выполняется разделение компонент доказательства (16):
(A, B, C) G Gi х G2 х Gi ^ Parsed).
3, Выполняется проверка уравнений верификации
i
е(Ада&, ВНв*) = е(д«й, ^)е(д§>*е(с, ^), ^
е(А,к) = е(д,В).
АВ ра (А, В) однозначно определяет С через первое уравнение (17), 4, Если все проверки (17) выполняются, то выводится 1, иначе 0,
Алгоритм моделирования доказательства п ^ Б1т(Ьр, sap, о^р^^) За счёт «лазейки» т возможно вывести корректные доказательства. Для этого выполняются следующие шаги:
1, Выполняется выборка открытых значений входов логических элементов схемы 0: (а0, ai,..., а^) ^ Parse(1, 0),
2, Выбирается случайное значение ^ е Zp.
3, Вычисляются компоненты доказательства (A,B = gM<5, ),
i
Z) a(7Wi(x)+(a+e)ui(x)))
4, Вычисляется компонента C = g i=0
5, На выход подаётся доказательство п = (A, B, C),
Заключение
Рассмотрены способы устранения уязвимоетей протоколов zk-SNARK, основанных на нарушении защищённости формирования CRS [5, 7, 11-15]. Представленные протоколы построения надёжных CRS являются самостоятельными и тяжеловесными конструкциями, которыми возможно расширять протоколы zk-SNARK, например [2, 3, 6], Проверка корректности формируемых CRS, например [5, 7], происходит после выполнения всего протокола, что в случае выявления частых нарушений может оказаться недостатком и требует повторного выполнения всего процесса построения CRS, Описаны более защищённые версии прототоколов zk-SNARK [6, 3] в виде модернизированных схем [8-10], Отмечается [24], что рассмотренные в работе протоколы zk-SNARK [2, 3, 6] имеют фиксированный размер доказательств и постоянное количество уравнений верификации, что дополнительно обосновывает целесообразность их практического применения. Проблемы защищённости других производительных протоколов zk-SNARK [24], например [19, 20, 25-29], в публичном доступе не представлены, поэтому их также можно рассматривать в качестве кандидатов на практическое применение,
ЛИТЕРАТУРА
1. Мартыненков И. В. Краткие неинтерактивные аргументы с нулевым разглашением на основе наборов полиномов // Прикладная дискретная математика. 2023. №59. С. 34-72.
2. Рато В., Howell J., Gentry С., and Raykova M. Pinocchio: Nearly practical verifiable computation // Proc. 34th IEEE Svmp. Security and Privacy. Oakland, 2013. P. 238-252.
3. Ben-Sasson E., Chiesa A., Tromer E., and Virza M. Succinct non-interactive Zero Knowledge for a von Neumann architecture // Proc. 23rd USENIX Security Svmp. San Diego, CA, USA, 2014. P. 781-796.
4. HopwoodD., BoweS., Hornby Т., and Wilcox N. Zcash Protocol Specification. Version 2021.2.16 [NU5], 2021. 213p.
5. Bowe S., Gabizon A., and Green M.D. A Multi-Party Protocol for Constructing the Public Parameters of the Pinocchio zk-SNARK. Crvptologv ePrint Archive. Paper 2017/602. 2017. 25p. https://ia.cr/2017/602.
6. GrothJ. On the size of pairing-based non-interactive arguments // LNCS. 2016. V. 9666. P. 305-326.
7. Bowe S., Gabizon A., and Miers I. Scalable Multi-Party Computation for zk-SNARK Parameters in the Random Beacon Model. Crvptologv ePrint Archive. Paper 2017/1050. 2017. 24p. https://eprint.iacr.org/2017/1050.
8. Groth J. and Mailer M. Snarkv Signatures: Minimal Signatures of Knowledge from Simulation-Extractable SNARKs. Crvptologv ePrint Archive. 2017. 36 p. https://eprint. iacr.org/2017/540.pdf.
9. Gabizon A. On the Security of the BCTV Pinocchio zk-SNARK Variant. Crvptologv ePrint Archive. Paper 2019/119. 2019. 9p. https://eprint.iacr.org/2019/119.
10. Parno В. A Note on the Unsoundness of vnTinvRAM's SNARK. Crvptologv ePrint Archive. Paper 2015/437. 2015. 4p. https://eprint.iacr.org/2015/437.
11. Mailer M. A Proof of Security for the Sapling Generation of zk-SNARK Parameters in the Generic Group Model. 2018. 12 p. https://github.com/zcash/ saplingsecurity-analysis/blob/master/MaryMallerUpdated.pdf.
12. Groth J., Kohlweiss M., Mailer M., et al. Updatable and Universal Common Reference Strings with Applications to zk-SNARKs. Crvptologv ePrint Archive. Paper 2018/280. 2018. 38 p. https://eprint.iacr.org/2018/280.
13. Mailer M., BoweS., Kohlweiss M., and MeiklejohnS. Sonic: Zero-Knowledge SNARKs from Linear-Size Universal and Updateable Structured Reference Strings. Crvptologv ePrint Archive. Paper 2019/099. 2019. 20 p. https://eprint.iacr.org/2019/099.
14. Ben-Sasson E., Chiesa A., Green M., et al. Secure sampling of public parameters for succinct zero knowledge proofs // IEEE Svmp. SP 2015. San Jose, CA, USA, 2015. P. 287-304.
15. Campanelli M., Gennaro R., Goldfeder S., and Nizzardo L. Zero-knowledge contingent payments revisited: Attacks and payments for services // Proc. ACM SIGSAC Conf. CCS'17. N.Y.: ACM, 2017. P. 229-243.
16. Schnorr C. Efficient identification and signatures for smart cards // LNCS. 1990. V. 435. P. 239-252.
17. Черёмушкин А. В. Криптографические протоколы. Основные свойства и уязвимости. М.: Издательский центр «Академия», 2009. 272 с.
18. Groth J. Short pairing-based non-interactive zero-knowledge arguments // LNCS. 2010. V. 6477. P. 321-340.
19. Ben-Sasson E., Chiesa A., TromerE., and Virza M. Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture. Updated version. 2019. 37 p. https://eprint. iacr.org/2013/879.pdf.
20. Backes M., Barbosa M., Fiore D., and Reischuk R. M. ADSNARK: Nearly practical and privacy-preserving proofs on authenticated data // Proc. 2015 IEEE Svmp. Security and Privacy. San Jose, CA, USA, 2015. P. 271-286.
21. Fuchsbauer G. Subversion-Zero-Knowledge Snarks. Crvptologv ePrint Archive. Paper 2017/587. 2017. 32p. https://eprint.iacr.org/2017/587.
22. zkSNARKs implementation in JavaScript k, WASM. https://github.com/iden3/snarkjs.
23. С++ library for zkSNARKs. https://github.com/scipr-lab/libsnark.
24. Мартыненков И. В. Способы повышения производительности кратких неинтерактивных аргументов с нулевым разглашением и анализ достигнутых результатов // Прикладная дискретная математика. 2023. №60. С. 40-58.
25. Gennaro R., Gentry С., Parno В., and Raykova М. Quadratic span programs and succinct NIZKs without PCPs // LNCS. 2013. V.7881. P. 626-645.
26. Ben-Sasson E., Chiesa A., GenkinD., et al. SNARKs for C: Verifying program executions succinctly and in zero knowledge 11 LNCS. 2013. V. 8043. P. 90-108.
27. Danezis G., Fournet C., Groth J., and Kohlweiss M. Square span programs with applications to succinct NIZK arguments 11 LNCS. 2014. V.8873. P. 532-550.
28. Ben-Sasson E., Chiesa A., TromerE., and Virza M. Scalable zero knowledge via cycles of elliptic curves // LNCS. 2014. V.8617. P. 276-294.
29. Costello C., Fournet C., Howell J., et al. Geppetto: Versatile verifiable computation // Proc. IEEE Svmp. SP'15. IEEE Computer Society, USA, 2015. P. 253-270.
42
l/l. B. MaprbiHeHKOB
REFERENCES
1. Martynenkov I. V. Kratkie neinteraktivnve argumentv s nulevvm razglasheniem na osnove naborov polinomov [Zero-knowledge succinct non-interactive arguments of knowledge based on sets of polynomials]. Prikladnava Diskretnava Matematika, 2023, no. 59, pp. 34-72. (in Russian)
2. Parno B., Howell J., Gentry C., and Raykova M. Pinocchio: Nearly practical verifiable computation. Proc. 34th IEEE Svmp. Security and Privacy, Oakland, 2013, pp. 238-252.
3. Ben-Sasson E., Chiesa A., Tromer E., and Virza M. Succinct non-interactive Zero Knowledge for a von Neumann architecture. Proc. 23rd USENIX Security Svmp., San Diego, CA, USA, 2014, pp.781-796.
4. HopwoodB., BoweS., Hornby T., and Wilcox N. Zcash Protocol Specification. Version 2021.2.16 [NU5], 2021. 213p.
5. Bowe S., Gabizon A., and Green M.P. A Multi-Party Protocol for Constructing the Public Parameters of the Pinocchio zk-SNARK. Cryptologv ePrint Archive. Paper 2017/602, 2017. 25p. https://ia.cr/2017/602.
6. GrothJ. On the size of pairing-based non-interactive arguments. LNCS, 2016. vol.9666, pp.305-326.
7. Bowe S., Gabizon A., and Miers I. Scalable Multi-Party Computation for zk-SNARK Parameters in the Random Beacon Model. Cryptologv ePrint Archive. Paper 2017/1050, 2017. 24p. https://eprint.iacr.org/2017/1050.
8. Groth J. and Mailer M. Snarkv Signatures: Minimal Signatures of Knowledge from Simulation-Extractable SNARKs. Cryptologv ePrint Archive, 2017. 36 p. https ://eprint. iacr.org/2017/540.pdf.
9. Gabizon A. On the Security of the BCTV Pinocchio zk-SNARK Variant. Cryptologv ePrint Archive. Paper 2019/119, 2019. 9p. https://eprint.iacr.org/2019/119.
10. Parno B. A Note on the Unsoundness of vnTinvRAM's SNARK. Cryptologv ePrint Archive. Paper 2015/437, 2015. 4p. https://eprint.iacr.org/2015/437.
11. Mailer M. A Proof of Security for the Sapling Generation of zk-SNARK Parameters in the Generic Group Model. 2018. 12 p. https://github.com/zcash/ saplingsecurity-analysis/blob/master/MaryMallerUpdated.pdf.
12. Groth J., Kohlweiss M., Mailer M., et al. Updatable and Universal Common Reference Strings with Applications to zk-SNARKs. Cryptologv ePrint Archive. Paper 2018/280, 2018. 38 p. https://eprint.iacr.org/2018/280.
13. Mailer M., BoweS., Kohlweiss M., and MeiklejohnS. Sonic: Zero-Knowledge SNARKs from Linear-Size Universal and Updateable Structured Reference Strings. Cryptologv ePrint Archive. Paper 2019/099, 2019. 20 p. https://eprint.iacr.org/2019/099.
14. Ben-Sasson E., Chiesa A., Green M., et al. Secure sampling of public parameters for succinct zero knowledge proofs. IEEE Svmp. SP 2015, San Jose, CA, USA, 2015, pp.287-304.
15. Campanelli M., Gennaro R., Goldfeder S., and Nizzardo L. Zero-knowledge contingent payments revisited: Attacks and payments for services. Proc. ACM SIGSAC Conf. CCS'17, N.Y., ACM, 2017, pp. 229-243.
16. Schnorr C. Efficient identification and signatures for smart cards. LNCS, 1990, vol.435, pp.239-252.
17. Cheremushkin A. V. Kriptograficheskie protokolv. Osnovnve svojstva i uvazvimosti [Cryptographic Protocols. Basic Properties and Vulnerabilities]. Moscow, Akademiva Publ., 2009. 272 p. (in Russian)
18. Groth J. Short pairing-based non-interactive zero-knowledge arguments. LNCS, 2010, vol.6477, pp.321-340.
19. Ben-Sasson E., Chiesa A., TromerE., and Virza M. Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture. Updated version, 2019. 37 p. https://eprint. iacr.org/2013/879.pdf.
20. Backes M., Barbosa M., Fiore D., and Reischuk R. M. ADSNARK: Nearly practical and privacy-preserving proofs on authenticated data. Proc. 2015 IEEE Svmp. Security and Privacy, San Jose, CA, USA, 2015, pp. 271-286.
21. Fuchsbauer G. Subversion-Zero-Knowledge Snarks. Crvptologv ePrint Archive. Paper 2017/587, 2017. 32p. https://eprint.iacr.org/2017/587.
22. zkSNARKs implementation in JavaScript k, WASM. https://github.com/iden3/snarkjs.
23. C++ library for zkSNARKs. https://github.com/scipr-lab/libsnark.
24. Martynenkov I. V. Sposobv povvsheniva proizvoditel'nosti kratkikh neinteraktivnvkh argumentov s nulevvm razglasheniem i analiz dostignutvkh rezul'tatov [Ways to improve the performance of zero-knowledge succinct non-interactive arguments of knowledge and analysis of the results achieved]. Prikladnava Diskretnava Matematika, 2023, no. 60, pp. 40-58. (in Russian)
25. Gennaro R., Gentry C., Parno B., and Raykova M. Quadratic span programs and succinct NIZKs without PCPs. LNCS, 2013, vol.7881, pp.626-645.
26. Ben-Sasson E., Chiesa A., GenkinD., et al. SNARKs for C: Verifying program executions succinctly and in zero knowledge. LNCS, 2013, vol.8043, pp.90-108.
27. Danezis G., Fournet C., Groth J., and Kohlweiss M. Square span programs with applications to succinct NIZK arguments. LNCS, 2014, vol.8873, pp. 532-550.
28. Ben-Sasson E., Chiesa A., TromerE., and Virza M. Scalable zero knowledge via cycles of elliptic curves. LNCS, 2014, vol.8617, pp.276-294.
29. Costello C., Fournet C., Howell J., et al. Geppetto: Versatile verifiable computation. Proc. IEEE Svmp. SP'15, IEEE Computer Society, USA, 2015, pp. 253-270.
