Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
31 августа 2013, 3:10:59 AM   # 1
 
 
Сообщения: 560
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Я видел этот RFC упоминается один или два раза на этом форуме, но не мог найти обширный диалог о нем. Я хотел бы осуществить это как часть моего аппаратный кошелек, но я не решаются сделать это, не видя, что другие должны думать о подходе.

Детерминированное Использование цифровой подписи алгоритм (DSA) и эллиптические кривые Digital Signature Algorithm (ECDSA)


Резюме RFC 6979
поколение ECDSA подписи использует число к, которое должно быть случайным образом и равномерно выбранные каждый раз, когда создается подпись. Под детерминированным ECDSA, предложенный RFC 6979, к выбрано детерминировано.

Мы начнем с создания экземпляра HMAC-DRBG, с закрытым ключом в качестве источника энтропии, и хэш сообщения в качестве временного значения. K генерируется из выходного сигнала этого экземпляра HMAC-DRBG. Это делает к детерминированным, учитывая сообщение и закрытый ключ, но все же равномерно распределены и ~ невозможным для злоумышленника угадать / Calculate.

Самое главное, что подписи генерируется таким образом, совместимы с существующими реализациями проверки ECDSA подписи.


Зачем ECDSA детерминированным?
Есть две основные причины использовать детерминированный алгоритм здесь. В обычном ECDSA, если две подписи создаются (различные сообщения) с тем же значением K, закрытый ключ может быть вычислен. Это означает, что ECDSA немедленно терпит неудачу, если к не выбран случайным образом.  Недавняя Android казус привел к такой проблеме. Использование детерминированного ECDSA позволяет избежать этого.

Во-вторых, это позволяет легко проверить реализаций ECDSA, используя фиксированные векторы теста. Обычные реализации ECDSA не могут использовать тест подписи векторов, так как подписи являются случайными дизайном.


Мысли?
fpgaminer сейчас офлайн Пожаловаться на fpgaminer   Ответить с цитированием Мультицитирование сообщения от fpgaminer Быстрый ответ на сообщение fpgaminer


Как заработать Биткоины?
Без вложений. Не майнинг.


31 августа 2013, 3:53:51 AM   # 2
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Получил 1806 Биткоинов
Реальная история.





Вот мои мысли: http://permalink.gmane.org/gmane.comp.bitcoin.devel/2734

gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

4 сентября 2013, 6:16:33 AM   # 3
 
 
Сообщения: 560
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)


Да, это, кажется, хорошо резонирует с моими выводами. Спасибо за ссылку.

Я только что закончил кодирование Реализация HMAC_DRBG в Python и бросил его на GitHub, как хорошая ссылка. Я буду следить за этим с реализацией RFC 6979 в Python, чтобы играть с.

Лично я склоняюсь к реализации в RFC 6979, с дополнительным переключателем в API, чтобы позволить использование дополнительной энтропии. Коммутатор может по умолчанию на, что позволяет избежать проблем более утечки информации о секретном ключе. При единичных или непрерывных испытаниях, однако, он может быть выключен, чтобы проверить соответствие с RFC 6979, и снова включается для проверки несоответствий (и, таким образом, подтверждает, что энтропия добавляется).
fpgaminer сейчас офлайн Пожаловаться на fpgaminer   Ответить с цитированием Мультицитирование сообщения от fpgaminer Быстрый ответ на сообщение fpgaminer

4 сентября 2013, 6:21:32 AM   # 4
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Я склоняюсь к рекомендации с использованием HMAC-SHA512, так как его уже требуется для BIP32.

Я бы вообще не рекомендовал недетерминированных подписей. Если подписи не являются детерминированными, что невозможно для кого-то, чтобы убедиться, что реализация не использует значение R в качестве бокового канала утечки закрытых ключей.

В с открытым исходным кодом чистых программных реализаций легко быть относительно уверено, что реализация не является криптографический кодирующей закрытым ключом при выборе значения R (с помощью, например, не приращением K, пока на R, что просачивается недетерминированная частью секретного ключа мастера ), но в аппаратной реализации бумажника это невозможно, и это тривиально построить злую реализацию, просачивается закрытый ключ с помощью значения R в нескольких подписях.

