Методы для получения реальных случайных чисел

@noname664 · Регистрация: 16.10.2015

Студворк — интернет-сервис помощи студентам

Предложите, пожалуйста, какие-нибудь методы для получения реальных случайных чисел.

Началось всё с того, что мне нужно было сделать программу для генерации ключей.
Безопасный ключ должен быть полностью случайным и достаточно длинным.

Я придумал достаточно тривиальный способ "ручного" сбора энтропии. Но дело в том, что от такого способа создания ключа напрягался не компьютер, а наоборот я сам.

Мой метод:
Создал форму, на которой в случайном порядке кликаю мышью, каждый клик даёт 1 случайный бит.
Для получения этого бита я использую позицию X, позицию Y, время клика T (системное время с точностью до миллисекунд) по формуле:
b = (x % 2) ^ (y % 2) ^ (t % 2);

Использую остаток от деления по модулю 2 для получения случайного бита, а совместное "проксоривание" все трёх источников натуральной энтропии приводит к чрезвычайной нестабильности и непредсказуемости выходного бита.
Генерация 512 битного ключа - долгая ручная работа.

Предложите свои способы, которые были бы такие же надёжные, но простые в использовании.

Генератор случайных чисел, встроенный в процессоры, не предлагать).

Спасибо)

Добавлено через 19 минут
Есть способ с помощью микрофона.
Длина ключа 512 бит = 64 байта.
Используем глубину кодирования 16 бит = 2 байта.
Таким образом, при частоте дискретизации 48000 Гц, длительность семпла = (64 / 2) / 48000 ~= 0.666 миллисек.
В этом семпле, по логике, должен находиться белый шум, который можно использовать в качестве ключа.
Однако, я сомневаюсь, что этот белый шум не имеет какой-либо сложной закономерности, которую уже могли заметить и описать сложными формулами.
1. Безопасен ли такой способ?
2. А если получить два таких семпла и "проксорить" их, это улучшит результат в плане безопасности?

Добавлено через 2 минуты
Не смотря на простоту вопроса, я считаю, вопрос достаточно сложен.

Добавлено через 16 минут
И ещё один способ пришёл в мою голову:
Представим, что есть веб-камера.
Делаем всего один скриншот с этой камеры, получаем большой байтовый массив фотоснимка.
Далее, опишу универсальный алгоритм для любого размера скриншота:
Длина и ширина выражается переменными w и h, таким образом, длина одномерного массива с фотоснимком равна w * h * 3 (RGB).

Далее, допустим длина массива равна 1024 * 768 * 3 = 2 359 296 байт.
Гм... нам нужно всего 64 байта (это длина ключа, 512 битного (это чтобы на все времена)).
Для этого циклично "проксориваем" первые 64 байта со вторыми 64-мя байтами массива, потом всё это уже с 3-ми 64-мя байтами, потом с 4-тыми 64-мя байтами и так далее до конца всего массива.

На выходе должна получиться смесь из всей картинки, "перексоренную" в 64 байта.

Скажите пожалуйста, как Вам такой метод и насколько он может быть приемлем?

Добавлено через 2 минуты
P.S. А ещё можно проксорить звуковой семпл и картинку с веб-камеры...

Добавлено через 10 минут
Кстати, алгоритм для случая выше (с веб-камерой) оказался достаточно прост:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
unsigned char m[1024 * 768 * 3];
unsigned long long mSize = 1024 * 768 * 3;
 
unsigned char key[64];
 
...
 
for (unsigned long long i = 0; i < 64; i = i + 1)
{
    key[i] = 0;
}
 
//Получение ключа из фотоснимка.
for (unsigned long long i = 0; i < mSize; i = i + 1)
{
    key[i % 64] = key[i % 64] ^ m[i];
}

@Shamil1 · 08.12.2015, 16:37

А чем Вас не устраивают криптостойкие ГПСЧ?

