Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
18 сентября 2015, 9:36:33 PM   # 1
 
 
Сообщений: 42
Цитировать по имени
цитировать ответ
по умолчанию Re: Формат для полных подписей файлов

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


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

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

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

Тем не менее, было бы очень полезно, чтобы иметь возможность подписать существующий файл, который может быть очень большим,
например ан EXE-файл или архив с исходным кодом.
Это позволило бы обеспечить PGP подобные функциональные возможности подписи с помощью Bitcoin эллиптической кривой.

Поэтому я создал и реализован такой формат подписи, который входит в состав пакета bitgen программного обеспечения:

http://bitcoin-gen.org/

Подпись может выглядеть следующим образом:
------ НАЧАТЬ Bitcoin SEPC256K1 ПОДПИСЬ ------
фе
14F0668D7FE8938F6A23F8FE1A4FB906C558A3FBDB967222B929158487F34183
6C50D34A304A3227035CEE1ADE006B5502CC41BF639609201F75919F1B3F560E
------ END Bitcoin SEPC256K1 ПОДПИСЬ ------


Подписи включают в себя значение г и х подписей, а также три логических значений.

Открытые ключи х и у значения не включено, поскольку кривая sepc256k1 позволяет восстановить открытый ключ
от значений г и с и хэш-суммы.

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

Первая буква может быть "е" или "s", Которая выступает за "первый" а также "второй",
С "е", Первое значение должно быть выбрано с "s" второе значение является правильным.

Вторая буква "е" или "о" для "странный" или "даже", И вместе с первым логическим значением дают правильный открытый ключ.

Эта функция может быть получена из сжатого или несжатого открытого ключа.
В третий символ указывает "U" для несжатых или "с" для сжатых.

Вторые и третьи строки являются значениями R и S в качестве шестнадцатеричных значений кодируются.

Двойной sha256 хэш файла осуществляется с помощью строки "Bitcoin Подписанный файл " сопровождаемый
Длина байт содержимого файла в десятичном формате ASCII, а затем " байт:" и, наконец, содержимое файла:

"Bitcoin Подписанный файл " + ASCII (длина) + " байт:" + file_content

Формат файла использует UNIX стиль новой строки с одним символом перевода строки.


Создание проекта даст два исполняемых файлов, один из которых является bitsig

Для того, чтобы создать и сохранить новый секретный ключ, используйте, например:
$ Bitsig случайный

Когда это будет сделано, подпись любого файла может быть создана:
$ эхо "тест bitgen" > btest.txt
$ Bitsig знак btest.txt

Это даст результат, похожий на следующий:
========================
Подписание файла сообщения: btest.txt
Ключ не указано, с помощью ключа по умолчанию: 17RjaCGZQbe2Cw984YdWcMcWDgM86kM7EN
Генерация 32 случайных байт.
Нажмите случайные клавиши или перемещать мышь, если это необходимо
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

Подписание в ходе ...
Попытка даже ...
Паритет даже

Результат записывается: btest.txt.bitsig
========================

Для проверки подписи файла, дайте следующую команду:

$ Bitsig проверить btest.txt btest.txt.bitsig

Это даст:
========================
Подписанный файл: btest.txt
Файл подписи: btest.txt.bitsig
Расчетный адрес: 17RjaCGZQbe2Cw984YdWcMcWDgM86kM7EN
Ни один общественный адрес не задан, глядя в брелок для ключей
Это наш собственный адрес
Найдено адрес в брелка
Проверка подписи ....
Убедитесь, OK Адрес: 17RjaCGZQbe2Cw984YdWcMcWDgM86kM7EN
Адрес псевдоним: MY KEY
========================
bit22gen сейчас офлайн Пожаловаться на bit22gen   Ответить с цитированием Мультицитирование сообщения от bit22gen Быстрый ответ на сообщение bit22gen


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


25 сентября 2015, 6:59:11 PM   # 2
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: Формат для полных подписей файлов

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





Да. Bitcoin использует цифровые подписи. Он также использует дополнение. И связные списки. Тем не менее, вы не видите, что люди собираются вокруг заменяют другие вещи, которые используют добавление или связанные списки с частями Bitcoin.

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

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

Цифровая подпись сама по себе не имеет смысла. Любой пользователь может создать один. Посмотрите на подписи на вашем сайте ... он служил через HTTP и у вас есть эти .bitsig файлы. Любой, кто мог подделать с загрузкой в ​​первую очередь могли бы просто заменить подписи: так, по крайней мере, как он используется там подписи не дают практически никакой безопасности.

Имея доказательства того, что используется ключ Публичного является подлинными один жесткой, но это прошёл проба системы, кажется, ничего не делать для этого; и Bitcoin предоставляет никаких ответов на that-- в дизайне клавиша Bitcoin не являются точной противоположностью постоянной identity-- анонимного, эфемерного, и, надеюсь, для одноразового использования.

PGP, с другой стороны, имеет обширную инфраструктуру для проверки ключей.

Так что основная причина, мы используем его, а не что-то самогон.

Некоторые другие вещи, чтобы думать для тех, кто работает на этом ...

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

