Действительно случайное число могло быть сгенерировано с помощью ping для псевдослучайным образом выбранных IP-адресов?

Я предполагаю, что Вы могли. Пара вещей не упустить:

• , Даже если проверка с помощью ping-запросов случайных IP-адресов, первые несколько транзитных участков (с Вас на первый реальный маршрутизатор L3 в сети ISP) будут тем же для каждого пакета. Это помещает нижнюю границу на круговую задержку даже при проверке с помощью ping-запросов чего-то в центре обработки данных в той первой Точке присутствия. Таким образом, необходимо быть осторожны относительно нормализации синхронизации, на распространении в прямом и обратном направлениях существует нижняя граница.
• необходимо было бы также быть осторожны относительно формирования трафика в сети. Типичная текучая реализация блока в маршрутизаторе выпускает байты N каждый микросекунды M, который эффективно тревожит Вашу синхронизацию в определенные временные интервалы, а не непрерывный диапазон времен. Таким образом, Вы, возможно, должны были бы отбросить биты низкоуровневые своей метки времени.

Однако я не согласился бы с предпосылкой, что нет хороших источников энтропии в потребительском оборудовании. Много x86 чипсетов в течение последних нескольких лет включали генераторы случайных чисел. Те я знаком с использованием относительно чувствительный ADCs, чтобы измерить температуру в двух различных местах на умирании и вычесть их. Биты низкоуровневые этого температурного дифференциала, как могут показывать, (через анализ В квадрате хи) решительно случайны. Поскольку Вы увеличиваете нагрузку обработки на систему, общая температура повышается, но дифференциал между двумя областями умирания остается некоррелированым и непредсказуемым.

Нет.

Отключают сетевой кабель (или /etc/init.d/networking stop), и энтропия в основном опускается до нуля.

Выполняют Атаку "отказ в обслуживании" на машине, которую она проверяет с помощью ping-запросов, и Вы также получаете предсказуемые результаты (значение тайм-аута ping)

Короткий ответ

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

Более длительная версия

, Насколько случайный времена ping?

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

Однако, в то время как синхронизация не будет хорошо распределена, там будет немного находиться на одном уровне случайности в данных. Или, другими словами, уровень информационная энтропия присутствует. Это - прекрасная идея подать данные синхронизации в генератор случайных чисел для отбора его. Таким образом, какой уровень энтропии присутствует?

данные синхронизации сети For говорят приблизительно 50 мс, измеренных к самому близкому 0,1 мс, с распространением значений 2 мс, у Вас есть приблизительно 20 значений. При округлении в меньшую сторону до самого близкого питания 2 (16 = 2^4) у Вас есть 4 бита энтропии на синхронизацию значения. Если бы это для какого-либо вида защищенного приложения (такого как генерация криптографических ключей) тогда, я был бы консервативен и сказал бы, что это были только 2 или 3 бита энтропии на чтение. (Отмечают, что я сделал очень грубую оценку здесь и проигнорировал возможность нападения).

, Как генерировать действительно случайные данные

Для истинных случайных чисел, необходимо отправить данные во что-то разработанное вроде /dev/random, который соберет энтропию, распределяя его в хранилище данных (использующий некоторый , хеш-функция , обычно защищают одну ). В то же время энтропийная оценка увеличена. Таким образом для ключа AES на 128 битов, 64 синхронизации ping требовались бы, прежде чем энтропийный пул имел достаточно энтропии.

, Чтобы быть более устойчивыми, Вы могли тогда добавить данные синхронизации из клавиатуры и использования мыши, время отклика жесткого диска, данные датчика материнской платы (например, температура), и т.д. Это увеличивает уровень энтропийного набора и сложно взломщику контролировать все источники энтропии. И действительно это - то, что сделано с современными системами. Полный список источников энтропии MS Windows перечислен в второй комментарий этого сообщения .

Для обсуждения (компьютерная безопасность) нападает на генераторах случайных чисел и дизайне криптографически безопасного генератора случайных чисел, Вы могли сделать хуже, чем чтение бумага тысячелистника Bruce Schneier и John Kelsey. (Тысячелистник используется BSD и системами Mac OS X).

Случайные числа слишком важны, чтобы быть оставленными случиться.

Или внешнее влияние/управление.

Случайность не является двоичным свойством - это - значение между 0 и 1, который описывает, как трудный это должно предсказать следующее значение в потоке.