Я на самом деле есть две реализации примеров вредоносных подписантов: один производит недетерминированных подписей и просачивается в 256-битного ключа, к держателю конкретного открытого ключа, и никто другой, в ~ 33 подписи с очень высокой вероятностью (интенсивность отказов 1 в 1000 для 33 подписей, около 1 на миллион в течение 34). Другой производит казалось бы, RFC 6979, как детерминированная подпись и с одной подписью просачивается текущий секретный ключ, и с 16 подписями просачивается дополнительная 256-битным секрет (например, мастер-закрытый ключом, с частотой отказов около 1: 1000 для 16 подписей , ~ 1: 1E6 17 подписей).

Оба работают, выполняя дополнительную точку умножения, чтобы получить ECDH общий секрет между атакующим и ключом пользователя.

В первом случае он затем ищет значение K, где Н (секрет || R) 'ы младших бит соответствует данным утечки. Утечка данных выбирается на основе использования данных подписываются вбить код фонтан над частными данными.

Во втором, ECDH общий секрет заменяет секретный ключ в выборе RFC6979 K значения (особенно это дьявольское, потому что реализация с OpenSSL выглядит довольно доброкачественной, как его просто указать умножая секрет постояннЭДфвели-), и appeneding 16 бита (опять ) дайджеста сообщения, выбранные секретные данные (которые просто выглядит как более «соль») на этот раз только индекс в 65535 16-битных слов из 16 битного расширения в RS кода секретного ключа. Злоумышленник вычисляет общий секретный ключ, а затем ищет 16 битное значение, которое дает ему тот же R. Затем он знает K и может восстановить текущий ключ и узнал 16 бит секретных данных. Код RS может быть предварительно вычислены и прошло, как только избыточность для хранения мастер-ключа.

Поскольку уступчивость в аппаратных устройств уже слаб, он будет уверен, что будет лучше, если устройство может быть помещено в режиме, который сделает его поведение полностью воспроизводимым внешне. Если предположения, лежащие в основе безопасности на основе SHA2 derandomized DSA не имеет места, то это почти наверняка, что SHA2 использованием ECDSA также не будет держать. Какой бы вариант вы реализуете, я надеюсь, что будет способ для кого-то с устройством, чтобы убедиться в том, что он делает то, что его supposted делать.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

4 сентября 2013, 10:50:38 AM   # 5
 
 
Сообщения: 560
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Замечательные и проницательные комментарии, gmaxwell; Спасибо.

котировка
но в аппаратной реализации бумажника это невозможно
Если оборудование известно, и он работает прошивку с открытым исходным кодом, какие проблемы будет?

Кроме того, вредоносная прошивке не нужна утечка информации через подписи для того, чтобы вектор атаки. Это может быть с помощью DRBG, чтобы выбрать закрытые ключи, высевают от секрета, известного нападающего и устройства конкретного идентификатора. Это позволит злоумышленнику вычислить потенциальные частные ключи и поиск blockchain. Для внешнего наблюдателя, частные ключи будут выглядеть случайными, как обычно. (Это те же Worry людей об обучении RdRand)

котировка
было бы уверено, будет лучше, если устройство может быть помещено в режиме, который сделает его поведение полностью воспроизводимым внешне
Возможно, детерминированные подписи может быть конфигурируемый пользователем вариант, что позволяет пользователям экспертов в "выбрать свой яд",
fpgaminer сейчас офлайн Пожаловаться на fpgaminer   Ответить с цитированием Мультицитирование сообщения от fpgaminer Быстрый ответ на сообщение fpgaminer

4 сентября 2013, 11:29:00 PM   # 6
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

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

Как правило, если ваше вычислительное устройство скомпрометировано вы вид обречены, но в этом случае не так много ... потому что поведение устройства достаточно узко, и все общение опосредуется через хозяин, оно должно быть возможным, чтобы быть немного больше уверенный здесь.

котировка
Кроме того, вредоносная прошивке не нужна утечка информации через подписи для того, чтобы вектор атаки. Это может быть с помощью DRBG, чтобы выбрать закрытые ключи, высевают от секрета, известного нападающего и устройства конкретного идентификатора. Это позволит злоумышленнику вычислить потенциальные частные ключи и поиск blockchain. Для внешнего наблюдателя, частные ключи будут выглядеть случайными, как обычно. (Это те же Worry людей об обучении RdRand)

Я ожидаю, что вы хотите сделать свой мастер-ключ некоторых H (устройство хаотичности || пользователем или начальным хост хаотичность). Вам нужен способ, чтобы экспортировать данные мастера-ключ для целей резервного копирования, так и с добавлением, что также позволяет пользователю получить способствующую хаотичность после получения мастеров-ключа устройства. Фактически это означает, что устройство не может незаметный чита в том, как вы предлагаете.

