Comments 16
По поводу «если HashMap не может быть инициализирован с помощью getrandom, он временно откатится на использование /dev/urandom, чтобы не блокироваться рано в процессе загрузки» — было бы неплохо иметь возможность управлять этим.
Для тех, кто не понял — о чём это всё. В Linux имеется такой файл /dev/urandom, который выдаёт криптографически стойкие случайные числа. Он, правда, имеет проблему: он их генерирует в любых количествах с использованием криптографически стойкого хеша. Всё бы хорошо — но эта схема требует-таки исходного криптойскойкого «зерна»! Если вы в криптохеш засунете в качестве зерна число 1, скажем, то всё что вы потом нагенерируете — будет весьма предсказуемо, никакой «волшебный» хеш не поможет! Новый системный вызов
Но оказалось, что в некоторых системах (виртуальные машины, в основном) энтропии в должном количестве просто нет! И там
Для тех, кто не понял — о чём это всё. В Linux имеется такой файл /dev/urandom, который выдаёт криптографически стойкие случайные числа. Он, правда, имеет проблему: он их генерирует в любых количествах с использованием криптографически стойкого хеша. Всё бы хорошо — но эта схема требует-таки исходного криптойскойкого «зерна»! Если вы в криптохеш засунете в качестве зерна число 1, скажем, то всё что вы потом нагенерируете — будет весьма предсказуемо, никакой «волшебный» хеш не поможет! Новый системный вызов
getrandom эту проблему решает: он действует почти как /dev/urandom — но при этом при начальной загрузке системы ждёт пока откуда-нибудь возьмётся энтропия (от дребезга клавиватуры или из файла «прикопанного» перед перезагрузкой — неважно).Но оказалось, что в некоторых системах (виртуальные машины, в основном) энтропии в должном количестве просто нет! И там
getrandom может очень долго ждать «у моря погоды». Чтобы решить эту и проблему использщуется /dev/urandom для инициализации хеша. Это — хорошо для всяких локальных скриптов, которые никто не планирует атаковать, но для каких-нибудь web-серверов — это уже не так здорово. Можно, конечно, завести утилиту, которая будет эту проблему «разруливать»…
было бы неплохо иметь возможность управлять этим
https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.with_hasher — это не оно?
Я не хочу руками для каждого хеша указывать хешер! Вариант через
Как я сказал: тут как бы хорошего ответа нет. Для 99.99% пользователей
getrandom — меня вполне устраивает! Но не через /dev/urandom — который работает почти так же, но о проблемах в котором вы сможете узнать только когда вас взломают.Как я сказал: тут как бы хорошего ответа нет. Для 99.99% пользователей
getrandom — лучший выбор. Но 0.01% «пострадавших» вопит так, что «крыша поднимается». Ok, уважили вы их. Но нельзя ли сделать так, чтобы большинство, которым эта, с позволения сказать, «оптимизация» нафиг не нужна могли хотя бы ключик задать? Почитайте комментарии в баге.
В коде до этого было:
libc::syscall(NR_GETRANDOM, buf.as_mut_ptr(), buf.len(), 0)что аналогично вызову
getrandom(buf, len, 0);Как нам рассказывает man 2 getrandom:
By default, getrandom() draws entropy from the /dev/urandom pool. This behavior can be changed via the flags argument.
Т. е. при использовании одного и того же пула энтропии /dev/urandom чтение из /dev/urandom не блокируется (т. е. используется PRNG), а getrandom — блокируется? Не могли бы вы рассказать подробнее почему так?
Потому что когда делали
/dev/urandom, то считалось что для «настоящей» криптухи люди будут использовать /dev/random — но потом выяснилось что это просто не работает: ну нет столько энтропии в компьютере, чтобы для сессионных ключей новую энтропию откуда-то находить! Соответственно все используют /dev/urandom, которого достаточно для всех случаев, кроме того, когда «начальной энтропии» ещё не накоплено достаточно — а чтобы этого случая избежать все дистрибутивы начинают загрузку переливая некоторое количество бит из сохранённого на диске пула (или из /dev/random) в /dev/urandom — но это костыль. А getrandom — современная замена. Или вы не нашли в описании соответствующих слов?By default, when reading from/dev/random,getrandom() blocks if no random bytes are available, and when reading from/dev/urandom, it blocks if the entropy pool has not yet been initialized.
Ну, HashMap — это всё-таки не криптография. В рамках данной задачи (создание хэшей для HashMap), даже если генератор случайных чисел будет некачественным, единственное, чем это может грозить — это потеря производительности. Да, можно организовать DoS-атаку, но это опять же, нужно очень постараться.
С одной стороны да, было бы неплохо, чтобы был флаг для управления источником рандома. С другой стороны, если так беспокоитесь о безопасности, можно и самому наполнить пул энтропии. Хотя в любом случае должен быть какой-нибудь warning, если берется заведомо некачественный генератор, банально чтобы обратить внимание админов и разработчиков к этой проблеме.
С одной стороны да, было бы неплохо, чтобы был флаг для управления источником рандома. С другой стороны, если так беспокоитесь о безопасности, можно и самому наполнить пул энтропии. Хотя в любом случае должен быть какой-нибудь warning, если берется заведомо некачественный генератор, банально чтобы обратить внимание админов и разработчиков к этой проблеме.
В рамках данной задачи (создание хэшей для HashMap), даже если генератор случайных чисел будет некачественным, единственное, чем это может грозить — это потеря производительности. Да, можно организовать DoS-атаку, но это опять же, нужно очень постараться.Зачем тогда вообще что-то рандомизировать, если нас это мало волнует с точки зрения безопасности. Проблема не в том, что эта проблема стоит остро или часто. Проблема в том, что при сегодняшней организации у вас нет ни малейших намёков нигде в логах о том, что «что-то пошло не так».
Хотя в любом случае должен быть какой-нибудь warning, если берется заведомо некачественный генератор, банально чтобы обратить внимание админов и разработчиков к этой проблеме.Это — тоже вариант. Похуже, чем ключ для неиспользования /dev/urandom, но тоже ничего. Но так как сейчас — это просто неправильно.
Когда добавят инкрементальную компиляцию? Видел пост Нико Матсакиса, что вот вот, но это было пару месяцев назад.
Я не припомню (и не могу нагуглить) утверждений про "вот вот", но в текущей ночной сборке вижу опцию "-Z incremental=val — enable incremental compilation (experimental)".
И вроде даже получилось несколько проектов собрать при помощи вызова "cargo rustc — -Z incremental=tmpdir", но пару раз оно грохнулось с ошибкой внутри rustc — видимо, еще достаточно сырое.
Sign up to leave a comment.
Анонс Rust 1.10