@noname664 · 09.12.2015, 19:56 **[ТС]**

...
Затем берём 8 семплов от микрофона (каждый по 64 байта), и ключ key, полученный выше в алгоритме с веб-камерой. Затем всё это между собой "перексориваем".
Получается очень быстро и, наверно, этого будет достаточно?

А чем Вас не устраивают криптостойкие ГПСЧ?

Я им не доверяю, да и не люблю какие-то специальные микросхемы, люблю использовать натуральную энтропию. Честно говоря я не могу внятно объяснить, почему я им не доверяю, возможно я просто люблю нестандартные способы.

Добавлено через 21 час 55 минут
Вообщем, я придумал способ, опишу если кому пригодится в будущем:
Потребуется криптографическая хеш-функция SHA-3 (Keccak), отлично сделанная реализация для C++ есть в интернете, я сам лично её скачал и проверил.

Далее, используем тот способ, который я изложил в самом начале темы для получения всего-лишь одного ключа.

Далее, SHA-3 является криптопримитивом, с её помощью можно построить даже блочный шифр со счётчиком и делать Message Auth Code без конструкции HMAC, подробности на Википедии.

Теперь, имея всего один ключ, мы может получить на его основе произвольное количество новых ключей и сохранить их на будущее и использовать их но мере необходимости.

Допустим у нас есть ключ 0123456789abcdef, тогда чтобы получить на его основе новый ключ, допишем к нему индекс ключа и возьмём от всего этого хеш, а именно:

HashSHA3("0123456789abcdef" + "00000001")

Теперь по аналогии получим второй ключ:

HashSHA3("0123456789abcdef" + "00000002")

Выходное хеш-значение и есть новый ключ, полученный на основе базового ключа и индекса.

Таким образом, можно сгенерировать запас ключей на многие годы и сохранить их).

Такой способ создания ключей безопасен только для SHA-3 (Keccak), поскольку она используется для создания гаммы с фиксированным префиксом и переменным суффиксом, другие хеш-функции для этого использовать нельзя.

ВАЖНО! Базовый ключ, на основе которого были получены новые ключи, должен быть уничтожен сразу же после использования, потому что утечка этого ключа скомпрометирует все полученные на его основе ключи.

Кароче я сам ответил на свой вопрос)

Добавлено через 7 минут
Поправка, написано "поскольку она используется для создания гаммы с фиксированным префиксом и переменным суффиксом", следует читать "поскольку она используется для создания гаммы на основе прообраза с фиксированным префиксом и переменным суффиксом".
Понять не могу, зачем нельзя редактировать сообщение если прошло более 5 минут.

Добавлено через 5 часов 10 минут
...
Но и это ещё не всё.
Идея получает продолжение.
Представьте, что у нас есть микрофон и веб-камера и SHA-3.

Далее, я понимаю, что есть шумы в голосовой записи с микрофона и есть тепловой шум на фотоснимке с веб-камеры, но я считаю, что хоть эти шумы внешне и выглядят случайно, однако могут может быть описаны какими-нибудь сложными формулами типа разложение в математический ряд, проще говоря, на вид поток случайных чисел, но использовать в чистом виде нельзя.

Но представьте, что мы сделали голосовую запись длительностью 1 секунда качества 16 бит/48000 Гц.
Она занимает 96 000 байт.
Далее в это же время сделаем 1 фотоснимок с веб-камеры качества 320 на 240.
Он занимает 230 400 байт.

Далее, занесём в общий массив эти массивы данных (голос и фото) и получим общую длину 326 400 байт.

И наконец, теперь рассчитаем хеш для этих данных в общем массиве.
Полученный хеш и будет сгенерированным ключом.

Любое изменение входных данных (хотя бы на один бит) меняет итоговый хеш до неузнаваемости.
Он будет всегда уникальный, потому что я не могу поверить, что у кого-то ещё байт в байт совпадут и голос и фото.

А как думаете Вы?

