Чому ми не поєднуємо генератори випадкових чисел?

Існує багато застосунків, де використовується генератор псевдовипадкових чисел. Тож люди реалізують те, що, на їхню думку, є чудовим лише для того, щоб згодом виявити його недоліки. Щось подібне сталося з генератором випадкових чисел Javascript нещодавно. RandU теж набагато раніше. Також є питання про невідповідний початковий посів на щось подібне до Twister.

Я не можу знайти приклади того, хто поєднує дві або більше сімейств генераторів зі звичайним оператором xor. Якщо для управління такими речами, як java.SecureRandom або Twister реалізація є достатньою потужністю, чому люди не поєднують їх? ISAAC xor XORShift xor RandU повинен бути досить хорошим прикладом, і там, де ви можете бачити слабкість одного генератора, що пом'якшується іншими. Це також повинно допомогти з розподілом чисел на більш високі розміри, оскільки внутрішні алгоритми абсолютно різні. Чи є якийсь фундаментальний принцип, який не слід поєднувати?

Якби ви створили справжній генератор випадкових чисел, люди, напевно, порадили б вам поєднати два чи більше джерел ентропії. Чи відрізняється мій приклад?

Я виключаю загальний приклад кількох лінійних регістрів зрушення зворотного зв'язку, які працюють разом, оскільки вони з однієї родини.

IIRC (і це з пам’яті), бестселер Rand 1955 року «Мільйон випадкових цифр» зробив щось подібне. Перш ніж комп’ютери були дешевими, люди вибирали випадкові числа з цієї книги.

Автори генерували випадкові біти з електронним шумом, але це виявилося упередженим (важко зробити так, щоб фліпфлоп витратив рівно однакові рази на фліп та флоп). Однак комбінування бітів зробило розподіл набагато більш рівномірним.

Звичайно, ви можете комбінувати PRNG, як це, якщо хочете, припускаючи, що вони висіваються самостійно. Однак це буде повільніше і, мабуть, не вирішить найактуальніших проблем, які виникають у людей.

На практиці, якщо у вас є вимога до високоякісного PRNG, ви використовуєте добре перевірений криптографічний PRNG, і ви засіваєте його справжньою ентропією. Якщо ви це зробите, ваш найбільш ймовірний режим відмови не є проблемою з самим алгоритмом PRNG; найімовірнішим режимом відмови є відсутність адекватної ентропії (або, можливо, помилок впровадження). Xor-ing декількох PRNG не допомагає в цьому режимі відмови. Отже, якщо ви хочете дуже якісного PRNG, то, мабуть, мало сенсу їх розробляти.

Крім того, якщо ви хочете, щоб статистичний PRNG був достатньо хорошим для цілей моделювання, як правило, проблема №1 - це швидкість (генерувати псевдовипадкові числа дійсно швидко) або простота (не хочу витрачати багато часу на розробку чи дослідження). Xor-ing уповільнює PRNG та робить його складнішим, тому він також не відповідає первинним потребам у цьому контексті.

Поки ти проявляєш розумну турботу та компетентність, стандартні PRNG є більш ніж хорошими, тому насправді немає причини, чому нам потрібне щось фантазійніше (немає потреби в руслі). Якщо у вас немає навіть мінімальних рівнів догляду та компетенції, ви, мабуть, не збираєтесь вибирати щось складне, наприклад, xor-ing, і найкращий спосіб покращити речі - це зосередитись на більшій турботі та компетентності у виборі PRNG а не на ксьор.

Підсумок : В основному, трюк xor не вирішує проблем, які зазвичай є у людей під час використання PRNG.

Насправді, щось проривне було тільки оголошено, роблячи саме це.

Професор інформатики Техаського університету Девід Цукерман та аспірант Ешан Чаттопадхей виявили, що "якісне" випадкове число може бути сформовано шляхом поєднання двох "низькоякісних" випадкових джерел.

Ось їхня робота: Явні екстрактори з двома джерелами та стійкі функції

$X_1,\ldots,X_n$$X_i$$\{0,1\}$$X_1,\ldots,X_n$$K$$f(K)$

