Есть ли оптимальный размер пакета для arc4random_buf? - PullRequest
Новая
       21

Есть ли оптимальный размер пакета для arc4random_buf?

0 голосов
/ 10 марта 2019

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

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

Я нахожусь на macOS, которая, к сожалению, с закрытым исходным кодом,поэтому я не могу просто прочитать исходный код.Есть ли какой-нибудь портативный способ определения оптимального X?

1 Ответ

2 голосов
/ 10 марта 2019

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

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

Реализация библиотеки FreeBSD, по-видимому, пытается оптимизировать путем периодического вычисления около 1 КБ случайных байтов.Затем arc4random_buffer использует memcpy для копирования байтов из внутреннего буфера в пользовательский буфер.

Для реализации FreeBSD оптимальным размером буфера будет объем данных, доступных во внутреннем буфере, потому что этоминимизирует количество звонков до memcpy.Однако нет способа узнать, сколько это будет, и оно не будет одинаковым при каждом вызове из-за алгоритма повторного ввода.

Я предполагаю, что вы обнаружите очень небольшую разницу между размерами буфера, превышающими, скажем, 16K, и, возможно, даже меньше.Для реализации FreeBSD будет немного более эффективно, если размер буфера будет кратен 8.

Добавление: все известные мне реализации имеют глобальный порог повторного переключения, поэтому вы не можете влиять настоимость повторного ввода путем изменения размера буфера в arc4random_buffer.Библиотека просто пересылает все сгенерированные байты X.

...