Добавлено через 4 минуты
Ах да, можно ещё в общий массив закинуть UTC...

@Shamil1 · 10.12.2015, 09:27

Сообщение от noname664

Он будет всегда уникальный, потому что я не могу поверить, что у кого-то ещё байт в байт совпадут и голос и фото.

Сбой в логике. Для того чтобы совпали хэши не требуется совпадение информации, на основе которой они делаются.

@noname664 · 10.12.2015, 12:20 **[ТС]**

Сбой в логике. Для того чтобы совпали хэши не требуется совпадение информации, на основе которой они делаются.

Да, поправка, я просто не уточнил, если хеш длиной 512 бит, то совпадения начнутся через примерно 1.25 * Sqrt(n), т.е. примерно после 2^256 сгенерированных хешей, парадокс Дней Рождений, что нереально много и поэтому никто всё равно не увидит совпадений этих хешей, поэтому меня волнует чтобы именно входные данные не совпадали часто.

Добавлено через 5 минут
Если например в каждом фотоснимке, даже если он делается всегда с одного и того же ракурса и при тех же условиях, за счёт например теплового шума, есть минимум 512 случайных и не кореллируемых между собой бит, то это означает пригодность использования фотоснимка для получения ключа 512 бит, вычислением 512 битного хеша от этого фотоснимка.

Добавлено через 1 минуту

Затем берём 8 семплов от микрофона (каждый по 64 байта), и ключ key, полученный выше в алгоритме с веб-камерой. Затем всё это между собой "перексориваем".
Получается очень быстро и, наверно, этого будет достаточно?

Вообще здесь я всё-таки не согласен сам с собой, всё-таки "перексоривать" нельзя, надо просто брать хеш...

@noname664 · 15.12.2015, 01:58 **[ТС]**

Придумал ещё способ, хотя наверно не я первый.
Запускаем 4 параллельных потока, в бесконечном цикле периодично меняем переменную с 0 на 1 и наоборот.
Затем, в главном потоке через каждые 40 мс считываем значение этих переменных.
Для большей рандомижатности "перексориваем" их между собой (a ^ b ^ c ^ d).
Каждое считывание через каждые 40 мс даёт 1 случайный бит.
Для генерации 512 битного ключа потребуется 40 мс * 512 = 20 480 мс ~= 20.5 секунд.

Как Вам такой метод?
Насколько эти биты случайны?
Вот рабочий код на VS C++:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
#include "stdafx.h"
 
#include <iostream>
#include <windows.h>
#include <thread>
 
 
unsigned long long a;
unsigned long long b;
unsigned long long c;
unsigned long long d;
 
unsigned long long thread_end_a;
unsigned long long thread_end_b;
unsigned long long thread_end_c;
unsigned long long thread_end_d;
 
 
void ThreadA()
{
    a = 0;
    while (thread_end_a == 0)
    {
        a = 1 - a;
        Sleep(0);
    }
}
 
void ThreadB()
{
    b = 0;
    while (thread_end_b == 0)
    {
        b = 1 - b;
        Sleep(0);
    }
}
 
void ThreadC()
{
    c = 0;
    while (thread_end_c == 0)
    {
        c = 1 - c;
        Sleep(0);
    }
}
 
void ThreadD()
{
    d = 0;
    while (thread_end_d == 0)
    {
        d = 1 - d;
        Sleep(0);
    }
}
 
 
 
void main()
{
    thread_end_a = 0;
    thread_end_b = 0;
    thread_end_c = 0;
    thread_end_d = 0;
 
    std::thread thrA(ThreadA);
    std::thread thrB(ThreadB);
    std::thread thrC(ThreadC);
    std::thread thrD(ThreadD);
    
    std::cout << "Start 512 bit";
 
    for (int i = 0; i < (8 * 64); i = i + 1)
    {
        if ((i % 8) == 0)
        {
            std::cout << "\n";
        }
        Sleep(40);
        std::cout << a << b << c << d << "=" << (a ^ b ^ c ^ d) << "  ";
 
    }
 
    thread_end_a = 1;
    thread_end_b = 1;
    thread_end_c = 1;
    thread_end_d = 1;
 
    std::cout << "\n";
    std::cout << "Stop Generate";
 
    while (1)
    {
    }
}

Добавлено через 10 минут
Написано:

C++
1
                std::cout << a << b << c << d << "=" << (a ^ b ^ c ^ d) << "  ";

Следует читать:

C++
1
2
3
                unsigned long long ta, tb, tc, td;
                ta = a; tb = b; tc = c; td = d;
                std::cout << ta << tb << tc << td << "=" << (ta ^ tb ^ tc ^ td) << "  ";

Что-то мне стыдно стало за такую ошибку((, я собою очень недоволен!

@Satorius · 15.12.2015, 06:02

Я просто оставлю это здесь:
Подробно о генераторах случайных и псевдослучайных чисел
Вы опасно некомпетентны в криптографии

@Shamil1 · 15.12.2015, 10:40

Сообщение от noname664

Насколько эти биты случайны?

У наборов случайных (псевдослучайных) чисел есть две независимые характеристики: криптостойкость и "случайность".
Криптостойкость - это насколько сложно, зная алгоритм, "угадать" следующее число.
"Случайность" - это равномерность распределения.
Последовательность случайных чисел можно трактовать как последовательность координат в n-мероном пространстве. Насколько равномерно эти точки будут заполнять пространство?
Специалисты НАСА выбрали недостаточно случайный генератор случайных чисел для подсчёта интеграла методом Монте-Карло. В результате спутник промахнулся мимо Юпитера (iirc).
А для шифрования этот параметр не критичен. Даже если злоумышленник будет знать, что ваши случайные числа на 1% чаще будут попадать в верхнюю половину диапазона, это ему никак не поможет.

@noname664 · 15.12.2015, 17:10 **[ТС]**

Satorius, спасибо за ссылки.
Статью про "Вы опасно некомпетентны в криптографии" я уже изучил, там перечислены несколько векторов атаки, я их все учёл при разработке (разработка теоретическая в виде документации), это выражено хотя бы в том, что я использую специально написанные функции, которые используют одинаковое количество тактов, например при проверке Message Auth Code, для устранения атаки по времени. Далее я использую SHA-3, поскольку она устойчива к атаке на удлинение сообщения, а также многие другие вектора, их много. В частности, использование фиксированных заголовков вместо переменных исключает некоторые типы атак.

По поводу случайных чисел:
Мне нужен всего один ключ, все собранные случайные числа я собираюсь пропустить через хеш-функцию и получить таким образом всего один ключ, поэтому в силу специфики использования случайных чисел, мне не критично, насколько неравномерно распределение, необходимо и достаточно всего два условия:
1. Поток случайных чисел должен быть уникальным, т. е. вероятность получить один и тот же поток случайных чисел (бит в бит) должен быть не выше 2 в степени "длина ключа" (2^512). Это возможно, если в этом потоке будут хотя бы 512 случайных и не коррелируемых между собой бит, остальные биты могут быть любыми, они являются просто баластом. Тогда в силу свойства хеш-функции, будут получаться случайные выходные значения с вероятность повтора 1.25 * Sqrt(2^512), парадокс Дней Рождений. Если микрофон может породить не менее 2^512 различных потоков, тогда условие выполнено.
2. Не должно быть способа предсказать, какой может быть выходной поток. Если в этом потоке нельзя предсказать хотя бы 512 бит, а предсказать их нельзя, если эти биты и будут случайными, то условие будет выполнено.

Выполнение этих двух условий означает годность потока случайных чисел для получения одного ключа 512 бит.

И тут самое сложное, как доказать, что микрофон может выдать 2^512 различных выходных семплов качества 16 бит/48000 Гц моно, например длительностью 3 секунды. Длина этого потока 16 * 48000 * 1 * 3 = 2 304 000 бит, но может из этих бит почти все настолько часто повторяются, что уникальных (не совпадающих бит в бит) семплов всего несколько миллионов, а нужно минимум 2^512, я не знаю.

Если уникальных семплов очень мало, тогда их просто можно перебирать, пока не будет получен искомый ключ.

Вот хороший пример:
Представьте, что мы получаем ключ из системного времени UTC, прогоняем его через хеш-функцию.
На вид получили 512 бит, но получены они через UTC, а это число типа long long 64 бита. Достаточно их все перебрать и искомый ключ будет найдет.

Вопрос:
Может ли микрофон породить не менее 2^512 уникальных семплов качества 16 бит/48000 Гц моно длительностью например 5 секунд (длина этого семпла 3 840 000 бит) и насколько равнораспределена эта вероятность между всеми семплами?

@Satorius · 15.12.2015, 17:39

Умные "дядьки" из Википедии говорят, что для генерации случайных чисел сигнал от микрофона использовать можно, но сложно и дорого. Поэтому предлагают использовать источники энтропии.

Так что, ход ваших мыслей по методам получения случайных чисел, похоже, верный

Но обосновать это с математической точностью - вне моей компетенции.

@noname664 · 15.12.2015, 18:09 **[ТС]**

Объясню по-человечески, а то у меня вредная привычка расписывать на много строчек, а никто не любит читать много строчек:

Условимся, что параметры семпла 16 бит/48000 Гц моно длительность 5 сек.
Если микрофон может в теории записать 2^512 отличающихся друг от друга бит в бит семплов, то у нас множество из 2^512 вариантов (выборок), значит мощность выходного потока с микрофона не ниже мощности выходного потока хеш-функции 512 бит, она тоже может породить 2^512 вариантов выходного хеша.

И второе условие, если каждый семпл "выпадает" равновероятно из всего 2^512 множества всех семплов, тогда выходной поток с микрофона доказано годен для получения 512 битного ключа через хеш-функцию.

Хороший пример:
Допустим мы получаем ключ в виде хеша от введённой пользователем фразы.

Наше текстовое поле ограничено максимум 4 символа, только цифры.
Значит текстовое поле может породить только 10^4 выборок, это как бы первое условие выше.
Далее, очень часто пользователи пишут в текстовое поле "1234", "0000", "9999", "5678", значит выборки не равнораспределены, это второе условие выше.

Таким образом текстовое поле не годно для получения 512 битного ключа, потому что входная выборка всего 10^4 вариантов, из которых наиболее вероятные только 4 ("1234", "0000", "9999", "5678"), а должно быть не менее 2^512 выборок из которых все равновероятно распределены.

Добавлено через 3 минуты

Так что, ход ваших мыслей по методам получения случайных чисел, похоже, верный Но обосновать это с математической точностью - вне моей компетенции.

У меня тоже нет способа как это обосновать именно с математической точностью, согласен, это вопрос сложный и доказать это я не смогу точно, у меня нет знаний для этого.

Добавлено через 18 минут
И самая главная проблема, что я делаю именно теоретическую документацию и не могу просто так добавить в неё метод, не прошедший доказательство и анализ.
Единственно пригодный способ, который я могу безопасно использовать, это "ручной" способ, когда я кликаю мышью по экрану в разных местах и смотрю, чётная ли координата X и Y, а также чётное ли время клика в миллисекундах (по системному времени UTC) и всё это между собой "перексориваю" и так 512 раз (кликов).

@noname664 · 22.12.2015, 19:57 **[ТС]**

И последний способ изложу, и пожалуй забью на эту тему)

Кстати, тема выродилась в FAQ.

Способ теоретический, хотя...

Представим, что у нас есть сверхточный системный таймер, с точностью до пикосекунды (10^-12 = 0.000 000 000 001).
Например, делаем запрос текущего времени в ОС по клику мыши, а именно узнаём не текущую дату, время, час, а узнаём только текущее количество пикосекунд.
Получили например по запросу .988 756 334 012, ну чем не случайное число.
Первые 3 цифры не берём - это миллисекунды и они менее случайны, чем остальные цифры.
Значит за один клик мы получили целых "756 334 012" 9 случайных цифр, это за один клик мыши.
Это число умещается в переменную типа Int32, засунем его туда.
Далее, для создания 2^512 случайных бит нужно получить такую же по мощности выборку.
2^512 это число 1,3407807929942597099574024998206e+154, т. е. число состоящее из 154 + 1 цифр.
За один клик мы получили 9 цифр, а нужно всего 155, значит нужно сделать (155 / 9) + 1 = 18 кликов.

В принципе, если таймер менее точен, то по аналогии просто потребуется больше кликов.

Итак, мы получили 162 случайных цифры (18 кликов * 9 цифр), они помещены по 9 цифр в переменную Int32, что даёт размер входящих данных 18 * 4 = 72 байта, достаточных для получения 512 битного ключа, теперь осталось их просто прогнать через хеш-функцию и получить 512 битный ключ.

Вопрос исчерпан)

Добавлено через 18 минут
Написано "Далее, для создания 2^512 случайных бит нужно получить такую же по мощности выборку".
Следует читать "Далее, для создания 512 случайных бит нужно получить такую же по мощности выборку".

Новые блоги и статьи Все статьи Все блоги /
Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .	SDL3 для Web (WebAssembly): Сборка SDL3 и Box2D из исходников с помощью CMake и Emscripten 8Observer8 27.02.2026 Недавно вышла версия 3. 4. 2 библиотеки SDL3. На странице официальной релиза доступны исходники, готовые DLL (для x86, x64, arm64), а также библиотеки для разработки под Android, MinGW и Visual Studio. . . .	SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .
Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»

@Shamil1 Модератор 3136 / 2283 / 469 Регистрация: 26.03.2015 Сообщений: 8,885
	08.12.2015, 16:37
	А чем Вас не устраивают криптостойкие ГПСЧ? 0

@Satorius 14 / 14 / 8 Регистрация: 11.12.2015 Сообщений: 37
	15.12.2015, 06:02
	Я просто оставлю это здесь: Подробно о генераторах случайных и псевдослучайных чисел Вы опасно некомпетентны в криптографии 1

@noname664 Задачи выполнил, ушёл 27 / 30 / 7 Регистрация: 16.10.2015 Сообщений: 345
	15.12.2015, 17:10 [ТС]
	Satorius, спасибо за ссылки. Статью про "Вы опасно некомпетентны в криптографии" я уже изучил, там перечислены несколько векторов атаки, я их все учёл при разработке (разработка теоретическая в виде документации), это выражено хотя бы в том, что я использую специально написанные функции, которые используют одинаковое количество тактов, например при проверке Message Auth Code, для устранения атаки по времени. Далее я использую SHA-3, поскольку она устойчива к атаке на удлинение сообщения, а также многие другие вектора, их много. В частности, использование фиксированных заголовков вместо переменных исключает некоторые типы атак. По поводу случайных чисел: Мне нужен всего один ключ, все собранные случайные числа я собираюсь пропустить через хеш-функцию и получить таким образом всего один ключ, поэтому в силу специфики использования случайных чисел, мне не критично, насколько неравномерно распределение, необходимо и достаточно всего два условия: 1. Поток случайных чисел должен быть уникальным, т. е. вероятность получить один и тот же поток случайных чисел (бит в бит) должен быть не выше 2 в степени "длина ключа" (2^512). Это возможно, если в этом потоке будут хотя бы 512 случайных и не коррелируемых между собой бит, остальные биты могут быть любыми, они являются просто баластом. Тогда в силу свойства хеш-функции, будут получаться случайные выходные значения с вероятность повтора 1.25 * Sqrt(2^512), парадокс Дней Рождений. Если микрофон может породить не менее 2^512 различных потоков, тогда условие выполнено. 2. Не должно быть способа предсказать, какой может быть выходной поток. Если в этом потоке нельзя предсказать хотя бы 512 бит, а предсказать их нельзя, если эти биты и будут случайными, то условие будет выполнено. Выполнение этих двух условий означает годность потока случайных чисел для получения одного ключа 512 бит. И тут самое сложное, как доказать, что микрофон может выдать 2^512 различных выходных семплов качества 16 бит/48000 Гц моно, например длительностью 3 секунды. Длина этого потока 16 * 48000 * 1 * 3 = 2 304 000 бит, но может из этих бит почти все настолько часто повторяются, что уникальных (не совпадающих бит в бит) семплов всего несколько миллионов, а нужно минимум 2^512, я не знаю. Если уникальных семплов очень мало, тогда их просто можно перебирать, пока не будет получен искомый ключ. Вот хороший пример: Представьте, что мы получаем ключ из системного времени UTC, прогоняем его через хеш-функцию. На вид получили 512 бит, но получены они через UTC, а это число типа long long 64 бита. Достаточно их все перебрать и искомый ключ будет найдет. Вопрос: Может ли микрофон породить не менее 2^512 уникальных семплов качества 16 бит/48000 Гц моно длительностью например 5 секунд (длина этого семпла 3 840 000 бит) и насколько равнораспределена эта вероятность между всеми семплами? 0