В качестве aside-- глядя на вашем кодовом, я вижу, что она содержит полностью наивное и довольно медленное внедрение ECC. Такой подход будет кровоточить информацию о закрытом ключе пользователей через время, кэш и электромагнитное sidechannels. Зрелое криптографическое программное обеспечение (например, GPG) позволяет избежать такого рода уязвимостей. Я также вижу, что он не использует derandomized подписи. Я рад видеть, что есть некоторые тесты, но вы должны быть careful-- число людей понесло серьезные потери средств из-за неправильное поколение Публичного / адреса в редких случаях несколько фиксированных испытания векторов вряд ли поймать (например, редкие ошибки угла случая в bignum библиотек). Делая реальный обзор криптографии в проекте будет тонна работы ... и я думаю, что вряд ли кто-то будет делать это, потому что не по всей видимости, является причиной изобретать колесо в первую очередь (за ваше собственное образование, которое является очень ценным, но не большая причина для создания программного обеспечения для других людей, чтобы использовать).

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

25 сентября 2015, 8:57:52 PM   # 3
 
 
Сообщений: 42
Цитировать по имени
цитировать ответ
по умолчанию Re: Формат для полных подписей файлов

Bitcoin подписи вместо PGP не просто замена от одной реализации к другой
с теми же вариантами использования и характеристик.

Методы различаются, и поэтому лучше всего использовать в различных ситуациях.

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

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

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

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

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

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

Распределение ключей трудно. Загрузка открытого ключа подлежит атаке человек-в-середине.
Однако, загрузка из разных источников по различным каналам увеличат ваше доверие к открытому ключу.

Кроме того, поскольку адрес Bitcoin коротко, то проще отправить с, например, SMS.

Если вы получите файл от кого-то вы знаете, что можно получить публичный адрес
в телефонном разговоре. Человек-в-середине атаки будет очень сложно, если вы знаете человека, вы говорите с.

Программное обеспечение bitgen работа продолжается, есть много, чтобы улучшить в том числе тестов.

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

Я полностью согласен по поводу варианта brainwallet, я не считаю, что удаление функции, пока соль и KDF была реализован.

Если кто-то находит Bitcoin полные сигнатуры файлов полезна моя надежда, что будет использоваться указанный формат файла
когда новый bitsig-Aware программное обеспечение упаковали, возможно, с другой реализации ECC.

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

26 сентября 2015, 8:10:01 PM   # 4
 
 
Сообщения: 2366
Цитировать по имени
цитировать ответ
по умолчанию Re: Формат для полных подписей файлов

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

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

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

Хотя для файлов размером ключей Публичных и подписи, как правило, не очень интересно.

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

котировка
Кроме того, поскольку адрес Bitcoin коротко, то проще отправить с, например, SMS.
ПФГ отпечатков пальцев не хватает. Bitcoin адрес очень недружелюбно читать по телефону из-за смешанный случай.

котировка
Если кто-то находит Bitcoin полные сигнатуры файлов полезна моя надежда, что будет использоваться указанный формат файла
когда новый bitsig-Aware программное обеспечение упаковали, возможно, с другой реализации ECC.
Может быть ... но даже не обращая внимания на отсутствие ПКИ этот дизайн не очень подходит для файлов слишком большой, чтобы поместиться в памяти. В идеале вы хотите дерева структурированы схемы хэширования для этого.
gmaxwell сейчас офлайн Пожаловаться на gmaxwell   Ответить с цитированием Мультицитирование сообщения от gmaxwell Быстрый ответ на сообщение gmaxwell

26 сентября 2015, 9:01:22 PM   # 5
 
 
Сообщения: 412
Цитировать по имени
цитировать ответ
по умолчанию Re: Формат для полных подписей файлов

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

27 сентября 2015, 1:34:21 AM   # 6
 
 
Сообщения: 1484
Цитировать по имени
цитировать ответ
по умолчанию Re: Формат для полных подписей файлов

^^^

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

8 октября 2015, 9:24:54 PM   # 7
 
 
Сообщений: 42
Цитировать по имени
цитировать ответ
по умолчанию Re: Формат для полных подписей файлов

Используя низкие значения S в подписи согласно BIP-62 кажется хорошей идеей
даже если податливости для полных подписей файлов не является проблемой в настоящее время.

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

Я изменил реализацию так низко s подписи всегда генерируется. (Еще не выпущен)

Для полных подписей файлов низкого s теперь является обязательным требованием, а подпись не будет проверять без неоспоримым низкого с.

В других форматах подпись, не низком s все еще принимаются bitgen.

Код для расчета и проверки низкого S:

Знак:
======================
   // Вычисленный (R, S) значение является действительной подписью.
   // Однако, мы хотим, чтобы всегда использовать "низкие с" подпись

   Const BigInt<1024> Nhalf = (ec.n >> 1);
   если (s > Nhalf)
   {
      Const BigInt<1024> с2 = ec.n - с;
      Const ECPoint RS2 (г, с2);
      вернуться RS2;
   }   
   
   Const ECPoint RS (R, S);
   вернуться RS;
======================



Убедитесь, что:
======================
   Const BigInt<1024> Nhalf = (ec.n >> 1);
   если (s > Nhalf)
   {
      станд :: соиЬ << "Не использовать с низкой ей значением, неверная подпись" << станд :: епсИ;
      вернуться ложным;
   }
======================


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



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

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

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

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW