Виснажливий імітатор протоколів нульових знань у моделі випадкового Oracle

У статті під назвою "Про заперечення в загальній системі відліку та випадкової моделі Oracle" Рафаель Пас пише:

Зауважимо, що при доведенні безпеки відповідно до стандартного визначення нульових знань у моделі RO [Random Oracle], тренажер має дві переваги перед звичайним модельним симулятором, а саме:

1. Симулятор може бачити, на які значення сторони запитують оракул.
2. Симулятор може відповідати на ці запити будь-яким способом, який він обрав, поки відповіді "виглядають" ОК.

Перша методика, а саме здатність "контролювати" запити до RO, дуже поширена у всіх роботах, що стосуються концепції нульових знань у моделі RO.

Тепер розглянемо визначення нульових знань чорної скриньки ( PPT розшифровується як імовірнісна поліномальна машина Тьюрінга ):

симулятор PPT S , такий, що ∀ (можливо, обман) верифікатор PPT V ∗ , ∀ загальний вхід x ∈ L і ∀ випадковість r , наступні не відрізняються:$\exists$$S$$\forall$$V^*$$\forall$$x\in L$$\forall$$r$

• вигляд під час взаємодії з прихильником Р на вході x та використанням випадковості r ; $V^*$$P$$x$$r$
• вихід на входах x і r , коли S надається доступ чорного поля до V ∗ . $S$$x$$r$$S$$V^*$

Тут я хочу виставити верифікатор обману , завдання якого - вичерпати будь-який тренажер, який намагається контролювати RO-запити:$V'$

Нехай - тренажер, гарантований екзистенціальним квантором у визначенні нульових знань чорного поля, і нехай q ( | x | ) - поліном, який перевершує час роботи S на вході x . Припустимо, що S намагається контролювати запити V ∗ до RO.$S$$q(|x|)$$S$$x$$S$$V^*$

Тепер розглянемо обман , який спочатку запитує RO для q ( | x | ) + 1 раз (на довільних входах за його вибором), а потім діє довільно злісно.$V'$$q(|x|)+1$

Очевидно, що вичерпує імітатор S . Простий спосіб для S - відкинути таку шкідливу поведінку, але, таким чином, розрізниця може легко відрізнити реальну взаємодію від змодельованої. (Оскільки в реальній взаємодії доказ P не може відслідковувати запити V ' , і, отже, не буде відхиляти, виходячи із простого факту, що V ' запитує занадто багато.)$V'$$S$$S$$P$$V'$$V'$

Яке вирішення вищезазначеної проблеми?

Редагувати:

Хорошим джерелом для вивчення ЗК в моделі РО є:

Мартін Гагне, Дослідження моделі випадкового оракула, к.т.н. Дисертація, Каліфорнійський університет, Девіс , 2008, 109 с. Доступно на ProQuest: http://gradworks.umi.com/33/36/3336254.html

Зокрема, він дає визначення чорної коробки ZK у моделі RO в розділі 3.3 (стор. 20), віднесеної до Юнга та Чжао:

Моті Юнг та Юнлей Чжао. Інтерактивні нульові знання з обмеженими випадковими оракулами. « Теорія криптографії» - TCC 2006 , LNCS 3876, с. 21-40, 2006.

Виникає питання, чому варто було б визначити чорну скриньку ZK у випадковій моделі oracle. Принаймні дві причини, через які люди пропонували визначення нульових знань чорного поля:

$poly(|x|) \cdot time(V*)$$poly(time(V*))$$V*$$V*$$V*$$V*$

$poly(time(V*))$$V*$ типово алгоритм фіксованого полінома, який виконує деякі псевдовипадкові функції, тоді як тренажер може мати будь-який час роботи полінома.

Ось мій погляд на проблему. Я нещодавно не читав жодних робіт, які стосуються нульових знань чорної скриньки у моделі випадкового оракула (RO), тому я просто здогадуюсь, що вони означають, а не те, що там написано. Коротка відповідь (здогадка) полягає в тому, що BB-ZK в моделі RO повинен дозволити тренажеру працювати в часі поліном у | x | і кількість RO-запитів, виданих V *, верифікатором обману.

Спробуємо виправдати цю здогадку. Початкове зауваження полягає в тому, що термін «докази нульових знань чорного поля у випадковій моделі оракула» потребує більш детального вивчення, щоб правильно визначити. Симулятори чорних ящиків визначені для роботи з будь-яким оракулом (тобто верифікатором обману як чорною скринькою), і їх єдиний інтерфейс здійснюється через вхід / вихід oracle. Якщо ми просто розширимо цю модель, щоб дати RO всім сторонам (можливо, дозволяючи їх схемам мати ворота RO), тоді ми отримаємо модель, де тренажер не може запрограмувати RO - на запит oracle, все (включаючи запити RO) відбувається "всередині" Oracle Oracle, і тоді він повертає своє наступне повідомлення. Якщо ми хочемо дозволити програмування RO, тоді нам потрібно змінити інтерфейси: симулятор тепер отримує вхідний / вихідний оракул для V *, а не випадковий оракул. Під час кожного дзвінка до Oracle O * замість того, щоб видавати наступне повідомлення, oracle може замість цього виробляти наступний запит до RO, і тренажер може надати йому відповідь RO, викликаючи оракул ще раз. Тепер це дозволяє програмування RO, і ми також можемо дозволити час роботи симулятора залежати від кількості запитів до RO.

Будь-яке подальше вивчення значення цих визначень залишається читачеві. Я синтаксично думаю.