• Главная
  • Контакты
Подписаться:
  • Twitter
  • Facebook
  • RSS
  • VK
  • PushAll
logo

logo

  • Все
    • Положительные
    • Отрицательные
  • За сегодня
    • Положительные
    • Отрицательные
  • За вчера
    • Положительные
    • Отрицательные
  • За 3 дня
    • Положительные
    • Отрицательные
  • За неделю
    • Положительные
    • Отрицательные
  • За месяц
    • Положительные
    • Отрицательные
  • За год
    • Положительные
    • Отрицательные
  • Сортировка
    • По дате (возр)
    • По дате (убыв)
    • По рейтингу (возр)
    • По рейтингу (убыв)
    • По комментам (возр)
    • По комментам (убыв)
    • По просмотрам (возр)
    • По просмотрам (убыв)
Главная
  • Все
    • Положительные
    • Отрицательные
  • За сегодня
    • Положительные
    • Отрицательные
  • За вчера
    • Положительные
    • Отрицательные
  • За 3 дня
    • Положительные
    • Отрицательные
  • За неделю
    • Положительные
    • Отрицательные
  • За месяц
    • Положительные
    • Отрицательные
  • Главная
  • «Криптография в блокчейнах»: о хеш-функциях, ключах и цифровых подписях

«Криптография в блокчейнах»: о хеш-функциях, ключах и цифровых подписях +17

24.04.2017 15:00
alinatestova 14 5800 Источник
Разработка под e-commerce*, Криптография*, Информационная безопасность*, Блог компании Bitfury Group
Криптография — это сердце блокчейна, которое обеспечивает работу системы. Архитектура блокчейна предполагает, что доверие между участниками сети базируется на принципах математики и экономики, то есть является формализованным. Криптография также гарантирует безопасность, причем основанную на прозрачности и проверяемости всех операций, а не на традиционном для индустрии ограничении видимости системы (perimeter security).

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


/ изображение BTC Keychain CC

Хеш-функции


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

Хеш-функции имеются практически в любом языке программирования. Например, они используются для реализации хеш-таблиц и множеств (HashMap/HashSet в Java, dict и set в Python, Map, Set и объекты в JavaScript и так далее). Отдельная категория хеш-функций — криптографические хеш-функции. К ним предъявляются существенно более строгие требования, чем к функциям, обычно используемым в хеш-таблицах. Поэтому и применяются они в более «серьезных» случаях, например для хранения паролей. Криптографические хеш-функции вырабатываются и тщательно проверяются исследователями по всему миру.

Поэкспериментировать с хеш-функциями можно, написав простую программу на Python:

import hashlib
def hash_hex(message):
    return hashlib.sha256(message.encode()).hexdigest()

Функция hash_hex() рассчитывает представление хеша в шестнадцатеричной записи для строки. В приведенном примере используется функция SHA-256 — та же, что и в биткойне.

Хорошая хеш-функция обеспечивает защиту от коллизий (невозможно получить два одинаковых хеша при разных начальных данных) и обладает так называемым эффектом лавины, когда малейшее изменение входных данных значительно преобразует выходное значение. Эффект лавины в хеш-функции SHA-256 выглядит следующим образом:

>>> hash_hex('Blockchain')
'625da44e4eaf58d61cf048d168aa6f5e492dea166d8bb54ec06c30de07db57e1'
>>> hash_hex('blockchain')
'ef7797e13d3a75526946a3bcf00daec9fc9c9c4d51ddc7cc5df888f74dd434d1'
>>> hash_hex('Bl0ckchain')
'511429398e2213603f4e5dd3fff1f989447c52162b0e0a28fe049288359220fc'

Хеш-функции в блокчейнах гарантируют «необратимость» всей цепочки транзакций. Дело в том, что каждый новый блок транзакций ссылается на хеш предыдущего блока в реестре. Хеш самого блока зависит от всех транзакций в блоке, но вместо того, чтобы последовательно передавать транзакции хеш-функции, они собираются в одно хеш-значение при помощи двоичного дерева с хешами (дерево Меркла). Таким образом, хеши используются как замена указателям в обычных структурах данных: связанных списках и двоичных деревьях.

За счет использования хешей общее состояние блокчейна — все когда-либо выполненные транзакции и их последовательность — можно выразить одним-единственным числом: хешем самого нового блока. Поэтому свойство неизменности хеша одного блока гарантирует неизменность всего блокчейна.


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

import hashlib
    