Выяснение, "насколько случайный мои значения могут быть то, если я основываю их на ping?" на самом деле спрашивает, "насколько случайный ping?". Можно оценить это путем сбора достаточно большого набора данных (1 млн ping, например) и отображения их кривой распределения и поведения вовремя. Если распределение является плоским, и поведение трудно предсказать, данные кажутся более случайными. Более ухабистое распределение или предсказуемое поведение предлагают более низкую случайность.

необходимо также рассмотреть демонстрационное разрешение. Я мог вообразить результаты округленными в некотором роде к миллисекунде, таким образом, с ping у Вас могли быть целочисленные значения между 0 и 500. Это не большое разрешение.

На практической стороне, я рекомендовал бы против него, так как ping могут предсказываться и управляться, далее уменьшая их случайность.

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

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

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

    I MADE U A RANDOM NUMBER
           BUT I EATED IT

А, я нахожу, что этот вид вопроса ведет в дискуссии о значении 'действительно случайных' довольно быстро.

я думаю, что измерение ping привело бы к достойному качеству случайные биты, но на недостаточном уровне, чтобы иметь много применения (если Вы не были готовы сделать некоторый серьезный DDOSing).

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

(редактирование) На практической ноте, этот подход открывает Вас до возможности кого-то в Вашей сети, управляющей Вашим 'случайным' генератором чисел.

Это не кажется мне хорошим источником случайности.

, Что метрика была бы Вы использовать - очевидная является временем отклика, но диапазон значений, которые можно обоснованно ожидать, является маленьким: несколько десятков миллисекунд к нескольким тысячам. Само время отклика будет следовать за кривой нормального распределения и не будет случайным образом распределено через какой-либо интервал (как Вы выбрали бы интервал?), таким образом, необходимо было бы попытаться выбрать несколько 'случайных' битов из чисел.

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

существуют, вероятно, намного лучшие 'интересные' способы получить случайные биты - возможно, Google для случайного слова, захватывают первую страницу и выбирают Энный бит из страницы.

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

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

кроме того, даже если Вы сделали бы визуальный график 100 000 результатов и вычислили, что существует не или немного корреляций между числами, не означает, что это действительно случайно. Как объяснено Дилберт :)

Да, это возможно, но... дьявол в деталях.

, Если Вы собираетесь генерировать 32-разрядное целое число, необходимо собраться> 32 бита энтропии (и используйте достаточную функцию смешивания для получения того энтропийного распространения вокруг, но это знало и выполнимый). Большой вопрос, который является:

, сколько имеет энтропия времена ping?

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

, Если взломщики в состоянии полностью управлять временами ping, Вы получаете 0 битов энтропии на ping, и Вы никогда не можете составлять 32 бита энтропии, неважно, сколько Вы смешиваете. Если у них будут меньше, чем идеальное управление за времена ping, то Вы получите некоторую энтропию, и (если Вы не переоцените количество энтропии, Вы собираетесь), получит совершенно случайные 32-разрядные числа.

Я использовал бы что-то как ISAAC как более сильный PRNG прежде, чем доверять ping распространения в прямом и обратном направлениях как энтропии. Как другие сказали, это просто было бы слишком легко для кого-то к не, только предполагают Ваши числа, но также и возможно управляют ими до различных градусов.

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

я пошел 9 раундов с попыткой придумать сильное (и быстро) PRNG для клиент-серверного механизма RPC, который я писал. Обе стороны имели идентичный ключ, состоя из 1 024 строк 32 символьных шифров. Клиент отправил бы AUTH xx, сервер возвратит AUTH yy.. и обе стороны знали который две строки ключа использовать для создания секрета шифра (+ соль). Сервер тогда отправил бы обзор SHA-256 всего (зашифрованного) ключа, клиент знал, что он говорил с чем-то, что имело корректный ключ.. сессия продолжена. Да, очень слабая защита для человека в середине, но открытый ключ была вне рассмотрения для того, как устройство использовалось.

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

Так, должен спросить я относительно Вашей идеи.. насколько практичный это было бы?

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

См. Random.org для больше на случайности.

Вот попытка реализации:

@ips  : list = getIpAddresses();
@rnd         = PseudorandomNumberGenerator(0 to (ips.count - 1));

@getTrueRandomNumber() { ping(ips[rnd.nextNumber()]).averageTime }

