Здравствуйте, TailWind, Вы писали:
TW>Как сделать случайный пароль на 24 символа? TW>И потом ещё один такой же
Набрать энтропии откуда-то, получить криптографический хэш какой-нибудь
или даже лучше HMAC (что-то типа KDF_GOSTR3411_2012_256).
Потом кодировать в base64 и отрезать 24 байта.
Откуда набрать качественной энтропии — вопрос...
Так-то желательно иметь нормальный CSP.
В линухе можно, как уже написали, читать /dev/urandom.
Насчет биологического датчика энтропии для гпсч (типа клавиатуру нажимать, мышью двигать)...
Там чтобы нормально энтропию набрать, специальные алгоритмы применяются.
У нас они проверены и сертифицированы фсб.
Но если что-то из интернетов навскидку... можно скачать сорцы TrueCrypt там вроде была рулетка.
З.Ы. не знаю насколько это может быть корректно.
Можно попробовать набрать плохой энтропии.
Попросить пользователя ввести несколько символов, добавить данные rdtsc, времени.
Потом из этого выработать ключ по PBKDF2, ключ кодировать в base64 и откусить нужный кусок.
Если юзать отечественную криптографию то там PRF будет — все тот же HMAC на гостовском хэше.
Здравствуйте, ·, Вы писали:
n>> Я вот проверил: Ubuntu 20.04, системный GCC. И что вы таки себе думаете — он включает встроенный в этот самый random_device... ещё один Mersenne Twister! И никакого /dev/random не читает. Картина Пикассо. ·>Странно. По крайней мере, вроде может. В исходниках он пытается что-то подоборать ·>https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/src/c++11/random.cc#L330 ·>Может он напрямую из CPU берёт?
Ты прав, а я запутался в отладчике. Он, оказалось, через RDRAND берёт данные.
·>И, вроде, у него есть метод entropy, которым честность случайности.
Здравствуйте, vsb, Вы писали:
vsb>Там грабля не совсем в этом была, грабля была в том, что /dev/random раньше мог блокироваться, если его кто-то активно вычитывал, а источники энтропии закончились. /dev/random читается именно на старте программы и это могло этот старт заморозить на неопределённое время.
vsb>Но в современном линуксе это исправили и там /dev/random и /dev/urandom по сути одинаковые.
Угу, в ванильке где-то с 5.12.
vsb>Про другие *nix не знаю.
FreeBSD так работала примерно с 2001-го. MacOS повторила её подход. Чем в Linux думали — не знаю, там в условном core team пачка настолько упрямых ослов была, что цензурных слов не было.
Здравствуйте, netch80, Вы писали:
n> Ты прав, а я запутался в отладчике. Он, оказалось, через RDRAND берёт данные.
n> ·>И, вроде, у него есть метод entropy, которым честность случайности. n> Так оно бы не помогло.
В смысле? Прога может проверять энтропию, и если 0 (что выдаётся в случае плохого prng источника), то сказать пользователю "извините, не шмогла" или подобное.
Трахаться с полу-стандартным winapi, подстраиваться под разные версии винды... как-то бессмысленно, когда это давно решили разработчики stdlib.
Здравствуйте, ·, Вы писали:
n>> ·>И, вроде, у него есть метод entropy, которым честность случайности. n>> Так оно бы не помогло. ·>В смысле? Прога может проверять энтропию, и если 0 (что выдаётся в случае плохого prng источника), то сказать пользователю "извините, не шмогла" или подобное.
Если бы оно само генерировало каким-то псевдоГСЧ, то с энтропией было бы всё в порядке, о чём бы оно честно и сказало.
·>Трахаться с полу-стандартным winapi, подстраиваться под разные версии винды... как-то бессмысленно, когда это давно решили разработчики stdlib.
Здравствуйте, netch80, Вы писали:
n> ·>В смысле? Прога может проверять энтропию, и если 0 (что выдаётся в случае плохого prng источника), то сказать пользователю "извините, не шмогла" или подобное. n> Если бы оно само генерировало каким-то псевдоГСЧ, то с энтропией было бы всё в порядке, о чём бы оно честно и сказало.
Опять же отправлю к тому же исходнику: case prng: return 0.0;.
n> ·>Трахаться с полу-стандартным winapi, подстраиваться под разные версии винды... как-то бессмысленно, когда это давно решили разработчики stdlib. n> В какой из полдесятка сборок?
Я не говорю, что это суперуниверсальное всемогучее решение всех проблем. Но это решение лучше по многим параметрам, чем предложенные тут альтернативы в виде cryptoapi и доморощенные алгоритмы.
Здравствуйте, TailWind, Вы писали:
TW>Не очень понятно как из этого сделать равномерное распределение TW>Проблема с rand() в том, что она повторяется каждые 3fff байт
так у вас от пользователя куча рандомных данных. Можно перед каждым вызовом rand задавать затравку. Да и в таком подходе rand не особо то и нужен. Фактически берёте от пользователя случайную последовательность, смешиваете с временной меткой и хешируете в своё удовольствие. Каждый следующий символ практически случаен.
SP>так у вас от пользователя куча рандомных данных
Мышка и клавиатура не рандомные
С большой вероятностью вы будите тыкать в клавиатуру по очереди правой и левой рукой
Правая рука будет тыкать чаще справа, левая слева
Наберите статистику на 100000 таких вводов и получите распределение наиболее вероятных комбинаций
Здравствуйте, TailWind, Вы писали:
SP>>так у вас от пользователя куча рандомных данных
TW>Мышка и клавиатура не рандомные TW>С большой вероятностью вы будите тыкать в клавиатуру по очереди правой и левой рукой TW>Правая рука будет тыкать чаще справа, левая слева
Когда говорится о таких данных, имеется в виду что-то вроде дробной части миллисекунды момента получения прерывания от клавиатуры/мыши с точностью до, например, 10 нс. А не какая клавиша и какой рукой нажата.
Но этой энтропии таки недостаточно, иначе бы всякие RDRAND не изобретали бы.
Здравствуйте, TailWind, Вы писали:
TW>Чем их измерять то, эти 10 нс?
RDTSC, RDTSCP считают до такта процессора, а это с частотой >=1GHz менее наносекунды.
HPET или APIC timer позволяют до 40-90 нс, это тоже неплохо (но к ним так просто не подобраться, если ОС не замапила их всем на чтение).
Здравствуйте, TailWind, Вы писали:
TW>Как сделать случайный пароль на 24 символа? TW>И потом ещё один такой же
TW>Нужно чтобы между символами и паролями не было математической зависимости
TW>То есть rand(), rand(), rand(), rand() не подходит
TW>Единственное, что мне пришло в голову rand(GetTickCount()) TW>Но этого мало. А дальше то как?
вся или почти вся(если строго) криптография основана на том, что злоумышленник знает все алгоритмы
так что исходить нужно из этого
