Цифровые подписи: ECDSA и EdDSA

Bitcoin-транзакция проходит через десятки незнакомых нод по всему миру. Ни одна из них не знает отправителя лично. Но каждая может математически доказать, что именно владелец ключа - и никто другой - авторизовал этот перевод. Без паспорта, без пароля, без центрального сервера. Как? С помощью цифровых подписей - технологии, которая превращает случайное 256-битное число в неподделываемую «печать» на каждой транзакции.

• **Bitcoin** - каждая транзакция содержит ECDSA-подпись. Сеть обрабатывает ~400 000 подписей в день, и каждая верифицируется каждой полной нодой
• **Solana** - использует Ed25519 для скорости: верификация ~65 000 подписей в секунду необходима для пропускной способности сети
• **Ethereum** - ECDSA на secp256k1 защищает каждый перевод ETH, вызов смарт-контракта и deploy. С Taproot-аналогом (EIP-7702) экспериментируют для account abstraction

Диффи, Хеллман и рождение асимметричной криптографии

В 1976 году Уитфилд Диффи и Мартин Хеллман опубликовали статью *"New Directions in Cryptography"*, которая перевернула мир криптографии. До этого вся криптография была **симметричной**: отправитель и получатель должны были заранее обменяться секретным ключом. Для военных и дипломатов это работало, но для интернета - нет. Диффи и Хеллман предложили идею **асимметричных** ключей: два математически связанных ключа, один из которых можно публиковать открыто. Позже выяснилось, что британская спецслужба GCHQ пришла к тем же идеям на несколько лет раньше (Джеймс Эллис и Клиффорд Кокс), но засекретила результаты.

Без асимметричной криптографии не было бы ни HTTPS, ни блокчейна, ни даже возможности безопасно зайти на сайт. Каждый раз, когда браузер показывает замочек - работает наследие Диффи и Хеллмана.

Предварительные знания

• Hash Functions: the foundation of blockchain

Пары ключей: асимметричная криптография

До 1976 года у криптографии была фундаментальная проблема: чтобы обменяться секретным сообщением, отправитель и получатель должны были **заранее договориться** о секретном ключе. Но как передать ключ по незащищённому каналу?

**Асимметричная криптография** решила эту проблему, разделив ключ на два: **приватный** (secret key) и **публичный** (public key). Они математически связаны, но зная публичный - вычислить приватный невозможно.

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

**Приватный ключ = полный контроль.** Кто знает приватный ключ - владеет всеми средствами на адресе. Нет «восстановления пароля», нет службы поддержки. По оценкам, **3.7 миллиона BTC** (~150 млрд) потеряны навсегда из-за утраченных приватных ключей.

**Почему нельзя вычислить приватный ключ из публичного?** Это задача дискретного логарифма на эллиптической кривой (ECDLP). Для secp256k1 лучший известный алгоритм потребует ~$2^{128}$ операций - больше, чем атомов в Солнечной системе.

ECDSA: подписи Bitcoin

**ECDSA** (Elliptic Curve Digital Signature Algorithm) - алгоритм цифровой подписи, используемый в **Bitcoin**, **Ethereum** и большинстве ранних блокчейнов. Он основан на математике эллиптических кривых - Bitcoin использует кривую **secp256k1**.

Процесс подписания транзакции: 1. Берём данные транзакции и вычисляем их **хеш** (SHA-256) 2. Генерируем **случайное число k** (nonce) - критически важный шаг! 3. Вычисляем точку на кривой $R = k \cdot G$, берём её x-координату как $r$ 4. Вычисляем $s = k^{-1} \cdot (hash + r \cdot privateKey) \mod n$ 5. Подпись - это пара $(r, s)$

**Почему secp256k1?** Сатоши Накамото выбрал эту кривую для Bitcoin вместо популярной NIST P-256. Причина: secp256k1 была создана компанией Certicom и имеет «прозрачные» параметры (т.н. *nothing-up-my-sleeve numbers*), тогда как параметры NIST-кривых подозревают в наличии бэкдора от NSA.

**Критическая уязвимость: nonce reuse.** Если при подписании двух разных сообщений использовать **одинаковый** nonce $k$, приватный ключ **извлекается напрямую**: $privateKey = (s_1 - s_2)^{-1} \cdot (hash_1 \cdot s_2 - hash_2 \cdot s_1) \cdot r^{-1}$ Именно так в 2010 году **Sony** потеряла мастер-ключ PlayStation 3: они подписали все обновления с одним и тем же $k$. Хакеры вычислили приватный ключ и получили полный контроль над консолью.

EdDSA: следующее поколение подписей

**EdDSA** (Edwards-curve Digital Signature Algorithm) - современная альтернатива ECDSA, разработанная Дэниелом Бернштейном в 2011 году. Самая популярная реализация - **Ed25519** на кривой Curve25519.