Подход измерение чего-то для генерации случайного семени, кажется, довольно хороший. Книга O'Reilly Практический Unix и Защита в сети Интернет дает несколько подобных дополнительных методов определения случайного семени, таких как то, чтобы просить, чтобы пользователь ввел несколько нажатий клавиш и затем измерения времени между нажатиями клавиш. (Книга отмечает, что эта техника используется PGP в качестве источника своей случайности.)

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

Однако, вероятно, маловероятно, что внутренний датчик ЦП мог точно отмерить температуру ЦП к достаточным десятичным разрядам для создания значения действительно жизнеспособным как семя случайного числа; по крайней мере, не с "аппаратными средствами товарного класса", как упомянуто в вопросе!

Часть хорошего генератора случайных чисел является равными вероятностями всех чисел как n-> бесконечность.

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

я не слишком уверен с использованием ping, что Вы измерили бы для получения случайной переменной, он время отклика? Если так, можно быть вполне уверены, что некоторое время отклика или диапазоны времени отклика, будет более частым, чем другие и следовательно сделало бы потенциально небезопасный генератор случайных чисел.

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

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

Другие идеи включают синхронизацию теплового шума и низкого уровня строк кэша. Много современных ПК с микросхемами TPM имеют качественные аппаратные генераторы случайных чисел шифрования уже на борту.

Моя реакция коленного рефлекса проверить с помощью ping-запросов (особенно при использовании ICMP) состоит в том что обман слишком очевидно. В той точке Вы могли бы также выкрикнуть счетчик giger и использовать радиационный фон в качестве Вашего случайного источника.

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

Можно использовать метод XKCD:

У меня есть код, который создает случайные числа с помощью traceroute. Еще у меня есть программа, которая делает это с помощью ping. Я сделал это более года назад для классного проекта. Все, что он делает, - это запускает traceroute и адрес, и он берет наименьшую цифру из числа миллисекунд. Он довольно хорошо работает при получении случайных чисел, но я действительно не знаю, насколько он близок к истинному случайному.

Вот список из 8 чисел, который я получил, когда запустил его.

455298558263758292242406192

506117668905625112192115962

805206848215780261837105742

095116658289968138760389050

465024754117025737211084163

995116659108459780006127281

814216734206691405380713492

124216749135482109975241865

#include <iostream>
#include <string>
#include <stdio.h>
#include <cstdio>
#include <stdlib.h>
#include <vector>
#include <fstream>

using namespace std;

int main()
{
system("traceroute -w 5 www.google.com >> trace.txt");

string fname = "trace.txt";
ifstream in;
string temp;

vector<string> tracer;
vector<string> numbers;

in.open(fname.c_str());
while(in>>temp)
tracer.push_back(temp);

system("rm trace.txt");

unsigned index = 0;

string a = "ms";
while(index<tracer.size())
{
if(tracer[index]== a)
numbers.push_back(tracer[index-1]);
++index;
}


std::string rand;

for(unsigned i = 0 ; i < numbers.size() ; ++i)
{
std::string temp = numbers[i];
int index = temp.size();
rand += temp[index - 1];
}

cout<<rand<<endl;

return 0;

}

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

Идея веб-камеры звучит (немного) разумно. Пользователи Linux часто рекомендуют просто использовать случайный шум от звуковой карты, к которой не подключен микрофон.

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

YouTube показывает устройство в действии: http://www.youtube.com/watch?v=7n8LNxGbZbs

Случайно, если никто не может предсказать следующее состояние.

вот мое предложение:

1- выберите несколько веб-сайтов, которые находятся как можно дальше от вашего местоположения. например если вы находитесь в США, попробуйте некоторые веб-сайты, IP-адреса которых находятся в Малайзии, Китае, России, Индии и т. д. сервера с большим трафиком лучше.

2- во время высокого интернет-трафика в вашей стране (в моей стране это примерно с 19 до 23 часов) пингуйте эти веб-сайты много-много раз, возьмите каждый результат пинга (используйте только целочисленное значение) и вычислите модуль 2 это (т.е. от каждой операции ping вы получаете один бит: либо 0, либо 1).

3- повторить процесс в течение нескольких дней, записывая результаты.

4 - соберите все биты, которые вы получили из всех ваших пингов (возможно, вы получите сотни тысяч бит) и выберите из них свои биты. (возможно, вы захотите выбрать свои биты, используя некоторые данные из того же метода, упомянутого выше :))

БУДЬТЕ ОСТОРОЖНЫ: в вашем коде вы должны проверять тайм-аут .. и т. д.