Криптография
Продвинутые ECC
Ethereum 2.0: 500 000 валидаторов подписывают каждый блок. Без BLS-агрегации верификация заняла бы минуты. С BLS - одна операция спаривания за миллисекунды. Математика спаривания на эллиптических кривых сделала Ethereum Proof-of-Stake возможным в принципе.
- **Ethereum PoS**: BLS12-381, 48-байтные подписи валидаторов. Агрегация ~500k подписей в одну для каждого checkpoint.
- **Chia Network**: BLS подписи для транзакций. Агрегация всех подписей в блоке в одну.
- **Azure Information Protection**: CP-ABE концептуально (в упрощённой форме) для классификации документов. Политики 'Confidential\Encrypt' -> только сотрудники с атрибутом.
- **drand**: публичная случайность через threshold BLS. Cloudflare, EPFL, Protocol Labs совместно генерируют непредсказуемую публичную случайность.
Билинейные спаривания: новая операция над кривыми
Билинейное спаривание e: G1 x G2 -> GT - операция над двумя группами эллиптических кривых в целевую группу. Ключевое свойство: e(a*P, b*Q) = e(P, Q)^(ab). Это позволяет вычислять с экспонентами 'одновременно' - что невозможно в обычных ECC операциях.
Pairing-friendly кривые уязвимы к MOV-атаке: ECDLP сводится к DLP в GT через спаривание. Поэтому кривые выбираются так, что embedding degree k достаточно большой (12 для BLS12-381), делая DLP в GT таким же сложным как ECDLP.
Что позволяет делать свойство e(a*P, b*Q) = e(P, Q)^(ab)?
BLS подписи: агрегация миллионов подписей
BLS (Boneh-Lynn-Shacham, 2001): подписи агрегируются в одну через сложение. Миллион подписей валидируется за одну операцию спаривания. Это критично для блокчейнов: Ethereum 2.0 использует BLS для подписей валидаторов.
IETF RFC 9380 (HashToCurve) и RFC 9382 (BLS Signature) - стандарты 2023. Ethereum использует BLS12-381 кривую. Chia Network, Filecoin, Algorand также используют BLS. Rogue-key атака решается через proof of possession или domain separation в хэш.
Почему BLS подписи критически важны для Ethereum 2.0 с 500k валидаторами?
IBE: шифрование на основе идентичности
IBE (Identity-Based Encryption, Boneh-Franklin, 2001): публичный ключ = произвольная строка (email, phone). Отправитель шифрует на 'alice@company.com' без предварительного получения ключа. PKG (Private Key Generator) выдаёт приватные ключи по запросу.
Voltage Security (поглощена HPE) - коммерческая реализация IBE для защиты email. Военные применения: шифровать на 'Colonel Smith, Unit 5' без предварительного обмена ключами в поле. Проблема key escrow (PKG читает всё) ограничивает широкое применение.
Какая фундаментальная проблема IBE ограничивает его применение?
ABE: шифрование на основе атрибутов
ABE (Attribute-Based Encryption): расширение IBE где доступ определяется политиками на атрибутах. CP-ABE (Ciphertext-Policy): шифровать с политикой '(HR AND Manager) OR CEO'. Расшифровать может тот, чьи атрибуты удовлетворяют политике.
ABE используется в Microsoft Azure Information Protection для классификации документов (Confidential, Internal, Public). NIST изучает ABE для federal data sharing. Основная проблема: атрибуты выдаёт Authority - key escrow в отдельных атрибутах. Multi-authority ABE распределяет это доверие.
Чем CP-ABE (Ciphertext-Policy) отличается от KP-ABE (Key-Policy)?
Итоги
- **Билинейные спаривания**: e(a*P, b*Q) = e(P,Q)^(ab). Новая математическая операция открывает IBE, BLS, ZKP. Кривые BN254 и BLS12-381.
- **BLS подписи**: агрегация n подписей в одну за сложение в G1. Одна верификация для всех. Ethereum PoS с 500k валидаторами.
- **IBE**: публичный ключ = строка идентичности. Нет PKI. Ограничение: key escrow у PKG.
- **CP-ABE**: политики доступа в шифртексте. Расшифровывает кто удовлетворяет атрибутной политике. Применения в enterprise DRM и медицинских данных.
Связанные темы
Продвинутые ECC строятся на математике спаривания:
- ECC математика — Спаривания - расширение обычных ECC операций на специальные pairing-friendly кривые.
- ZK-SNARKs — Groth16 и другие SNARKs используют спаривания на BN254 для верификации доказательств. Pairing-check в центре протокола.
- PKI и сертификаты — IBE концептуально альтернативна PKI: нет сертификатов, но есть key escrow у PKG.
Вопросы для размышления
- BLS подписи уязвимы к rogue-key атаке: Bob публикует pk = Bob_real - Alice_pk, делая агрегированный ключ = Bob_real. Как proof-of-possession предотвращает это?
- IBE и ABE оба имеют key escrow проблему. Как Multi-Authority ABE распределяет доверие между несколькими независимыми authorities?
- drand использует threshold BLS (t-of-n) для публичной случайности. Почему это безопаснее одного сервера рандомности?