/ dev / random Очень медленно?
Вы не можете, не без большого кропотливого ручного определения часового пояса.
Python не включает базу данных часового пояса, потому что она будет устаревать слишком быстро. Вместо этого Python полагается на внешние библиотеки, которые могут иметь гораздо более быстрый цикл выпуска, чтобы обеспечить вам правильно настроенные часовые пояса.
В качестве побочного эффекта это означает, что разметка часового пояса также должна быть внешняя библиотека. Если dateutil слишком тяжелый для вас, вместо этого используйте iso8601 , он отлично разбирает ваш конкретный формат:
>>> import iso8601
>>> iso8601.parse_date('2012-11-01T04:16:13-04:00')
datetime.datetime(2012, 11, 1, 4, 16, 13, tzinfo=)
iso8601 является whopping 4KB маленький. Сравните этот файл python-dateutil с 148 КБ.
Начиная с Python 3.2 Python может обрабатывать простые временные интервалы на основе смещения, а %z будет анализировать -hhmm и +hhmm временные смещения в метке времени. Это означает, что для метки времени ISO 8601 вам нужно будет удалить : в часовом поясе:
>>> from datetime import datetime
>>> iso_ts = '2012-11-01T04:16:13-04:00'
>>> datetime.strptime(''.join(iso_ts.rsplit(':', 1)), '%Y-%m-%dT%H:%M:%S%z')
datetime.datetime(2012, 11, 1, 4, 16, 13, tzinfo=datetime.timezone(datetime.timedelta(-1, 72000)))
Отсутствие правильного синтаксического анализа ISO 8601 отслеживается в Python issue 15873 .
5 ответов
В большинстве систем Linux /dev/random работает на основе реальной энтропии, собранной средой. Если ваша система не доставляет большой объем данных из /dev/random, это, вероятно, означает, что вы не генерируете достаточно случайную окружающую среду, чтобы привести ее в действие.
Я не уверен, почему вы думаете /dev/urandom «медленнее» или более высокого качества. Он повторно использует внутренний пул энтропии для генерации псевдослучайности - что делает его немного более низким качеством - но он не блокирует. Как правило, приложения, которые не требуют высокоуровневой или долгосрочной криптографии, могут надежно использовать /dev/urandom.
Попробуйте немного подождать, а затем снова читать из /dev/urandom. Вполне возможно, что вы исчерпали так много внутреннего чтения пулов энтропии из /dev/random, сломав оба генератора - чтобы ваша система могла создавать больше энтропии, их нужно пополнить.
См. Википедию для получения дополнительной информации о /dev/random и /dev/urandom.
Это исправило это для меня. Используйте новый SecureRandom () вместо SecureRandom.getInstanceStrong ()
Дополнительную информацию можно найти здесь: https://tersesystems.com/blog/2015/12/17/the-right-way -в-использование-SecureRandom /
Вы можете использовать rngd из пакета rng-utils на большинстве дистрибутивов Linux, чтобы получить больше случайных данных. Например, на fedora 18 все, что мне нужно было сделать, чтобы разрешить заполнение из TPM и CPU RNG (инструкция RDRAND), было:
# systemctl enable rngd
# systemctl start rngd
Вы можете сравнить скорость с и без rngd. Это хорошая идея запустить rngd -v -f из командной строки. Это покажет вам обнаруженные источники энтропии. Убедитесь, что все необходимые модули для поддержки ваших источников загружены. Чтобы использовать TPM, его нужно активировать через tpm-tools. Обновление : вот хорошая инструкция .
Кстати, я читал в Интернете некоторые опасения по поводу того, что TPM RNG часто ломается по-разному, но не читал ничего конкретного против RNG, обнаруженного в чипах Intel, AMD и VIA. Использование более одного источника было бы лучше, если вы действительно заботитесь о качестве случайности.
urandom подходит для большинства случаев использования (за исключением случаев, когда во время начальной загрузки). В настоящее время большинство программ используют случайный, а не случайный. Даже openssl делает это . См. мифы об урандоме и , сравнение случайных интерфейсов .
В недавних Fedora и RHEL / CentOS rng-tools также поддерживают энтропию джиттера . Вы можете сделать это из-за отсутствия аппаратных опций или если вы просто доверяете этому больше, чем своему аппаратному обеспечению.
ОБНОВЛЕНИЕ: другой вариант для большей энтропии - HAVEGED (сомнительное качество). На виртуальных машинах есть kvm / qemu VirtIORNG (рекомендуется).
использовать / dev / urandom, это криптографически безопасно.
хорошо прочитано: http://www.2uo.de/myths-about-urandom/
«Если вы не уверены, следует ли использовать / dev / random или / dev / urandom, тогда, вероятно, вы захотите использовать последний. "
Если вы сомневаетесь в ранней загрузке, достаточно ли у вас энтропии. вместо этого используйте системный вызов getrandom(). [1] Это лучший из обоих миров,
- он блокирует, пока (только один раз!) Не соберет достаточно энтропии,
- после этого он никогда не будет блокироваться снова.
Если вы хотите больше энтропии для /dev/random, то вам нужно либо купить аппаратный ГСЧ, либо использовать один из * _ энтропидных демонов для его генерации.