(В настоящее время, любой конкретный пользователь может не обнаружить, но это- это изменяет модель риска для кого-то, подставляя прошивку, так как после того, как уже обязавшись некоторым поведение и подписание сделок от имени пользователя пользователь может затем требовать его обеспечить хаотичность устройства и они могли в полной мере повторить выход)

котировка
было бы уверено, будет лучше, если устройство может быть помещено в режиме, который сделает его поведение полностью воспроизводимым внешне
Возможно, детерминированные подписи может быть конфигурируемый пользователем вариант, что позволяет пользователям экспертов в "выбрать свой яд",
[/ Цитата] Я предпочитаю меньше возможностей для более ... но на самом деле.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

9 сентября 2013, 7:30:50 PM   # 7
 
 
Сообщения: 439
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Последние новости о DRBG: http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy 

Кстати, слякоть и я пытаюсь реализовать RFC6979 в питон-ECDSA / microecdsa. Надеюсь, мы будем публиковать результаты в ближайшее время (или смотреть https://github.com/trezor/python-ecdsa а также https://github.com/trezor/microecdsa РЕПО).
придерживаться сейчас офлайн Пожаловаться на палку   Ответить с цитированием Мультицитирование Сообщения от палки Быстрый ответ на сообщение клюшка

9 сентября 2013, 7:35:15 PM   # 8
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Последние новости о DRBG: http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy 
Старые новости и fpgaminer не говорят о Dual_EC_DRBG. Он реализован DRBG основанного на SHA256.

gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

9 сентября 2013, 7:42:22 PM   # 9
 
 
Сообщений: 28
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Вау, спасибо за размещение «microecdsa» код - теперь я получаю, чтобы увидеть, как то, что я придумал штабеля до версии

Пара вопросов:

Является алго вы создали устойчивый к боковому каналу атаки (постоянное время для выполнения скалярного умножения)?
Можете ли вы дать мне какие-либо идеи / ссылки в вашу технику «PRECOMPUTED_CP / IV»?

Последние новости о DRBG: http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy 

Кстати, слякоть и я пытаюсь реализовать RFC6979 в питон-ECDSA / microecdsa. Надеюсь, мы будем публиковать результаты в ближайшее время (или смотреть https://github.com/trezor/python-ecdsa а также https://github.com/trezor/microecdsa РЕПО).
NATB сейчас офлайн Пожаловаться на NATB   Ответить с цитированием Мультицитирование сообщения от NATB Быстрый ответ на сообщение NATB

9 сентября 2013, 11:32:10 PM   # 10
 
 
Сообщения: 111
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Что было бы недостатком детерминированной генерации K каждый раз, а затем умножением на ПСЧ генерироваться числа и уменьшения по модулю п и использовать это, чтобы подписать?
Вы бы не получить защиту от сбоя любого метода этот путь?
Crowex сейчас офлайн Пожаловаться на Crowex   Ответить с цитированием Мультицитирование сообщения от Crowex Быстрый ответ на сообщение Crowex

9 сентября 2013, 11:46:12 PM   # 11
 
 
Сообщений: 28
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Это все хорошо, - да, это прекрасно работает. Однако, как я понимаю, это портит преимущества, имеющие третье лицо стороны сможет * точно * воспроизводить свои подписи, чтобы убедиться, что устройство HW ничего не делает немое при создании указанных подписей. Это дает им уверенность в том, что ваш HW бумажник не протекающая информации о закрытых ключах через неудовлетворительное «случайное» поколение чисел.

Что было бы недостатком детерминированной генерации K каждый раз, а затем умножением на ПСЧ генерироваться числа и уменьшения по модулю п и использовать это, чтобы подписать?
Вы бы не получить защиту от сбоя любого метода этот путь?
NATB сейчас офлайн Пожаловаться на NATB   Ответить с цитированием Мультицитирование сообщения от NATB Быстрый ответ на сообщение NATB

10 сентября 2013, 12:27:04 AM   # 12
 
 
Сообщения: 560
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

котировка
Как вы знаете, на самом деле, что он работает исходный прошивки открытой и не модифицированную версию установленной изготовителем или замене в пути?
Два этапа, в зависимости от пользователя паранойя:

1) Обновление устройства перед его использованием, с исправной прошивкой (криптографическая подпись + детерминированная компиляция). [Не исключает руткит]
2) Откройте устройство, визуально проверить оборудование, а также использовать JTAG / SWD, чтобы вручную стереть и вспышка. [Правила из руткита, FPGA маскарада, и т.д.]