def merkle_root(lst):
    # Биткойн использует для склеивания хешей два прогона SHA-256 и изменение 
    # порядка байтов. Зачем, не до конца понятно.
    sha256d = lambda x: hashlib.sha256(hashlib.sha256(x).digest()).digest()
    hash_pair = lambda x, y: sha256d(x[::-1] + y[::-1])[::-1]

    if len(lst) == 1: return lst[0]
    
    # Дублирование элементов в дереве приводит к интересной уязвимости -
    # получается, что различные списки транзакций могут иметь один и тот же хеш.
    # По этой причине в биткойне даже есть специальный комментарий,
    # предостерегающий разработчиков новых криптовалют:
    # https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L9
    if len(lst) % 2 == 1:
        lst.append(lst[-1])
    return merkle_root([ hash_pair(x, y) 
        for x, y in zip(*[iter(lst)] * 2) ])

Хеш-деревья имеют много применений помимо блокчейнов. Они используются в файловых системах для проверки целостности файлов, распределенных БД для быстрой синхронизации копий и в управлении ключами для надежного журналирования выдачи сертификатов. Git использует обобщение хеш-деревьев — направленные ациклические графы на основе хешей. В блокчейне использование хеш-деревьев продиктовано соображениями производительности, так как они делают возможным существование «легких клиентов», которые обрабатывают лишь малую часть транзакций из блокчейна.

Цифровые подписи


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


Существует множество различных схем криптографии с открытым ключом. Две самые популярные из них — это схемы на основе разложения на множители (RSA) и схемы на основе эллиптических кривых. Последние более популярны в блокчейнах из-за меньшего размера ключей и подписей. Например, в биткойне используется стандарт эллиптической криптографии ECDSA вместе с эллиптической кривой secp256k1. В ней закрытый ключ имеет длину 32 байта, открытый — 33 байта, а подпись — около 70 байт.


Общая идея подписей с открытым ключом выглядит следующим образом. Предположим, что Алиса хочет перевести Бобу один биткойн. Для этого она формирует транзакцию, где записывает, откуда его следует брать (указание на предыдущую транзакцию, в которой Алиса получила биткойн от кого-то еще) и кому отправить (открытый ключ Боба). Алиса знает открытый ключ Боба из сторонних источников — Боб может послать его Алисе через мессенджер или даже опубликовать его на сайте.

Затем Алиса подписывает транзакцию, используя свой секретный ключ. Любой узел в биткойн-сети может проверить, что транзакция подписана определенным открытым ключом (аутентификация), с которым до выполнения транзакции был ассоциирован один биткойн (авторизация). Если эти условия выполнены, то переведенный биткойн начинает ассоциироваться с открытым ключом Боба.

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

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



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

P.P.S. Немного дополнительных источников:

  • Наш англоязычный блог

  • «C чем это едят»: что такое блокчейн
  • Подтверждение доли и доказательство выполнения работы (PoS vs PoW)
  • Смарт-контракты в биткойн-блокчейне
Поделиться с друзьями
-->

Комментарии (14)


  1. grossws
    24.04.2017 22:41
    #10189362

    Хорошая хеш-функция обеспечивает защиту от коллизий (невозможно получить два одинаковых хеша при разных начальных данных)

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


    1. KatbertW
      24.04.2017 23:04
      #10189388

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


      1. grossws
        24.04.2017 23:51
        #10189438
        +1

        Это не то же самое. Невозможность — это невозможность.


        Перебрав все сообщения длиной размера хэша и плюс одно длиной размер хэша + 1 мы получим гарантированную коллизию. Благодаря парадоксу дней рождения получим её с хорошей вероятностью ещё раньше (2^(n/2)). А устойчивость — это высокая вероятность того, что эта коллизия получается не сильно дешевле, чем перебором (2^(n/2)).


        1. andrewzhuk
          25.04.2017 00:06
          #10189454

          Игра слов из серии «адаптивный дизайн» и «отзывчивый дизайн». В англоязычной википедии требования описываются фразой "it should be difficult to find", в русскоязычной — "должно быть вычислительно невозможно".


          1. grossws
            25.04.2017 00:22
            #10189464

            Но при этом ни одно из выражений не утверждает о невозможности. Вычислительно невозможно != невозможно. Difficult to find != impossible to find.


            1. andrewzhuk
              25.04.2017 00:41
              #10189482
              +1

              Хотел ответить мемом с Дружко, но делать этого я конечно не буду.

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


  1. k0sh
    24.04.2017 23:08
    #10189394

    Спасибо за статью. Как продавцы за биткоины понимают что именно я заплатил за товар?


    1. KatbertW
      24.04.2017 23:42
      #10189430
      +3

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


    1. Gorthauer87
      25.04.2017 15:10
      #10190436
      +1

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


  1. pansa
    25.04.2017 00:00
    #10189448
    -4

    Очередная статья про блокчейн в стиле «как нарисовать сову».
    В одну руку берем хэш. В другую руку берем ассиметричное шифрование… вжууух! Смотрите, какой крутой блокчейн получился, он может то-то и то-то!


  1. rule
    25.04.2017 05:30
    #10189554
    +1

    Хорошо написано, продолжайте пожалуйста.


  1. haiflive
    25.04.2017 07:21
    #10189578

    а можно немного разъяснить, Алиса передала часть суммы со своего кошелька Бобу, оба использовали свой открытый ключ, что мешает Бобу создать новую транзакцию Алисы и опустошить кошелёк Алисы? Как это регулируется в биткоин?


    1. alinatestova
      25.04.2017 09:18
      #10189680

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


    1. QDeathNick
      29.04.2017 01:40
      #10197066

      Для создания транзакции нужен закрытый ключ. Боб его не знает после первой транзакции.

МЕТКИ

  • Хабы
  • Теги

Разработка под e-commerce

Криптография

Информационная безопасность

Блог компании Bitfury Group

криптография

bitfury

СЕРВИСЫ
  • logo

    CloudLogs.ru - Облачное логирование

    • Храните логи вашего сервиса или приложения в облаке. Удобно просматривайте и анализируйте их.
Все публикации автора
  • Bitfury Group провела 1-ю транзакцию в Lightning Network c использованием биткойн-протокола +14

    • 21.07.2017 12:41

    «Ультимативный» блокчейн-дайджест: полезные материалы на Хабре и другие источники по теме +14

    • 18.07.2017 05:31

    «Ваш следующий шаг к блокчейну»: релиз платформы Exonum от Bitfury Group +18

    • 17.07.2017 06:50

    Рынок систем детекции и распознавания: Эмоции и «эмоциональные вычисления» +11

    • 07.07.2017 08:45

    Bitfury Group провела первую успешную multi-hop-транзакцию в сети Lightning Network +14

    • 04.07.2017 15:40

    Как запустить надстройку над биткойн-блокчейном +16

    • 20.06.2017 08:14

    Как масштабировать биткойн-блокчейн +14

    • 13.06.2017 07:18

    Что такое эксклюзивные блокчейны +8

    • 08.06.2017 07:26

    Иное применение блокчейнов: Смарт-контракты +14

    • 06.06.2017 10:12

    Подкаст «Правила игры»: бухгалтерские тонкости для технологического (и другого) бизнеса +10

    • 11.05.2017 10:01

Подписка


ЛУЧШЕЕ

  • Сегодня
  • Вчера
  • Позавчера
09:01

От React всё также веет безумием, но все об этом молчат +21

08:02

Commodore 64 Ultimate: возрождение легенды в 2025 году +12

08:16

«Хочу, но боюсь и не делаю»: что делать со страхом того, что не получится? +7

06:15

Vue: Composables и TS это вам не Mixins и JS. С ними сложнее +6

04:41

Управление проектами: дайджест публикаций #36 +6

07:16

Конфаундинг, или как аналитику попасть в ловушку +5

05:16

Алгоритмы для работы с большими данными в Go: HyperLogLog и Count-Min Sketch +5

09:02

Kubernetes на базе Deckhouse в облаке Linx Cloud: встроенный мониторинг, безопасность и управление сертификатами +4

08:13

Новый рекорд по упаковке сфер неожиданно пришёл из геометрии +4

10:15

Как дизайн Kaspersky Thin Client пережил подростковый бунт (и что из этого вышло) +3

10:15

Как дизайн Kaspersky Thin Client пережил подростковый бунт (и что из этого вышло) +3

12:15

Алгоритм Диница: как найти максимальный поток в сети (для начинающих) +2

10:08

Свой ChatGPT на документах: делаем RAG с нуля +2

07:36

Продолжаем делать реализацию LISP на Python. Часть 1: структуры +2

09:52

Скоро без нас: когда роботы окончательно отберут нашу работу? +1

07:18

Применение языка Python в инженерной практике. Точность измерений и вычислений. Погрешности и неопределённости +1

08:41

Как в РФ разрабатывали уникальный судовой радар ближней зоны в диапазоне 76 ГГц +62

09:01

Первые анекдоты о программистах: юмор айтишников на переломе тысячелетий, 1999-2000 годы +49

00:21

Исследование METR: использование Cursor замедляет опытных разработчиков на 19 % +38

05:29

VLESS+Reality и Multi-hop: Архитектура VPN-цепочки для нового поколения блокировок +36

13:01

Голографический принцип: реальность как иллюзия +35

12:00

Самодельный компьютерный стол с навороченной начинкой внутри за 20 шагов +33

18:16

Территория Большого Взрыва. Что, где и когда взорвалось +26

14:05

