Сообщение Re[6]: Случайный пароль от 20.05.2023 8:50
Изменено 20.05.2023 8:58 vsb
Re[6]: Случайный пароль
Здравствуйте, netch80, Вы писали:
vsb>>Берёшь остаток от деления на 64. Если результат меньше 36, возвращаешь его. Иначе генерируешь новое число. Способ простой и даёт равномерное распределение.
N>Только вот никто не гарантирует, что тебе на входе не поступят 100500 (или хотя бы 100) значений все которые дадут остаток 36 или больше. В результате алгоритм формально несходящийся, а на практике с неровными таймингами, через которые можно тоже что-то вычислить.
Если входной случайный генератор работает адекватно, то вероятность даже 10 итераций это < 1/2^10. Даже 20 это уже почти невероятно.
Если хочется убрать неровные тайминги, я бы предложил взять, к примеру, 6 * 64 битов, и в них найти первые 6 битов, которые меньше 33. И их выдать. А если таковых не нашлось, я бы вообще советовал сделать abort(), вероятность того, что исходный ГСЧ шпарит 0xff из-за бага, я бы оценил куда выше, чем вероятность того, что у нас произошло событие с вероятностью < 1/2^64. [Тут](https://github.com/vbezhenar/pwgen/blob/d902155b143202264d5f50e895545bddb298d530/pwgen.html#L303) я так и сделал (:
Про тайминги не понял, что через них можно вычислить. Вроде ничего нельзя. Ну да, ты понимаешь, что исходный случайный генератор выдал несколько чисел, у которых нижние биты слишком большие. Если это нормальный криптографический генератор, по идее из этого ты никаких выводов сделать не можешь.
vsb>>Берёшь остаток от деления на 64. Если результат меньше 36, возвращаешь его. Иначе генерируешь новое число. Способ простой и даёт равномерное распределение.
N>Только вот никто не гарантирует, что тебе на входе не поступят 100500 (или хотя бы 100) значений все которые дадут остаток 36 или больше. В результате алгоритм формально несходящийся, а на практике с неровными таймингами, через которые можно тоже что-то вычислить.
Если входной случайный генератор работает адекватно, то вероятность даже 10 итераций это < 1/2^10. Даже 20 это уже почти невероятно.
Если хочется убрать неровные тайминги, я бы предложил взять, к примеру, 6 * 64 битов, и в них найти первые 6 битов, которые меньше 33. И их выдать. А если таковых не нашлось, я бы вообще советовал сделать abort(), вероятность того, что исходный ГСЧ шпарит 0xff из-за бага, я бы оценил куда выше, чем вероятность того, что у нас произошло событие с вероятностью < 1/2^64. [Тут](https://github.com/vbezhenar/pwgen/blob/d902155b143202264d5f50e895545bddb298d530/pwgen.html#L303) я так и сделал (:
Про тайминги не понял, что через них можно вычислить. Вроде ничего нельзя. Ну да, ты понимаешь, что исходный случайный генератор выдал несколько чисел, у которых нижние биты слишком большие. Если это нормальный криптографический генератор, по идее из этого ты никаких выводов сделать не можешь.
Re[6]: Случайный пароль
Здравствуйте, netch80, Вы писали:
vsb>>Берёшь остаток от деления на 64. Если результат меньше 36, возвращаешь его. Иначе генерируешь новое число. Способ простой и даёт равномерное распределение.
N>Только вот никто не гарантирует, что тебе на входе не поступят 100500 (или хотя бы 100) значений все которые дадут остаток 36 или больше. В результате алгоритм формально несходящийся, а на практике с неровными таймингами, через которые можно тоже что-то вычислить.
Если входной случайный генератор работает адекватно, то вероятность даже 10 итераций это < 1/2^10. Даже 20 это уже почти невероятно.
Если хочется убрать неровные тайминги, я бы предложил взять, к примеру, 6 * 64 битов, и в них найти первые 6 битов, которые меньше 33. И их выдать. А если таковых не нашлось, я бы вообще советовал сделать abort(), вероятность того, что исходный ГСЧ шпарит 0xff из-за бага, я бы оценил куда выше, чем вероятность того, что у нас произошло событие с вероятностью < 1/2^64. Тут я так и сделал (:
Про тайминги не понял, что через них можно вычислить. Вроде ничего нельзя. Ну да, ты понимаешь, что исходный случайный генератор выдал несколько чисел, у которых нижние биты слишком большие. Если это нормальный криптографический генератор, по идее из этого ты никаких выводов сделать не можешь.
vsb>>Берёшь остаток от деления на 64. Если результат меньше 36, возвращаешь его. Иначе генерируешь новое число. Способ простой и даёт равномерное распределение.
N>Только вот никто не гарантирует, что тебе на входе не поступят 100500 (или хотя бы 100) значений все которые дадут остаток 36 или больше. В результате алгоритм формально несходящийся, а на практике с неровными таймингами, через которые можно тоже что-то вычислить.
Если входной случайный генератор работает адекватно, то вероятность даже 10 итераций это < 1/2^10. Даже 20 это уже почти невероятно.
Если хочется убрать неровные тайминги, я бы предложил взять, к примеру, 6 * 64 битов, и в них найти первые 6 битов, которые меньше 33. И их выдать. А если таковых не нашлось, я бы вообще советовал сделать abort(), вероятность того, что исходный ГСЧ шпарит 0xff из-за бага, я бы оценил куда выше, чем вероятность того, что у нас произошло событие с вероятностью < 1/2^64. Тут я так и сделал (:
Про тайминги не понял, что через них можно вычислить. Вроде ничего нельзя. Ну да, ты понимаешь, что исходный случайный генератор выдал несколько чисел, у которых нижние биты слишком большие. Если это нормальный криптографический генератор, по идее из этого ты никаких выводов сделать не можешь.