Это позволит смягчить все возможные атаки. Только одна левая бы злонамеренный пользовательский ASIC притворяясь MCU. Но если злоумышленник готов потратить миллионы долларов ... черт, вы должны делать что-то прямо в вашей жизни.

котировка
Как правило, если ваше вычислительное устройство скомпрометировано вы вид обречены, но в этом случае не так много ... потому что поведение устройства достаточно узко, и все общение опосредуется через хозяин, оно должно быть возможным, чтобы быть немного больше уверенный здесь.
Да, есть миллион и один способ атаковать пользователь, когда злоумышленник сторона может манипулировать оборудование. Но, вы делаете большую точку независимо; более безопасный, чем сожалеть.

котировка
Я ожидаю, что вы хотите сделать свой мастер-ключ некоторых H (устройство хаотичности || пользователем или начальным хост хаотичность). Вам нужен способ, чтобы экспортировать данные мастера-ключ для целей резервного копирования, так и с добавлением, что также позволяет пользователю получить способствующую хаотичность после получения мастеров-ключа устройства. Фактически это означает, что устройство не может незаметный чита в том, как вы предлагаете.
Вместо этого, и если у вас есть доверенный компьютер, на котором все это сделать (так как он будет иметь доступ к мастер-ключу), просто создать резервную копию вручную, используя собственную энтропию и восстановить его на устройство. Затем запрос устройства для нескольких открытых ключей, чтобы проверить это с помощью резервной копии. Я специально оставил этот вариант открытым на моей платформе, так что продвинутые пользователи могли выбирать свои собственные средства создания мастер-ключа. Например, выбирая его как brainwallet.

Как обычно, gmaxwell, ваши комментарии удивительно проницательные и полезные. Спасибо за то, что нашли время на биту вокруг этих идей со мной (и остальной частью сообщества).
fpgaminer сейчас офлайн Пожаловаться на fpgaminer   Ответить с цитированием Мультицитирование сообщения от fpgaminer Быстрый ответ на сообщение fpgaminer

10 сентября 2013, 12:55:01 AM   # 13
 
 
Сообщения: 560
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Я протянул руку к Colin Персиваль (который написал Scrypt, например) для его мысли / комментарии по RFC 6979. Вот что он должен был сказать (с его разрешения):

котировка
Я не вижу каких-либо конкретных проблем с этим предложением, но с использованием закрытого ключа
как часть ввода хэшированном делает меня немного нервничать.

Лично я предпочел бы, чтобы накормить их в HMAC-DRBG использовать для энтропии
* В дополнении к * нормальному высеву энтропии от операционной системы - если не
Вам действительно нужны детерминированных подпись.

Это, кажется, согласуется с мнением в значительной степени все остальные в RFC 6979, который хорошо видеть. Большое спасибо Colin Персиваль нашли время, чтобы ответить на мой вопрос!

котировка
Вау, спасибо за размещение «microecdsa» код - теперь я получаю, чтобы увидеть, как то, что я придумал штабеля до версии смайлик
Shameless самореклама: https://github.com/fpgaminer/strong-arm

котировка
Можете ли вы дать мне какие-либо идеи / ссылки в вашу технику «PRECOMPUTED_CP / IV»?
Смотрит на меня как реализации LUT ЭЦ скалярного умножения. У вас есть 256 предварительно вычисленные значения, каждая из вида 2 ^ я * G так что вы можете просто добавить их вместе в зависимости от битов скаляр. Я могу пойти в более подробное объяснение, если вы хотите.

Я решил не реализовать эту оптимизацию в сильноточной руке, так как на самом деле была не так много узких мест, и я лично предпочитаю прозрачный код по оптимизированному коду. Легче аудит и избежать ошибок.

котировка
Что было бы недостатком детерминированной генерации K каждый раз, а затем умножением на ПСЧ генерироваться числа и уменьшения по модулю п и использовать это, чтобы подписать?
Вы можете сделать это в псевдо-RFC 6979, просто перезаполнения DRBG с какой-либо дополнительной энтропии вы хотите. Хотя, как NATB отметил, gmaxwell и другие считают, что лучше оставить все полностью детерминированным. Я ... еще на заборе, но склоняюсь больше к детерминированному после прочтения аргументов gmaxwell в.
fpgaminer сейчас офлайн Пожаловаться на fpgaminer   Ответить с цитированием Мультицитирование сообщения от fpgaminer Быстрый ответ на сообщение fpgaminer

10 сентября 2013, 1:09:22 AM   # 14
 
 
Сообщения: 439
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Я решил не реализовать эту оптимизацию в сильноточной руке, так как на самом деле была не так много узких мест, и я лично предпочитаю прозрачный код по оптимизированному коду. Легче аудит и избежать ошибок.

Эта оптимизация делает код 5x быстрее на x86. Еще на ARM устройств. Это значительное улучшение. К сожалению, это также код 3x-4x больше, поэтому есть макросы, чтобы включить / выключить.
придерживаться сейчас офлайн Пожаловаться на палку   Ответить с цитированием Мультицитирование Сообщения от палки Быстрый ответ на сообщение клюшка

10 сентября 2013, 1:20:10 AM   # 15
 
 
Сообщения: 1372
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Вытащите запрос добавление RFC 6979 в питон-ECDSA: https://github.com/warner/python-ecdsa/pull/10
слякоть сейчас офлайн Пожаловаться на слякоть   Ответить с цитированием Мультицитирование сообщения от слякоти Быстрый ответ на сообщение слякоть

10 сентября 2013, 1:33:07 AM   # 16
 
 
Сообщения: 560
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

котировка
Вытащите запрос добавление RFC 6979 в питон-ECDSA: https://github.com/warner/python-ecdsa/pull/10
Взрыв аплодисментов.  Очень здорово видеть! Спасибо за обмен, и подталкивая к репо Уорнера.

Лично я хотел бы видеть его использовать отдельный модуль HMAC-DRBG, чтобы помочь разделению кода, модульное тестирование и повторное использование кода (https://github.com/fpgaminer/python-hmac-drbg является общественным достоянием). Кроме того, возможность поменять HMAC-DRBG для другой функции, поэтому он может быть использован в качестве тест-кровать для использования простой HMAC.
fpgaminer сейчас офлайн Пожаловаться на fpgaminer   Ответить с цитированием Мультицитирование сообщения от fpgaminer Быстрый ответ на сообщение fpgaminer

10 сентября 2013, 1:48:02 AM   # 17
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Я протянул руку к Colin Персиваль (который написал Scrypt, например) для его мысли / комментарии по RFC 6979. Вот что он должен был сказать (с его разрешения):

:: вздыхать :: При добавление секрета к входу были проблематичной функция всего подписания будет очень вероятно, будет небезопасна: Вычислительные столкновениями легче, чем восстановление неизвестного прообраза, вдвойне, потому что следующая вещь, которую вы делаете, это умножить K на G чтобы получить R, что и уменьшает пространство на выходе, и делает K неустранимой из, если вы не можете решить проблему дискретного журнала.

Стоимость этого является то, что вы производите устройство Whos правильное поведение не поддается измерению. Это может иметь лазейки, вставленные в нескольких формах, которые были бы очень трудно обнаружить, или он может иметь недостатки работы.

например если он становится горячим есть случайный bitflips в многосвязном используются для получения R из К, так как повороту secp256k1 является гладким полем, где решение DLP относительно легко один бит-флип в умножении может приводить к значению R, из которого К может быть восстановлен в около 2 ^ 51 работы.

[Edit: На самом деле это неверно secp256k1 является поворот безопасным, ошибка там стало результатом очевидно транскрипции ошибки копирования вниз порядка твист для факторинга. Конечно, потенциал для бэкдоров в DSA Нонса поколения является универсальным и применим ко всему кривому, а edDSA а]

По существу, я рассматриваю это как повышение слабость к этим конкретным, но "довольно скучно" угрозы, которые я могу сформулировать и даже показать вам демонстрацию (например, потайными дверь подписантов) в пользу или умозрительно повышение безопасности в отношении неопределенного криптографического boogymen, which-, если они существуют в All-вероятно убить все нас, независимо (позволяя коллизии на время данные подписаны, и, таким образом, позволяя подписи перекомпоновка).

Два этапа, в зависимости от пользователя паранойя:

1) Обновление устройства перед его использованием, с исправной прошивкой (криптографическая подпись + детерминированная компиляция). [Не исключает руткит]
2) Откройте устройство, визуально проверить оборудование, а также использовать JTAG / SWD, чтобы вручную стереть и вспышка. [Правила из руткита, FPGA маскарада, и т.д.]

Это позволит смягчить все возможные атаки. Только одна левая бы злонамеренный пользовательский ASIC притворяясь MCU. Но если злоумышленник готов потратить миллионы долларов ... черт, вы должны делать что-то прямо в вашей жизни.

Так что это на самом деле не вполне отражает "защита модель" Я иду. Realistically- чей будет идти и делать эти вещи? Даже из тех людей, с миллионом долларов, чтобы защитить? Очень мало.

Но не ноль, несколько вундеркиндов, вероятно, могут пойти splunking вокруг- и я думаю, что на самом деле какой-либо один пытается быть поставщиком в этом пространстве должны даже выделить некоторый бюджет платить за аудит третьей стороны, чтобы сделать _sure_ некоторые внешние глаза копать глубоко.

То, что я думаю, что было бы полезно для Bitcoin-экономики с использованием, если эти редкие случаи сумасшедшие, любопытные, или иначе мотивированные искателей приключений каким-то образом защищены все мы из вредности. Это то, что происходит с открытым кодом: Когда я просматриваю код полностью, я не только защитить себя: Я защищаю всех я могу общаться.

Проблема с (2) есть то, что я не могу сказать, если устройство было неверным, чтобы начать с. Так что, если я парень, который не доверяет моего устройства результатом является то, что я получаю безопасное устройство, но я не получаю возможность сирену, чтобы предупредить кого-либо еще. В частности, если устройство является детерминированным, кто идет в с логическими анализаторами может удостоверить устройство и документировать поведение, то другие люди могут случайно проверить, что их устройства измеряют документированное поведение с гораздо меньшим количеством работы.

Компромисс в середине, если устройство имеет дисплей: при подписании, показать дополнительные "бонус" Случайность на дисплее. Поведение может еще тогда быть полностью детерминированным (если вы захватить бонус случайность) .. но так как протокол по-прежнему должна быть безопасными против чего-либо с помощью криптографического boogymen, даже если "бонус хаотичность" это просто константа должна быть безвредным для его отображения, можно даже отправить его через USB к хозяину. Если вы не беспокоитесь о boogmen, которые могут инвертировать SHA256 и владеют видеокамеры (или, в последнем, и которые уже взломали ваш компьютер).

Я надеюсь, вы не думаете, что я разглагольствования на вас слишком много. Мои ответы здесь все в духе говорить путем создания лучших и наиболее безопасных систем практически possible- цель я думаю, что мы все разделяем.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

10 сентября 2013, 8:51:31 AM   # 18
 
 
Сообщения: 360
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Я протянул руку к Colin Персиваль (который написал Scrypt, например) для его мысли / комментарии по RFC 6979. Вот что он должен был сказать (с его разрешения):

котировка
Я не вижу каких-либо конкретных проблем с этим предложением, но с использованием закрытого ключа
как часть ввода хэшированном делает меня немного нервничать.

Лично я предпочел бы, чтобы накормить их в HMAC-DRBG использовать для энтропии
* В дополнении к * нормальному высеву энтропии от операционной системы - если не
Вам действительно нужны детерминированных подпись.

Это, кажется, согласуется с мнением в значительной степени все остальные в RFC 6979, который хорошо видеть.

:: вздыхать :: При добавление секрета к входу были проблематичной функция всего подписания будет очень вероятно, будет небезопасна: Вычислительные столкновениями легче, чем восстановление неизвестного прообраза, вдвойне, потому что следующая вещь, которую вы делаете, это умножить K на G чтобы получить R, что и уменьшает пространство на выходе, и делает K неустранимой из, если вы не можете решить проблему дискретного журнала.

Стоимость этого является то, что вы производите устройство Whos правильное поведение не поддается измерению. Это может иметь лазейки, вставленные в нескольких формах, которые были бы очень трудно обнаружить, или он может иметь недостатки работы.

например если он становится горячим есть случайный bitflips в многосвязном используются для получения R из К, так как повороту secp256k1 является гладким полем, где решение DLP относительно легко один бит-флип в умножении может приводить к значению R, из которого К может быть восстановлен в около 2 ^ 51 работы.