@Satorius 14 / 14 / 8 Регистрация: 11.12.2015 Сообщений: 37
	15.12.2015, 17:39
	Умные "дядьки" из Википедии говорят, что для генерации случайных чисел сигнал от микрофона использовать можно, но сложно и дорого. Поэтому предлагают использовать источники энтропии. Так что, ход ваших мыслей по методам получения случайных чисел, похоже, верный Но обосновать это с математической точностью - вне моей компетенции. 0

@noname664 Задачи выполнил, ушёл 27 / 30 / 7 Регистрация: 16.10.2015 Сообщений: 345
	22.12.2015, 19:57 [ТС]
	И последний способ изложу, и пожалуй забью на эту тему) Кстати, тема выродилась в FAQ. Способ теоретический, хотя... Представим, что у нас есть сверхточный системный таймер, с точностью до пикосекунды (10^-12 = 0.000 000 000 001). Например, делаем запрос текущего времени в ОС по клику мыши, а именно узнаём не текущую дату, время, час, а узнаём только текущее количество пикосекунд. Получили например по запросу .988 756 334 012, ну чем не случайное число. Первые 3 цифры не берём - это миллисекунды и они менее случайны, чем остальные цифры. Значит за один клик мы получили целых "756 334 012" 9 случайных цифр, это за один клик мыши. Это число умещается в переменную типа Int32, засунем его туда. Далее, для создания 2^512 случайных бит нужно получить такую же по мощности выборку. 2^512 это число 1,3407807929942597099574024998206e+154, т. е. число состоящее из 154 + 1 цифр. За один клик мы получили 9 цифр, а нужно всего 155, значит нужно сделать (155 / 9) + 1 = 18 кликов. В принципе, если таймер менее точен, то по аналогии просто потребуется больше кликов. Итак, мы получили 162 случайных цифры (18 кликов * 9 цифр), они помещены по 9 цифр в переменную Int32, что даёт размер входящих данных 18 * 4 = 72 байта, достаточных для получения 512 битного ключа, теперь осталось их просто прогнать через хеш-функцию и получить 512 битный ключ. Вопрос исчерпан) Добавлено через 18 минут Написано "Далее, для создания 2^512 случайных бит нужно получить такую же по мощности выборку". Следует читать "Далее, для создания 512 случайных бит нужно получить такую же по мощности выборку". 0