Я делаю это (не) уязвимость населения, так как я совершенно уверен, что нет непосредственной опасности, но исходный код должен быть изменен основным Dev-Team для следующей версии.
В клиенте Bitcoin Windows, энтропия обеспечивается:
1. RAND_Screen при инициализации (в util.cpp)
2. Периодические вызовы на RandAddSeedPerfmon ()
Но второй метод может представить две проблемы:
А. RandAddSeedPerfmon () вызывает RandAddSeed (), который вызывает QueryPerformanceCounter (), который получает метку времени приблизительно с 25 битами реальной энтропии (так как приложения-службы, как правило, выполняются при запуске компьютера). Но QueryPerformanceCounter () требует аргумент быть QWORD выровненный, и я не уверен, что если GCC выравнивает к границам 8 байт (я думаю, что выравнивание по 4 байта). Так что, может быть, вызов иногда не удается спокойно, и эти энтропийные биты никогда не возвращаются.
B. RandAddSeedPerfmon () вызывает RegQueryValueExA (HKEY_PERFORMANCE_DATA, "Глобальный" с фиксированным размером буфера 250000. Если возвращаемые данные больше, чем этот буфер, он терпит неудачу. Но в моем XP (и, вероятно, во многих других системах) возвращаемые данные около 280 Кб, поэтому эта функция не может спокойно.
В конце концов, единственный источник случайных может быть RAND_Screen, без энтропии пересева происходит.
Обратите внимание, что первая пара ключей создается с помощью всего двух вызовов RandAddSeedPerfmon (), так что можно было бы предположить, ключи, если RAND_Screen не будет достаточно сильным. (К счастью, в XP и выше).
Проблема, которую я вижу, что нет ничего регистрируется в файле debug.log или сообщения сообщает пользователю, что он может быть генерирующий слабые ключи. Обе неудача QueryPerformanceCounter () и RegQueryValueExA должна быть зарегистрирована, а пользователь должен быть встревожен.
К Dev-Team: пожалуйста, не удаляйте RAND_Screen (интересный разговор на http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/06/04)
С наилучшими пожеланиями,
Серхио.
PS: Поздравляем Гэвин для Bitcoin Foundation!
|
|
||||||
27 сентября 2012, 6:35:37 PM
|
# 1 |
Сообщения: 539
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru |
|
|
|
Как заработать Биткоины?
Без вложений. Не майнинг.
|
27 сентября 2012, 7:22:47 PM
|
# 2 |
|
Сообщения: 1526
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Получил 1806 Биткоинов
Реальная история. Пары ключей генерируются OpenSSL, который имеет свой собственный код для получения энтропии от хост-системы. Вы уверены, что ваши выводы верны?
|
|
|
|
|
27 сентября 2012, 8:01:22 PM
|
# 3 |
|
Сообщения: 1652
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Есть хороший открытый исходный кусок кода, который мы можем использовать, чтобы проверить, чтобы убедиться, что мы генерировать хорошую энтропию?
Эти ошибки должны быть исследованы и фиксированной (Sergio вы можете открытые вопросы, на GitHub?), Но я хотел бы тест мы могли периодически работать, чтобы убедиться, что они остаются неподвижными. Еще лучше, если код может контролировать себя и позволить пользователю знать, если есть проблема с генерацией энтропии. |
|
|
|
|
27 сентября 2012, 8:42:02 PM
|
# 4 |
|
Сообщения: 539
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Пары ключей генерируются OpenSSL, который имеет свой собственный код для получения энтропии от хост-системы. Вы уверены, что ваши выводы верны? Да, как я уже сказал: RAND_Screen кажется достаточно сильным. (Проверьте OpenSSL код на OpenSSL-1.0.1c \ криптографической \ рандов \ rand_win.c) OpenSSL не добавляет дополнительную энтропию сам по себе: пользователь должен вызвать RAND_poll () периодически. Только первые RAND_Bytes время называется OpenSSL вызывает RAND_poll (). |
|
|
|
|
27 сентября 2012, 9:03:45 PM
|
# 5 |
|
Сообщения: 539
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Есть хороший открытый исходный кусок кода, который мы можем использовать, чтобы проверить, чтобы убедиться, что мы генерировать хорошую энтропию? Эти ошибки должны быть исследованы и фиксированной (Sergio вы можете открытые вопросы, на GitHub?), Но я хотел бы тест мы могли периодически работать, чтобы убедиться, что они остаются неподвижными. Еще лучше, если код может контролировать себя и позволить пользователю знать, если есть проблема с генерацией энтропии. Вы можете запустить DIEHARD тесты (http://en.wikipedia.org/wiki/Diehard_tests), Но они не будут обнаруживать низкую энтропию, если вы не генерировать терабайты данных для тестирования. Я не думаю, что это будет работать. Я уже говорил, так как RAND_Screen называет CryptGenRandom (), который, как предполагается, должен быть сильным, энтропия должна быть достаточно. Но опять-таки! OpenSSL не будет говорить функции вызывающего абонента, если CryptAcquireContext () терпит неудачу и так CryptGenRandom () никогда не вызывается. Я не знаю, как CryptAcquireContext () может потерпеть неудачу, но есть так много кодов ошибок неудачи, что я предполагаю, что это будет не в состоянии иногда! (Я бы предпочел отказоустойчивые семантику, которая информирует пользователя о фактической энтропии приобретенной для RAND_Screen) (проверить http://msdn.microsoft.com/en-us/library/windows/desktop/aa379886%28v=vs.85%29.aspx) Лучшее решение, которое я могу думать о том, чтобы уведомить пользователя, если код энтропии поколения не работает. Обратите внимание, что Bitcoind работает в Windows 2000 или более ранних версий, вероятно, страдает от недостатка энтропии, но я думаю, что Win2K не поддерживается. |
|
|
|
|
28 сентября 2012, 1:41:36 AM
|
# 6 |
|
Сообщения: 1106
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
OpenSSL реализует сильный ПСЧ на основе пула случайных чисел, поэтому в дополнение к другой энтропии сбора почему мы не инициализировать генератор случайных чисел при запуске со всеми секретными ключами в кошельке? Это было бы достаточно эффективно действовать в качестве постоянного источника энтропии с защитой так же хорошо, как бумажник он пытается защитить в первую очередь. Это также совершенно безопасно:
котировка При использовании данных семян состояния ГСЧА, данные, используемые не должен быть экстрагируемыми из состояния ГСЧА. Я считаю, что это должно быть требование, потому что один возможный источник «секретных» полу случайных данных будет секретный ключ или пароль. Эти данные не должны быть раскрыты либо последующими случайными числами или «основной» свалкой, оставленных к аварийному завершению программы. http://www.openssl.org/docs/crypto/rand.htmlкак данные, добавленные хешируется в бассейн с использованием криптографически сильной хэш-функции. Одинаково хэширования в дешифрования пароля пользователя, если кошелек зашифрован, также безопасен. Конечно, это не произойдет до тех пор, бумажник не расшифрован, но случайные байты не нужны до тех пор, пока бумажник дешифрование в любом случае. Даже с действительно сломанной источник энтропии, вы будете в конечном итоге накапливается достаточно, чтобы последующие ключи безопасны. Кроме того, если мы случайно выпустить версию со сломанным источником, который не будет сразу разорвать генерацию ключей для пользователей, которые уже имеют бумажник. Я мог бы приготовить патч через некоторое время после следующей недели, если никто не бьет меня тоже. Edit: приходите думать об этом, если люди обеспокоены тем, что вставка пары ключей может каким-то образом просачиваться данные в случае перерыва в библиотеке OpenSSL или что-то, вставить половину каждого ключа, то же половину каждый раз. Даже взлом ключа с половиной бит известен примерно грозная 2 ^ 128 проблема. Я не знаю точно, как работает ключ формата ECC, поэтому, возможно, я должен выбрать конкретные биты, любое представление о том, что? |
|
|
|
|
28 сентября 2012, 4:22:28 AM
|
# 7 |
Сообщения: 1302
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Эмм. Общий принцип в криптографии не использовать ту же энтропию в два раза, если возможно, вы можете избежать этого.
Кроме того, если у вас есть проблемы с источником энтропии, питающей, что низкая входной энтропией назад в не кажется, что это поможет много. |
|
|
|
|
28 сентября 2012, 5:46:12 AM
|
# 8 |
|
Сообщения: 1106
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Эмм. Общий принцип в криптографии не использовать ту же энтропию в два раза, если возможно, вы можете избежать этого. Кроме того, если у вас есть проблемы с источником энтропии, питающей, что низкая входной энтропией назад в не кажется, что это поможет много. Дело в том, с правильной реализации пул энтропии добавления в данных с нулевой энтропией является безопасно, и любая энтропия, однако мало, накапливается. Давайте предположим, что я "бассейн" ровно два бита данных. Мы начинаем с ним в известном состоянии: 00 Я добавлю это дополнительные источники энтропии с помощью XOR. Во-первых, давайте добавим два бита из сломанного источника энтропии, который выводит все из них: 00 XOR 11 = 11 В основном этот источник несколько раз просто переворачивается биты от одного к другому. Тем не менее, теперь я собираюсь добавить в качестве источника энтропии, где первый бит разбивается, но второй бит действительно случайный: 00 исключающее 11 исключающее 1? = 0? Атакующий может выяснить первый бит, но не второй. Добавим, что полностью сломана источник энтропии снова: 00 исключающее 11 исключающее 1? XOR 11 = 1? Атакующий * еще * не может угадать второй бит. Теперь давайте добавим источник энтропии со вторым битом разбитым, но первого бита OK: 00 исключающее 11 исключающее 1? XOR 11 XOR? 1 = ?? Полностью случайный. Точно так же в Bitcoin, если взять все частные ключи в хранилище ключей, XOR их вместе, чтобы создать семя, вы будете иметь по крайней мере столько же энтропию в этом семени, как любой один ключ в вашем хранилище содержит. Если все, что вы сделали хэш, что семена для создания вашего следующего ключа и сохранили этот ключ, XORing все ваши личные ключи вместе будет все еще производить семена с таким же количеством энтропии. По умолчанию используется метод случайного пула OpenSSL, в RAND_SSLeay в криптографическом / рандах / md_rand.c, работает в своем роде подобных же образом. Данные добавляются в пул хешируются, а затем добавляют к вращающемуся набору из нескольких блоков. Если вы хотите несколько байт, эти блоки получают операции XOR вместе в состояние, а хэш этого состояния возвращаются к абоненту. (Эр, примерно в любом случае, я мог бы что-то пропустил чтение исходного кода) Этот файл также где проект Debian облажался и сломал генерацию ключей SSL несколько лет назад ... Мы действительно хотим, чтобы избежать подобной ошибки любой ценой. Bitcoin на системах Debian в 2008 году, возможно, оставили свои личные ключи угадываемы. http://en.wikipedia.org/wiki/Fortuna_(PRNG) хорошее объяснение другого хорошего ПСЧ, с доказательных ограничениями на сколько времени требуется, чтобы вернуться к защищенной системе после компрометации ключа. Во всяком случае, я написал действительно грубые примечания / набросал код, как вы бы на самом деле реализовать эту идею: https://github.com/petertodd/bitcoin/blob/devel.persistent-seed/persistent-seed-notes.txt |
|
|
|
|
28 сентября 2012, 12:06:39 PM
|
# 9 |
|
Сообщения: 676
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Некоторое время назад я смотрел на наш RandAddSeed () - функции и пришли к такому же выводу, что улей реестра вещь с данными перфорация не самое лучшее, что мы могли бы сделать, как MS CryptoAPI предлагает функцию генерации случайных данных (которые используется OpenSSL в любом случае), с лучшими источниками энтропии (хотя это функция МС с закрытым исходным кодом).
Ниже моя версия RandAddSeed (), который заменяет RandAddSeedPerfmon () и всегда используется тогда. Код: аннулированию RandAddSeed () { Int64 nStart = 0; если (fDebug) nStart = GetTimeMillis (); // Семя со счетчиком производительности процессора Int64 nCounter = GetPerformanceCounter (); RAND_add (&nCounter, SizeOf (nCounter), 1.5); MemSet (&nCounter, 0, SizeOf (nCounter)); #ifdef WIN32 HCRYPTPROV hCryptProv; символ без знака PDATA [250000]; MemSet (PDATA, 0, SizeOf (PDATA)); без знака длиной nРазмер: = SizeOf (PDATA); если (CryptAcquireContext (&hCryptProv, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)) { // заполняет PDATA с криптографически случайными байтами если (CryptGenRandom (hCryptProv, nРазмер:, PDATA)) { RAND_add (PDATA, nРазмер:, nРазмер: / 100,0); MemSet (PDATA, 0, nРазмер:); если (fDebug) Е ("RandAddSeed ()% D байт в%"PRI64d"мс \ п", NРазмер:, GetTimeMillis () - nStart); } CryptReleaseContext (hCryptProv, 0); } #endif } Вот небольшая скамейка сравнения: старый: RandAddSeedPerfmon () 198396 байт 1548ms новый (MS CryptoAPI): RandAddSeed () 250000 байт 16мс Edit 1: После вашего чтения я теперь уверен, что лучше не думать об удалении RAND_screen (!) диаметр |
|
|
|
|
28 сентября 2012, 1:02:02 PM
|
# 10 |
|
Сообщения: 1890
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Во многих криптографических программ (даже для Windows) они просят пользователей, чтобы помочь семени путем сбора движений мыши и клавиатурного ввода. Если Bitcoin клиент может использовать файл в качестве затравки (параметров командной строки, может быть), то мы можем создать файл только для этой цели, используя множество доступных генерации паролей инструментов, или хэша случайного снимка с камеры, направленным на небе , (Или даже видео файл.)
Это одна будет расширенная функция или функция пользователя питания. |
|
|
|
|
28 сентября 2012, 1:49:52 PM
|
# 11 |
Сообщения: 539
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Это мои мнения (которые более основаны на интуиции и опыте, чем на теоретических основаниях, что я могу назвать).
Они основаны на том, как система будет реагировать на выход из строя одного из компонентов, как контроль повреждения. 1. Не добавляйте частные ключи ECC в качестве случайного источника. Неудача в OpenSSL случайного пуле будет означать утечку секретных ключей в качестве нового вектора атаки. 2. Используйте простой бассейн файл состояния, с RAND_load_file (). Первый раз Bitcoin запускается, собирать энтропию из нажатых клавиш и сохранить эту энтропию в файл состояние. Смешать энтропии файл состояния с текущим состоянием пула каждый раз при запуске приложения. 3. Не XOR закрытые ключи ECC. Свойства XOR над полем ЕС не были проанализированы. Хеширования их вместе было бы лучше. Тем не менее, если состояние файла используется, это не является необходимым. 4. Если половина секретного ключа ECC раскрывается, возможно, что полный ключ скомпрометирован. Это происходит во многих теоретико-числовых шифров и алгоритмов подписи. Половина закрытый ключ не половина безопасности. 5. Вызов RAND_event () каждый раз, когда мы обрабатываем сообщение Windows. 6. Оставьте RAND_Screen где (Он не может причинить никакого вреда). Поскольку первый вызов RAND_bytes вызывает RAND_Poll, RAND_Screen не является строго необходимым. (видеть http://security.stackexchange.com/questions/7718/openssl-rand-poll-good-enough ) Мне нравится Diapolo код, но приложение должно сообщить пользователю или прекратить, если CryptAcquireContext не удается. 250000 байт, вероятно, не требуется. Всего 64 байт (как в OpenSSL) будет нормально. |
|
|
|
|
28 сентября 2012, 1:53:58 PM
|
# 12 |
|
Сообщения: 1526
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Да, теперь я вижу. Я был смущен названием вашего поста, который гласит, есть бедные энтропии в Windows, генерируются пары ключей.
Но OpenSSL действительно используют источники случайных данных MS, автоматически, что, как я уже говорил, и на самом деле ни один из кода настройки случайного пула в util.cc необходимо. Так что я согласен с вами, что не существует уязвимость. |
|
|
|
|
28 сентября 2012, 1:59:39 PM
|
# 13 |
|
Сообщения: 539
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Но OpenSSL действительно используют источники случайных данных MS, автоматически, что, как я уже говорил, и на самом деле ни один из кода настройки случайного пула в util.cc необходимо. Так что я согласен с вами, что не существует уязвимость. Дело в том, что мы на самом деле не знаю, если CryptAcquireContext () в RAND_Screen терпит неудачу. OpenSSL ничего не говорит пользователю об этом. Я даже не знал, в каких ситуациях он может потерпеть неудачу. Может быть "Windows Home BASIC для Childen под 13" не поддерживает его. Или, может быть "Окна для Кубы" не потому, что либо криптографических экспортного контроля ... |
|
|
|
|
28 сентября 2012, 3:20:34 PM
|
# 14 |
|
Сообщения: 676
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Но OpenSSL действительно используют источники случайных данных MS, автоматически, что, как я уже говорил, и на самом деле ни один из кода настройки случайного пула в util.cc необходимо. Так что я согласен с вами, что не существует уязвимость. Дело в том, что мы на самом деле не знаю, если CryptAcquireContext () в RAND_Screen терпит неудачу. OpenSSL ничего не говорит пользователю об этом. Я даже не знал, в каких ситуациях он может потерпеть неудачу. Может быть "Windows Home BASIC для Childen под 13" не поддерживает его. Или, может быть "Окна для Кубы" не потому, что либо криптографических экспортного контроля ... У меня было, что обсуждение на IRC, вы связали его выше, и мой первоначальный вопрос был похож, мы нуждаемся в util.cpp материал для энтропии и что делает его добавить. Тогда я намеревался ускорив процесс, и просил, чтобы удалить RAND_screen (), которая должна быть сохранена. Во всяком случае, я довольно уверен, что Гэвин не любит идею снятия его целиком, и если я расширяю свой код с предупреждением debug.log на неудачу CryptAcquireContext () не должно быть больно + мы пнуть, что доступ улей реестра из, который является довольно медленным и добавляет ничего ИМХО. диаметр |
|
|
|
|
28 сентября 2012, 3:50:40 PM
|
# 15 |
|
Сообщения: 1106
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Это мои мнения (которые более основаны на интуиции и опыте, чем на теоретических основаниях, что я могу назвать). Они основаны на том, как система будет реагировать на выход из строя одного из компонентов, как контроль повреждения. 1. Не добавляйте частные ключи ECC в качестве случайного источника. Неудача в OpenSSL случайного пуле будет означать утечку секретных ключей в качестве нового вектора атаки. Ну, что ваша модель угроз? Если это просто низкая энтропия, ваше второе предложение ниже решает эту проблему очень хорошо, по модулю теоретических опасений, что состояние пула должно быть зашифровано на диске. Если вы беспокоитесь об ошибках или вредоносном коде, то в крайнем случае мы ввинчиваемся в любом случае, как мы уже доверяем наши ключи к OpenSSL. Однако, если предположить, что ECC-коду, связанные и SHA256-код, связанные с работой, которая является основой безопасности Bitcoin в любом случае, то разумный подход по-прежнему создает хэш кодовой фразы пользователей / некоторые шифрованные ключи и закрытые ключи и либо отправки что RAND_add () или хэширования в RAND_bytes () и используя результат, что в качестве следующего ключевого материала. Самое худшее, что может случиться с как вы упали обратно к алгоритму детерминированной ключа, без ключа укрепления, совсем как предложение СИПА. Это также весьма маловероятно, чтобы утечка данных в выходе SHA256 хэш, поскольку это означает, что Дайджесты не правильно рассчитал, которые будут замечены очень быстро. Вы хотите быть уверены, что безопасная память используется в SHA256 рутинах, конечно, но это уже требуется с детерминированной системой ключей в любом случае. Использование дайджеста напрямую, а не отправлять его RAND_add (), действительно добавляет критический код, который может иметь ошибки в этом, хотя. Мы по существу создавая параллельный ПСЧ; пахнет по-инженерии. 2. Используйте простой бассейн файл состояния, с RAND_load_file (). Первый раз Bitcoin запускается, собирать энтропию из нажатых клавиш и сохранить эту энтропию в файл состояние. Смешать энтропии файл состояния с текущим состоянием пула каждый раз при запуске приложения. Проектирование ПСЧ является весело и все, но нет, код уже написан, так что я предпочел бы чтобы это было сделано, чем мое предложение. Как RAND_file_name () работает на окнах? Если собрать ПСЧ рядом с файл_ключа пользователя является разумным, и, возможно, обезглавленные пользователи спрашивают, почему материал становится написан другим, чем подцепится каталог мест. (Поведение по умолчанию имя_файла) В любом случае, RAND_load_file () при запуске и RAND_save_file (), когда бумажник модифицируется на диске звучит разумно для меня. Опять же, я напишу патч, если никто больше не бьет меня к нему. 3. Не XOR закрытые ключи ECC. Свойства XOR над полем ЕС не были проанализированы. Хеширования их вместе было бы лучше. Тем не менее, если состояние файла используется, это не является необходимым. 4. Если половина секретного ключа ECC раскрывается, возможно, что полный ключ скомпрометирован. Это происходит во многих теоретико-числовых шифров и алгоритмов подписи. Половина закрытый ключ не половина безопасности. Именно то, что я был обеспокоен. 5. Вызов RAND_event () каждый раз, когда мы обрабатываем сообщение Windows. 6. Оставьте RAND_Screen где (Он не может причинить никакого вреда). Оба хорошие идеи. |
|
|
|
|
29 сентября 2012, 10:02:38 AM
|
# 16 |
|
Сообщения: 1526
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Случайный источник Windows, вероятно, включает в тайминги и различные данные аппаратных событий, во всяком случае, если есть слабость в Windows, CSPRNG и OpenSSL использует, что это гораздо более серьезная проблема, чем просто с Bitcoin.
Видимо CryptGenRandom это просто оболочка для RtlGenRandom в течение некоторого времени. Я подозреваю, что это не даже больше использовать криптографический параметр контекста. Во всяком случае, если вы думаете, что код OpenSSL прослушивается и неправильно с помощью интерфейса Windows API, это обсуждение, чтобы в форумах OpenSSL. |
|
|
|
|
30 сентября 2012, 11:07:08 AM
|
# 17 |
|
Сообщения: 952
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Edit: приходите думать об этом, если люди обеспокоены тем, что вставка пары ключей может каким-то образом просачиваться данные в случае перерыва в библиотеке OpenSSL или что-то, вставить половину каждого ключа, то же половину каждый раз. Даже взлом ключа с половиной бит известен примерно грозная 2 ^ 128 проблема. Я не знаю точно, как работает ключ формата ECC, поэтому, возможно, я должен выбрать конкретные биты, любое представление о том, что? Насколько я знаю, взломав 128 битный ECC ключ требует только 2 ^ 64 операций в среднем с использованием алгоритма ро Полларда. Рассматривая 109-битный ключ был скомпрометирован в 2004 году, я не считал бы 128 битный ключ будет достаточно. |
|
|
|
|
22 октября 2012, 8:03:30 AM
|
# 18 |
|
Сообщения: 1890
цитировать ответ |
Re: Возможные новые уязвимости: слабая энтропия в Windows, генерируется .. пары ключей
Вместо того, чтобы просто автоматически генерировать случайные ключи при запуске клиента, почему не вариант, чтобы создать свежий кошелек? При входе на несколько факторов: Сколько ключей? (По умолчанию 100), а затем вы можете попросить пользователя генерировать, так что есть возможность ждать (тайминги) и перемещать мышь вокруг или ввод данных с клавиатуры.
Вы можете также спросить пользователь, если он хочет, чтобы он зашифрован, и пропустить незашифрованую генерирующую часть полностью, что, казалось, вопрос до 0.7.1. (Satoshi клиент) |
|
|
|
Как заработать Биткоины?
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包
bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru
3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW
Регистрация для новых участников, на данный момент не доступна. Просим извинения за временные неудобства.