Бумажный кошелек, сгенерированный на стороне клиента и вне сети, не обязательно безопасен [дубликат]

Можно было бы подумать, что если человек сгенерирует закрытый ключ на стороне клиента и никогда не выставит этот ключ в Интернет, он будет в безопасности. Однако риск заключается в том, что код генерации бумажного кошелька скомпрометирован и предоставляет жертве закрытые ключи, которые уже известны злоумышленнику. Как лучше снизить этот риск?

Ответы (1)

Вы можете сгенерировать случайные биты самостоятельно, чтобы устранить возможные слабые места / бэкдоры в автономном генераторе кошелька. Например, бросьте кости 100 раз, запишите последовательность и используйте хэш SHA256 в качестве закрытого ключа. Или, если у вас нет игральных костей, подбросьте монету 256 раз.

Как самостоятельное создание битов «устраняет бэкдоры»? Вам все еще нужно использовать чужое программное обеспечение, верно?
Вы никогда не сможете быть уверены на 100%, если не выполните умножение точек EC и SHA256+RIPEMD вручную. Даже компилятор и ЦП могут иметь лазейки. Но слабость RNG является наиболее распространенной и эксплуатируемой.
Слабость ГСЧ наиболее распространена? Можете ли вы обосновать, что это основной риск? Мне кажется, что большинство потерь не из-за слабости RNG, хотя проблема с Android RNG была. Это было быстро исправлено. Мне кажется, что большинство убытков — это простая кража, когда люди не контролируют свои приватные ключи. Недавние сбои обмена являются тому примером. Там пропало огромное количество.
@Brad - я никогда не говорил, что слабость ГСЧ наиболее распространена в целом. Но это наиболее вероятный бэкдор в конкретном случае «бумажного кошелька, сгенерированного на стороне клиента и за пределами сети», потому что нет другого мыслимого канала, через который может происходить утечка информации. Ваши примеры относительно сбоев обмена не имеют значения.
Послушайте, автономный генератор кошелька предназначен для выполнения некоторых хорошо известных функций, таких как умножение точек EC, хэш SHA256 + RIPEMD и кодирование Base58Check. Существует множество эталонных реализаций с открытым исходным кодом, с которыми можно сравнить. За исключением слабости ГСЧ, ошибка в программной реализации в худшем случае просто сделает сгенерированный ключ непригодным для использования.