$X_1,\ldots,X_n$$(X_1,\ldots,X_n)$$L$$L(\cdot)$

• $y_1,\ldots,y_n$$L(X_1 \oplus y_1, \ldots, X_n \oplus y_n) = L(X_1,\ldots,X_n)$

• $\vec{X^0},\vec{X^1}$$T \in \{0,1\}$$\vec{Z} = \vec{X^T}$$L(\vec{Z}) \geq \min(\vec{X^0},\vec{X^1})$

Перша властивість означає, що міра інваріантна під час перегортання го біта. Друга властивість означає, що якщо ми змішуємо два розподіли , то результат принаймні такий же хороший, як і гірший.$i$$\vec{X},\vec{Y}$

Будь-яка розумна міра випадковості задовольнить першу властивість. Друга властивість задовольняється найбільш популярними заходами, такими як ентропія та min-ентропія .$H$$H_\infty$

Тепер ми можемо заявити і довести теорему, що показує, що XORing двох псевдовипадкових послідовностей завжди є хорошою ідеєю.

Теорема. Нехай - дві незалежні псевдовипадкові послідовності однакової довжини, і - допустима міра випадковості (одна, що задовольняє двом вище умовам). Тоді$\vec{X},\vec{Y}$$L$

Доказ. Припустимо, . Тоді являє собою суміш з розподілу , змішують в відповідно до розподілу . Оскільки і суміш принаймні так само хороша, як і найгірший розподіл, що змішується, ми отримуємо . $L(X) \geq L(Y)$$X \oplus Y$$X \oplus y$$Y$$L(X \oplus y) = L(X)$$L(X \oplus Y) \geq L(X)$$~\square$

Що ця теорема означає, що якщо ви XOR двома псевдовипадковими послідовностями, згенерованими за допомогою двох незалежних ключів, результат завжди принаймні такий же хороший, як і краща послідовність, що є XORed, стосовно будь-якого допустимого показника випадковості.

На практиці, для використання двох незалежних клавіш, ми, мабуть, розширюємо одну клавішу на дві клавіші псевдовипадково. Два клавіші тоді не є незалежними. Однак, якщо ми використовуємо «дорогий» спосіб розширення однієї клавіші на дві клавіші, ми очікуємо, що отримані дві клавіші «виглядають» незалежними, і тому теорема буде «морально». У теоретичній криптографії є ​​способи уточнення цього твердження.

Чи повинні ми тоді XOR два генератори псевдовипадкових чисел? Якщо нас не обмежує швидкість, то це, безумовно, хороша ідея. Але на практиці у нас обмеження швидкості. Тоді ми можемо задати наступне питання. Припустимо, що нам дано два PRNG, кожен з параметром який керує часом роботи (і так силою) генератора. Наприклад, може бути довжиною LFSR або кількістю раундів. Припустимо, ми використовуємо один PRNG з параметром , інший з параметром та XOR результатом. Можна вважати, що , так що загальний час роботи є постійним. Який найкращий вибір$T$$T$$T_1$$T_2$$T_1 + T_2 = t$$T_1,T_2$? Тут є компроміс, на який взагалі важко відповісти. Можливо, налаштування набагато гірше, ніж будь-яке або .$(t/2,t/2)$$(t,0)$$(0,t)$

Найкраща порада тут - дотримуватися популярного PRNG, який вважається сильним. Якщо ви можете зекономити більше часу для створення послідовності, XOR кілька копій, використовуючи незалежні клавіші (або ключі, створені розширенням одного ключа за допомогою дорогого PRNG).

Я спробую це зробити, оскільки мене достатньо турбують поради, наведені в деяких інших відповідях.

Нехай є нескінченними бітовими послідовностями, породженими двома RNG (не обов'язково PRNG, які детерміновані, коли буде відомий початковий стан), і ми розглядаємо можливість використання послідовності з надією покращити поведінку в якомусь сенсі. Існує багато різних способів, за допомогою яких можна вважати кращими чи гіршими порівняно з кожним із та ; ось невеличка жменька, яка, на мою думку, є змістовною, корисною та відповідає звичайному використанню слів «краще» та «гірше»:$\vec{X},\vec{Y}$$\vec{X} \oplus \vec{Y}$$\vec{X} \oplus \vec{Y}$$\vec{X}$$\vec{Y}$

• (0) Ймовірність справжньої випадковості послідовності збільшується або зменшується
• (1) Вірогідність спостережуваної невипадковості збільшується або зменшується (стосовно певного спостерігача, який застосовує певну кількість перевірок, імовірно)
• (2) Суворість / очевидність спостережуваної невипадковості збільшується або зменшується.

Спочатку давайте подумаємо про (0), який є єдиним із трьох, хто сподівається на точність. Зауважте, що якщо насправді будь-який з двох вхідних RNG дійсно є дійсно випадковим, неупередженим та незалежним від інших, то результат XOR буде справді випадковим і неупередженим. Зважаючи на це, розглянемо випадок, коли ви вважаєте, що є справді випадковими неупередженими ізольованими бітовими потоками, але ви не зовсім впевнені. Якщо - відповідні ймовірності, що ви помиляєтесь щодо кожного з них, то ймовірність того, що не є справді випадковою, тоді , насправді набагато менше, оскільки$\vec{X},\vec{Y}$$\varepsilon_X,\varepsilon_Y$$\vec{X} \oplus \vec{Y}$$\leq \varepsilon_X \varepsilon_Y \lt min\{\varepsilon_X,\varepsilon_Y\}$$\varepsilon_X,\varepsilon_Y$ вважаються дуже близькими до 0 ("ти вважаєш їх справді випадковими"). Насправді це навіть краще, ніж це, коли ми також враховуємо можливість бути по-справжньому незалежним, навіть коли жодне не є справді випадковим: Тому ми можемо зробити висновок, що XOR у сенсі (0) не може нашкодити, і може потенційно багато допомогти.$\vec{X},\vec{Y}$

Однак (0) не цікавий для PRNG, оскільки у випадку з PRNG жодна із зазначених послідовностей не має шансів бути справді випадковими.

Тому для цього питання, яке насправді стосується PRNG, ми повинні говорити про щось на зразок (1) або (2). Оскільки це в таких властивостях і кількостях, як "спостережуване", "важке", "очевидне", "очевидне", ми зараз говоримо про складність Колмогорова, і я не збираюся намагатися зробити це точно. Але я піду так далеко, щоб висловити сподіваюсь суперечливе твердження, що за такою мірою "01100110 ..." (період = 4) гірше "01010101 ..." (період = 2), що гірше " 00000000 ... "(константа).

Тепер можна здогадатися, що (1) і (2) будуть слідувати тій самій тенденції, що і (0), і тому висновок "XOR не зашкодить" все ж може бути справедливим. Однак зауважимо значну можливість того, що ні ні не були випадково невипадковими, але кореляції між ними призводять до того, що може бути випадково невипадковим. Найважчий випадок цього, звичайно, це коли (або ), у цьому випадку постійна, найгірший з усіх можливих результатів; загалом, легко помітити, що незалежно від того, наскільки хороші та ,$\vec{X}$$\vec{Y}$$\vec{X} \oplus \vec{Y}$$\vec{X} = \vec{Y}$$\vec{X} = \mathrm{not}(\vec{Y})$$\vec{X} \oplus \vec{Y}$$\vec{X}$$\vec{Y}$$\vec{X}$і повинні бути "близькими" до незалежних, щоб їх xor був не помітно-не випадковим. Насправді, не будучи помітними залежними, можна обґрунтовано визначити як , не будучи помітно-не випадковими.$\vec{Y}$$\vec{X} \oplus \vec{Y}$

Така залежність від несподіванок виявляється справді великою проблемою.

Приклад того, що йде не так

Питання зазначає: "Я виключаю загальний приклад декількох регістрів зсуву лінійних зворотних зв'язків, які працюють разом, оскільки вони з однієї родини". Але я зараз виключаю це виключення, щоб навести дуже простий чіткий чіткий приклад з реального життя, що може піти не так з XORing.

Мій приклад - це стара реалізація rand (), яка була в якійсь версії Unix, приблизно в 1983 році. IIRC, ця реалізація функції rand () мала такі властивості:

• значення кожного виклику rand () становило 15 псевдовипадкових біт, тобто ціле число в діапазоні [0, 32767).
• послідовні повернені значення чергуються з непарними, непарними або непарними; тобто найменш значущі біти чергували 0-1-0-1 ...
• наступний до найменш значущого біта мав період 4, наступний після цього мав період 8, ... тому біт вищого порядку мав період .$2^{15}$
• тому послідовність 15-бітних зворотних значень rand () була періодичною з періодом .$2^{15}$

Мені не вдалося знайти вихідний вихідний код, але я здогадуюсь, щоб зібрати разом декілька публікацій у https://groups.google.com/forum/#!topic/comp.os.vms/9k4W6KrRV3A, що він робив саме наступне (код C), що відповідає моїй пам'яті властивостей, наведених вище:

#define RAND_MAX 32767
static unsigned int next = 1;
int rand(void)
{
    next = next * 1103515245 + 12345;
    return (next & RAND_MAX);
}
void srand(seed)
unsigned int seed;
{
    next = seed;
}

Як можна собі уявити, спроба використовувати цей rand () різними способами призводила до асортименту розчарувань.

Наприклад, в один момент я спробував моделювати послідовність випадкових монет, повертаючи кілька разів:

rand() & 1

тобто найменш значущий біт. Результатом стало просте чергування головки-хвости-голови-хвости. Спершу було важко повірити (має бути помилка в моїй програмі!), Але після того, як я переконав себе, що це правда, я спробував використати наступний найменш значущий біт. Це не набагато краще, як зазначалося раніше - цей біт періодичний з періодом 4. Продовжуючи досліджувати послідовно більш високі біти виявив шаблон, який я зазначив раніше: тобто кожен наступний біт вищого порядку мав вдвічі більше періоду попереднього, так що в в цьому відношенні біт вищого порядку був найкориснішим з усіх. Зауважте, що тут не було чорно-білого порогу "біт корисний, біт не корисний"; Все, що ми можемо сказати, - нумеровані бітові позиції мали різну ступінь корисності / непотрібності.$i$$i-1$

Я також спробував такі речі, як скремблювання результатів далі, або значення XORing разом, повернені з декількох викликів на rand (). Звичайно, пара XORing пар послідовних значень rand () була катастрофою - це призвело до всіх непарних чисел! Для моїх цілей (а саме створення «очевидно випадкової» послідовності монетних перегородок) результат XOR з постійним паритетом був навіть гіршим, ніж чергування непарної поведінки оригіналу.

Незначна зміна ставить це в початковий фреймворк: тобто нехай є послідовністю 15-бітових значень, повернутих rand () з заданим насінням , і послідовністю з іншого насіння . Знову ж таки, буде послідовністю або парних чи непарних чисел, що гірше, ніж оригінальне чергування парного / непарного поведінки.$\vec{X}$$s_X$$\vec{Y}$$s_Y$$\vec{X} \oplus \vec{Y}$

Іншими словами, це приклад, коли XOR погіршив речі у розумінні (1) та (2), будь-якою розумною інтерпретацією. Гірше також у кількох інших способах:

• (3) Найменш значущий біт XORed очевидно упереджений, тобто має неоднакові частоти 0 і 1, на відміну від будь-якого нумерованого бітового положення в будь-якому з входів, які є неупередженими.
• (4) Насправді, для кожної бітової позиції є пари насінин, для яких це положення біту є упередженим у результаті XOR, а для кожної пари насінь є (принаймні 5) бітові позиції, які зміщені в XOR результат.
• (5) Період всієї послідовності 15-бітних значень у результаті XOR становить або 1, або , порівняно з для оригіналів.$2^{14}$$2^{15}$

Жоден з (3), (4), (5) очевидний, але всі вони легко перевірити.

Нарешті, розглянемо можливість повторного введення заборони PRNG з однієї родини. Проблема тут, я думаю, полягає в тому, що ніколи не зрозуміло, чи є два PRNG "з однієї сім'ї", поки / якщо хтось не почне використовувати XOR і не помітить (або зловмисник) речі погіршилися в сенсі (1) та (2), тобто до тих пір, поки невипадкові шаблони у виході не перейдуть поріг від непоміченого до поміченого / бентежного / катастрофічного, і в цей момент вже пізно.

Мене насторожують інші відповіді, які дають некваліфіковану пораду "XOR не може нашкодити" на основі теоретичних заходів, які, як мені здається, роблять погану роботу з моделювання того, що більшість людей вважає "хорошим" і "поганим" PRNG в реальному житті. Цій раді суперечать чіткі і кричущі приклади, в яких XOR робить гірше, наприклад, наведений вище приклад rand (). Хоча можливо, що відносно "сильні" PRNG можуть послідовно демонструвати протилежну поведінку, коли XORed до поведінки іграшкового PRNG, який був rand (), завдяки чому XOR є гарною ідеєю для них, я не бачив доказів у цьому напрямку, теоретичних чи емпіричні, тому мені здається нерозумним припускати, що це відбувається.

Особисто мене, покусавши сюрпризом у юності XORing rand (), і незліченною безліччю різноманітних кореляцій сюрпризів протягом усього життя, у мене мало підстав думати, що результат буде іншим, якщо я спробую знову подібну тактику. Ось чому я особисто був би дуже неохоче на XOR разом декілька PRNG, якщо не було зроблено дуже широкого аналізу та перевірки, щоб дати мені певну впевненість, що це може бути безпечно для конкретних RNG. Як потенційне лікування, коли я маю низьку довіру до одного або декількох окремих PRNG, XORing їх навряд чи збільшить мою впевненість, тому я навряд чи буду використовувати його для такої мети. Я думаю, що відповідь на ваше запитання полягає в тому, що це широко розповсюджені настрої.

ВІДПОВІДАЛЬНІСТЬ: Ця відповідь суворо стосується "Ми це не робимо", а не "ось математичний доказ того, чому він може чи не може працювати". Я не стверджую, що XOR вводить (або ні) криптографічні вразливості. Моя думка лише в тому, що досвід показує нам, що навіть найпростіші схеми майже завжди призводять до непередбачених наслідків - і саме тому ми їх уникаємо.

"Випадковість" - це лише верхівка айсберга, коли мова йде про RNG та PRNG. Є інші важливі якості, наприклад, рівномірність.

Уявіть собі звичайну кістку, яка сама по собі хороша RNG. Але тепер скажімо, що вам потрібен діапазон 1-5 замість 1-6. Перше, що спадає на думку, - це просто стерти 6 облич і замінити його додатковим 1. "Випадковість" залишається (результати все ще справді випадкові), проте однаковість сильно страждає: зараз 1 вдвічі більше, ніж інші результати.

Об'єднання результатів з декількох РНГ - це так само слизький схил. Напр. просте додавання 2-х метальних кісток повністю знищує будь-яку рівномірність, оскільки "7" зараз у 6 разів частіше, ніж "2" або "12". Я погоджуюся, що XOR виглядає краще, ніж додавання на перший погляд, але в PRNG нічого не виходить так, як виглядає на перший погляд.

Ось чому ми прагнемо дотримуватися відомих реалізацій - адже хтось витрачав багато часу і грошей на їх дослідження, а всі недоліки добре відомі, зрозумілі та їх можна подолати. Коли ви розгортаєте свою власну, ви потенційно створюєте вразливості, і вам слід докласти подібних зусиль, щоб довести це. Як показує приклад додавання кісток, комбінування може не сильно відрізнятися від створення нового з нуля.

Безпека - це ланцюжок, настільки сильний, як і його найслабший компонент. Основне правило безпеки: коли ви поєднуєте 2 речі, зазвичай отримуєте суму недоліків, а не суму сильних сторін.