EdDSA решает три серьёзные проблемы ECDSA:

**Кто использует EdDSA?** - **Solana** - Ed25519 для всех транзакций (скорость критична при 65 000 TPS) - **Cardano** - Ed25519 Extended для иерархических ключей - **Polkadot** - Sr25519 (Schnorr на Ristretto255, родственник EdDSA) - **SSH/TLS** - Ed25519 стал стандартом для SSH-ключей (`ssh-keygen -t ed25519`)

**Почему Bitcoin до сих пор на ECDSA?** Bitcoin добавил поддержку Schnorr-подписей (BIP-340, Taproot, 2021) - они разделяют преимущества EdDSA. Полный переход на Ed25519 потребовал бы hard fork, на который сообщество не решается. Ethereum тоже остаётся на ECDSA (secp256k1) по той же причине.

Верификация подписей в блокчейне

Каждая нода в блокчейне **самостоятельно проверяет** каждую подпись каждой транзакции. Нет центрального органа - «доверие через математику». Но когда сеть обрабатывает тысячи транзакций в секунду, верификация подписей становится **узким местом**.

**Batch Verification** - техника, позволяющая проверить **N подписей быстрее**, чем проверять каждую по отдельности. Ed25519 поддерживает это нативно:

**Multisig (multi-signature)** - схема, требующая подписи от нескольких участников. Популярная конфигурация **2-of-3**: из трёх ключей достаточно **двух** подписей для авторизации транзакции.

**Атаки на подписи** - реальные инциденты, которые сформировали современные стандарты безопасности:

**Schnorr-подписи (BIP-340)** - будущее Bitcoin. Преимущества: - **Линейность**: N подписей в multisig сжимаются в **одну** - экономия места и gas - **Batch verification**: как EdDSA, поддерживают быструю пакетную проверку - **Privacy**: multisig-транзакция неотличима от обычной - наблюдатель не знает, сколько подписантов участвовало

Ключевые идеи

• **Пара ключей** - приватный ключ (секрет, 256 бит) и публичный ключ (адрес кошелька). Приватный подписывает транзакции, публичный позволяет любому проверить подпись
• **ECDSA** (secp256k1) - алгоритм подписи Bitcoin и Ethereum. Требует уникальный случайный nonce для каждой подписи, иначе приватный ключ раскрывается (как в случае Sony PS3)
• **EdDSA** (Ed25519) - современная альтернатива: детерминированный nonce, в 2-3 раза быстрее, устойчивость к side-channel атакам. Используется в Solana, Cardano и SSH
• **Multisig** (2-of-3) защищает от кражи одного ключа, а **batch verification** ускоряет проверку тысяч подписей. Важно: подпись не шифрует данные - она доказывает авторство, как та самая математическая «печать», которая позволяет десяткам незнакомых нод доверять каждой транзакции

Связанные темы

Цифровые подписи - мост между криптографическими примитивами и реальными блокчейн-протоколами:

• Хеш-функции — SHA-256 хеширует транзакцию перед подписанием - подпись защищает хеш, а хеш защищает данные
• Эллиптические кривые — Математический фундамент ECDSA и EdDSA - операции на кривых secp256k1 и Curve25519
• Bitcoin UTXO — Каждый UTXO «заперт» скриптом, требующим ECDSA-подпись владельца для траты
• Ethereum Transactions — Каждая транзакция содержит (v, r, s) - компоненты ECDSA-подписи, из которых восстанавливается адрес отправителя

Вопросы для размышления

• Квантовые компьютеры смогут взломать ECDSA и EdDSA (алгоритм Шора). Как блокчейн-сети готовятся к этому? Что произойдёт с Bitcoin, если квантовый компьютер появится раньше, чем сеть перейдёт на постквантовые подписи?
• Если приватный ключ - всего лишь случайное число, что мешает злоумышленнику случайно сгенерировать чужой ключ? Пространство ключей - 2^256. Какова вероятность коллизии?
• Multisig 2-of-3 защищает от кражи одного ключа. Но что если нужно защитить DAO с 1000 участниками? Почему наивный multisig 500-of-1000 не работает, и какие альтернативы существуют (threshold signatures, MPC)?

Связанные уроки

• bc-02-hashing — Digital signatures sign the hash of a message; hashing is the prerequisite
• bc-07-ecc — ECC is the math behind ECDSA (the signature scheme used in Bitcoin/Ethereum); signatures lesson is the abstract intro
• bc-22-bitcoin-utxo — Bitcoin UTXO spending requires a valid signature over the transaction hash
• bc-10-bls — BLS is an advanced signature scheme that supports aggregation; classical signatures are the prerequisite
• crypto-28-digital-signatures