Drift Skate, Freeskates, Freeline Skates, Кайф +20

08:14

Xreal One Pro — подробный разбор новых AR-очков с чипом X1 и экраном до 191 дюйма +19

17:29

Ещё один PID-контроллер +16

16:32

Девушки, котики и Flux Kontext: как выжать максимум из WebUI Forge? +15

21:09

Не хватило мощности: история бренда «Техносила» +13

06:05

История игровой журналистики в России +12

11:29

«Почему топ менеджеры выбирали SAP, но...» что пошло не так у автора +8

05:48

Универсальные подсказки по промптам (продвинутые советы) (Ч.2) +8

14:44

Разработка требований к ПО с помощью Markdown, Git и Obsidian +7

01:17

Сделай удобно: подборка UI/UX-кейсов из цифровых и нецифровых продуктов (#18) +7

18:46

Открытые инструменты для визуализации сетевого трафика +4

20:45

Цистеин. Как одна аминокислота мешает худеть. И спасибо ей за это +3

04:37

Laravel: электронная подпись на сервере с PDF визуализацией +3

13:01

Блеск и ад p2p-торговли на Bybit +73

08:07

Хронометр Гаррисона: прибор, спасший жизни сотен моряков +73

09:01

Самодельные любительские радиолампы. Франция, 1920 г. Часть 1 +68

13:20

Август 2009. Катастрофа в Саянах +57

08:06

Novomatic Coolfire. Самый навороченный игровой автомат двухтысячных +39

00:26

С торца — экран, внутри — эпоха: портативные (носимые) компьютеры 80-85 гг +34

08:01

ZFS on Linux: установка Ubuntu с корнем в ZFS, RAID и шифрованием +32

14:17

От Аристотеля до Тьюринга: что такое функциональное программирование и как оно облегчает жизнь +28

12:00

Python в Enterprise-разработке: почему популярность ЯП распространилась и на корпоративный сектор. Часть 1 +27

12:36

Руководство по pgcrypto — шифрование внутри PostgreSQL. Часть 2 +22

09:58

«IT-Планета 2025»: задачи третьего этапа по PostgreSQL +20

07:45

От промтов к агентам: как мы дошли до трансформеров, что LLM умеют уже сейчас и что нас ждёт в 2027 году +19

16:17

Почему топ менеджеры выбирали SAP, но не выбирали 1С, а теперь они тусуются на ЦИПР? +18

10:22

Как уменьшить размер модели Power BI на 90% +18

07:00

Хронический тонзиллит: «резать» или терпеть? Вот в чём вопрос +18

21:12

Сознание — не место для дискуссий +17

09:07

Краткий обзор платформы данных Т-Банка +16

11:59

Маленькое приключение в поиске ошибок. The Battle for Wesnoth +14

22:33

Как измеряется работа выполненная в z/OS и что из этого следует +13

16:12

AutoPrompting: как улучшить промпты, сэкономив время и ресурсы промпт-инженеров +13

ОБСУЖДАЕМОЕ

  • Самодельный компьютерный стол с навороченной начинкой внутри за 20 шагов +33

    • 151   22000

    Max от VK — мессенджер, который хочет стать российским WeChat. Что уже есть и что не так? -16

    • 136   23000

    Почему топ менеджеры выбирали SAP, но не выбирали 1С, а теперь они тусуются на ЦИПР? +18

    • 126   36000

    VLESS+Reality и Multi-hop: Архитектура VPN-цепочки для нового поколения блокировок +36

    • 84   25000

    Территория Большого Взрыва. Что, где и когда взорвалось +26

    • 65   8400

    «Почему топ менеджеры выбирали SAP, но...» что пошло не так у автора +8

    • 59   3500

    Блеск и ад p2p-торговли на Bybit +73

    • 58   19000

    От Аристотеля до Тьюринга: что такое функциональное программирование и как оно облегчает жизнь +28

    • 53   8000

    ZFS on Linux: установка Ubuntu с корнем в ZFS, RAID и шифрованием +32

    • 53   4500

    Исследование METR: использование Cursor замедляет опытных разработчиков на 19 % +38

    • 51   13000

    Хабра-харакири 2: Как я спросил, и мне ответили +2

    • 40   2200

    Самодельные любительские радиолампы. Франция, 1920 г. Часть 1 +68

    • 38   7900

    Сознание — не место для дискуссий +17

    • 37   2400

    Шаг за шагом проектируем сокращатель ссылок +2

    • 35   4400

    Python в Enterprise-разработке: почему популярность ЯП распространилась и на корпоративный сектор. Часть 1 +27

    • 34   3800
  • Главная
  • Контакты
© 2025. Все публикации принадлежат авторам.