Я, вероятно, отсутствует что-то здесь, но мне кажется, что аргумент, что вы даете похоже на то, что был Колин Персиваль в виду, хотя вы интерпретируя его в противоположном направлении, чем он, и я не совсем понять ваш аргумент еще.

Я думаю, что беспокоит то, что там могут быть атаки бокового канала на хэш-функции (тепло, как в вашем примере, акустический шум, синхронизации и т.д.), которые могут восстановить входные данные, которые он вызывается с. С другой стороны, в то время как это верно, что privkey и K также используются в следующих расчетах, наконец, выводит подпись, эти расчеты могут быть замаскированы в целях защиты от таких атак со стороны каналов (например, умножив к свежему случайному значение перед вычислением к ^ {- 1}, а затем демаскирования). Для хэш-функции, нет никакого способа, чтобы сделать эти маскирующие трюки, поэтому беспокойство?

Я полагаю, что это хорошая идея, что детерминированные подписи будут конфигурируемый пользователем вариантом, но важный вопрос все еще остается, ОТНОСЯЩИМСЯ, следует ли поведение по умолчанию быть детерминированным или случайным образом.

Кроме этого предполагается защита от атак со стороны каналов, кто-нибудь знает, если есть какие-либо другие преимущества или практические случаи использования для случайных подписей (как, очевидно, в случае со случайным шифрованием, так что это было бы семантический безопасным)?
Идо сейчас офлайн Пожаловаться на Идо   Ответить с цитированием Мультицитирование сообщения от Идо Быстрый ответ на сообщение Идо

10 сентября 2013, 9:32:15 AM   # 19
 
 
Сообщения: 111
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Это все хорошо, - да, это прекрасно работает. Однако, как я понимаю, это портит преимущества, имеющие третье лицо стороны сможет * точно * воспроизводить свои подписи, чтобы убедиться, что устройство HW ничего не делает немое при создании указанных подписей. Это дает им уверенность в том, что ваш HW бумажник не протекающая информации о закрытых ключах через неудовлетворительное «случайное» поколение чисел.

Что было бы недостатком детерминированной генерации K каждый раз, а затем умножением на ПСЧ генерироваться числа и уменьшения по модулю п и использовать это, чтобы подписать?
Вы бы не получить защиту от сбоя любого метода этот путь?

ОК. Я видел его в качестве страховки от неисправной PRNGs. Аппаратные бумажники всегда будут иметь проблемы в обеспечении частные ключи генерируются нормально в любом случае.
 Но если вы действительно хотели, чтобы проверить случайное слово подписи было бы возможно предварительно создать файл случайных чисел, хранить их на кошелек и дать им покупателю бумажника в файле или в Интернете, то детерминировано генерировать номер и добавить следующий номер из файла случайных чисел и уменьшить по модулю п и подписать с этим?
Crowex сейчас офлайн Пожаловаться на Crowex   Ответить с цитированием Мультицитирование сообщения от Crowex Быстрый ответ на сообщение Crowex

10 сентября 2013, 5:01:51 PM   # 20
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: детерминированных Использование суточных и Signature Алгоритмы ECDSA Digital (RFC 6979)

Я, вероятно, отсутствует что-то здесь, но мне кажется, что аргумент, что вы даете похоже на то, что был Колин Персиваль в виду, хотя вы интерпретируя его в противоположном направлении, чем он, и я не совсем понять ваш аргумент еще.
Колин Персиваль является автором единственного недавно заметному хеш-функции со значительными проблемами атаки данных в зависимости от хронометража, так что, возможно, вот почему это на его мозг.

Если у вас есть связанные с доступом без памяти питания или синхронизации боковых каналов (например, как сумматоры утечкой данных, что и требовалось бы для HMAC-SHA512, чтобы утечка), то там собирается не быть никакого способа избежать точки ECDSA математике течь как сумасшедший , Использование недетерминированное DSA не спасает вас от боковых каналов. Может быть детерминированным делает действительно боковой канал тяжелой реализации более уязвимыми, но люди уже продемонстрировали восстановление на устройствах с рандомизированном АСС, поэтому я немного скептически, что это имеет значение. Некоторое поведение маскировки было бы хорошо, но это не будет требовать создания выходных недетерминированы.

Будучи тяжело от злоумышленника с физическим доступом очень трудно, как я уже говорил простой битовую ошибку в нашей с многократно поставит вас на твист и наибольший простой множитель порядка закручивания SECP256k1 составляет всего около 2 ^ 50.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW