• Главная
  • Контакты
Подписаться:
  • 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

Подписка


ЛУЧШЕЕ

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

Погружение в многозадачность Python: процессы, потоки, GIL и асинхронность +3

11:00

Новые правила Хабра. Версия от 2026 +164

07:01

Звуки музыки советских ПЭВМ +55

07:52

YaFF в опенсорсе: как и зачем мы сделали zero‑copy представление для Protobuf +45

14:05

Почему мы до сих пор неправильно пишем физические движки и 3D-графику +39

12:01

Интервью автора легендарной Elite Йена Белла (Эксклюзив для Хабра) +37

07:12

Почему советы «как улучшить резюме» в IT в 2026 — это издевательство (и что делать вместо этого) +28

08:00

История виртуализации от chroot и jails до современных гипервизоров +27

14:17

Как «Союз» считал орбиту шестерёнками: внутри навигационного компьютера «Глобус» +19

13:01

Docker Fundamentals: теория и базовая эксплуатация +19

09:01

Как выбрать самый безопасный мессенджер +19

14:38

Условная агрегация в SQL: ускоряем отчеты, избавляясь от лишних JOIN-ов и подзапросов +17

22:46

Адаптация в команде есть? А если найду? +15

08:00

Код в эпоху AI: как перестать бороться за качество и начать контролировать деградацию +14

07:05

Zynq 7000. Переносим I²C Master Controller.  Linux + buildroot + kernel driver +14

13:17

Как незаметная indirect-зависимость в Go дописала ручку в ваш HTTP-сервер +13

12:37

Лонсдейлитовая кромка. Перспективы искусственного расширения шкалы Мооса. Guest Post +13

09:07

Пора редактировать людей +12

12:39

Как в 1915 году взялись собирать базу данных на всю страну без единого компьютера +11

08:00

Технический и продуктовый мониторинг за кастомизациями Битрикс24: как настроить и на что смотреть +11

02:07

Динамический полиморфизм против std::variant с указателями: Разрушаем мифы о скорости std::visit (v.2*) +11

13:01

Как я написал «Обратную змейку» на чистом Canvas +65

12:06

Реальные профессии будущего, а не «промпт-инженер» и про то, как мировой средний класс исчезает +57

07:50

Claude Code убрал из моей работы рутину и почему я этому не долго радовался +54

09:01

Вы не знаете HTML. Мои вопросы об HTML с ответами +53

07:00

Рояль на даче: использую ПЛК на Linux как real-time-синтезатор фортепиано +37

12:00

Железный дайджест за май: тесты B300, GPU от Alibaba и PCIe 8.0 +36

07:05

1 Вольт, как эталон: как, когда, каким образом +35

13:06

Как работает передача данных в радиоэфире: прогоняем картинки с котиками через ресурсную сетку +34

08:00

Как я пытался создать шедевр в Qwen, Luma и Pika, и что из этого вышло +30

07:02

О конференции OpenTalks.AI 2026: мои впечатления и 5 полезных докладов +28

07:01

MCP vs CLI + Skill: что выгоднее для ИИ‑агента при работе с внутренними API +26

14:27

Banned Book Library +24

15:53

ID, token, UUID и slug: в чём разница и почему их нельзя мешать +23

11:14

QA на уровне платформы: как мы строили систему качества +21

08:10

Время нанимать overqualified +20

12:02

PostgreSQL не тормозит. Почему мы перестали масштабировать базу данных и начали масштабировать архитектуру +16

12:02

PostgreSQL не тормозит. Почему мы перестали масштабировать базу данных и начали масштабировать архитектуру +16

09:43

Человек, укравший бесконечность: подлинная история Георга Кантора +16

07:00

Как я проектировал космический ковчег, который не ломает физику +16

06:41

Как ораклист сертификацию по Postgres сдавал +16

ОБСУЖДАЕМОЕ

  • Новые правила Хабра. Версия от 2026 +164

    • 286   16000

    Реальные профессии будущего, а не «промпт-инженер» и про то, как мировой средний класс исчезает +57

    • 177   31000

    Claude Code убрал из моей работы рутину и почему я этому не долго радовался +54

    • 67   13000

    Почему советы «как улучшить резюме» в IT в 2026 — это издевательство (и что делать вместо этого) +28

    • 49   9700

    Generic Repository обещал три вещи — не сдержал ни одной и забрал доменную модель +5

    • 48   11000

    Как я проектировал космический ковчег, который не ломает физику +16

    • 45   7000

    Парадокс Open-Source: Единственный способ победить корпорации — раздать свой код бесплатно +9

    • 40   7500

    OS Personium: инженерный подход к психологии +5

    • 38   6000

    ЦОДам в Москве отказывают в сети, они вынуждены строить электростанции +4

    • 30   7000

    Время нанимать overqualified +20

    • 29   9200

    Как я написал «Обратную змейку» на чистом Canvas +65

    • 27   16000

    Звуки музыки советских ПЭВМ +55

    • 25   9500

    MAX Light — легкая версия клиента MAX для ПК Windows +9

    • 25   6900

    Кому с AI жить хорошо +6

    • 23   11000

    Вы не знаете HTML. Мои вопросы об HTML с ответами +53

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