본문으로 이동
Financial Context Wiki

BLS 서명

Boneh-Lynn-Shacham 서명, 집계 방식, 암호 스위트, rogue-key 방어, 이더리움 합의 활용 및 구현 위험을 검증 중심으로 설명합니다.

업데이트

교육 참고용이며 투자 또는 암호 구현 조언이 아닙니다. 서명의 유효성만으로 프로토콜 안전성, 인가, 가용성 또는 최종성을 입증할 수 없습니다.

직접 답변

Boneh-Lynn-Shacham 서명은 페어링 기반 디지털 서명입니다. 일반적인 방향 중 하나에서 비밀 키 sk 는 공개 키 PK = sk * G1 을 생성하고, 메시지 m 은 H(m) 으로 매핑됩니다. 이 점은 G2 에 속하며, 서명 sig = sk * H(m) 은 e(PK, H(m)) = e(G1, sig) 로 검증됩니다. 정확한 군, 인코딩, hash-to-curve 스위트와 도메인 분리는 암호 스위트의 선택 사항이며 서로 바꿔 쓸 수 있는 표기가 아닙니다.

BLS에는 유효한 서명을 더해 하나의 고정 크기 군 원소로 만들 수 있다는 독특한 운영상 장점이 있습니다. 이는 서명을 압축하지만 서명자 목록을 압축하거나, 정족수를 입증하거나, 인가된 검증자를 식별하거나, 이중 투표를 막거나, 합의를 최종화하지는 않습니다. 그런 속성은 주변 프로토콜에서 나옵니다.

작동 방식

  1. 프로토콜, 암호 스위트 및 버전을 고정합니다. 곡선, 공개 키 군과 서명 군, 직렬화, hash-to-curve 함수, 도메인 분리 태그 및 메시지 루트 구성을 확인합니다. BLS라는 명칭만 보고 호환성을 추론해서는 안 됩니다.
  2. 지정된 키 생성 절차로 sk 를 생성하고 PK 를 도출합니다. 정확한 KeyValidate 및 역직렬화 규칙에 따라 0, 무한원점, 잘못된 형식, 비정규 및 잘못된 부분군 인코딩을 거부합니다.
  3. 정확한 메시지 바이트와 서명 도메인을 구성합니다. 이더리움 합의에서 서명 루트는 SSZ 객체 루트를 작업 유형과 포크 데이터에서 도출된 도메인에 결속합니다. 화면에 표시된 문구가 서명 객체는 아닙니다.
  4. 선택한 방식으로 서명하고 개별 검증합니다. Basic, message augmentation, proof of possession 변형은 rogue-key 방어 방식이 다르므로 임의로 섞을 수 없습니다.
  5. 메시지 패턴에 따라 집계 검증기를 선택합니다. 여러 검증된 공개 키가 필요한 소유 증명 가정 아래 동일한 메시지에 서명한 경우에만 FastAggregateVerify 를 사용합니다. 방식에서 허용하는 공개 키 및 메시지 목록에는 AggregateVerify 를 사용합니다.
  6. 위원회 데이터 또는 참가자 비트 목록으로 서명자 집합을 독립적으로 재구성하고, 중복되거나 인가되지 않은 인덱스를 거부하며, 스테이크 또는 임계값 가중치를 적용한 뒤 집계 서명을 검증합니다. 유효한 집계는 제공된 집합을 인증하지만 그 집합이 정책을 충족하는지는 결정하지 않습니다.
  7. 결과를 포크 선택, 슬래싱 조건, 정족수, 가용성, 시점 및 최종성과 대조합니다. 입력 바이트, 도메인, 서명자 인덱스, 구현 버전 및 테스트 벡터를 보존하고 배포 전에 독립 라이브러리끼리 비교합니다.

계산 예시

  • 압축해도 구성원 데이터는 없어지지 않는다. 이더리움 합의는 각 BLS 공개 키를 48 bytes, 각 서명을 96 bytes 로 인코딩합니다. 동일한 메시지에 대한 서명이 512 개이면 개별 서명은 512 * 96 = 49,152 bytes 를 차지합니다. 하나의 집계 서명과 512-bit = 64-byte 참가자 비트 목록은 96 + 64 = 160 bytes 이며, 49,152 - 160 = 48,992 bytes, 즉 99.6744791667% 감소입니다. 검증자 공개 키와 위원회 매핑은 여전히 다른 곳에서 이용할 수 있어야 합니다.
  • 동일 메시지 집계. 등록된 검증자 17, 24, 91 이 모두 동일한 서명 루트 R 에 서명한다고 가정합니다. 서명은 sigAgg = sig17 + sig24 + sig91 로 집계됩니다. 검증에는 순서가 지정되고 검증된 공개 키 집합 [PK17, PK24, PK91], 동일한 R, FastAggregateVerify 를 사용합니다. 유효한 결과는 이 방식 아래 해당 키가 R 에 서명했음을 입증합니다. 키별 가중치와 세 명이 정족수를 구성하는지는 별도 규칙이 결정합니다.
  • 서로 다른 메시지에는 올바른 API가 필요하다. 공개 키 PK1, PK2, PK3 이 서로 다른 메시지 m1, m2, m3 에 서명합니다. 검증기는 쌍 [PK1, m1], [PK2, m2], [PK3, m3] 을 보존하고 해당 AggregateVerify 를 호출해야 합니다. 입력을 하나의 메시지로 바꾸고 FastAggregateVerify 를 사용하면 다른 주장을 검증하게 됩니다. Basic 방식에서는 메시지들도 서로 달라야 합니다.
  • 집계는 임계 서명이 아니다. 8 명 그룹에서 구성원 [1, 2, 4, 6, 8] 의 일반 서명을 집계하면 서명 하나와 5명짜리 서명자 목록이 생성됩니다. 하나의 그룹 공개 키로 검증되는 5-of-8 임계 서명이 되지는 않습니다. 진정한 threshold BLS 설계에는 분산 키 생성 또는 신뢰할 수 있는 딜러 모델, 공유 인덱스 및 보간 규칙이 필요하며 그 신뢰와 실패 가정은 별도로 감사해야 합니다.

위험

  • 프로토콜과 다른 곡선, 군 방향 또는 암호 스위트를 사용하는 경우.
  • 같은 사람이 읽을 수 있는 메시지를 표시하면서 다른 직렬화 바이트에 서명하는 경우.
  • 포크, 작업 또는 애플리케이션 도메인을 생략해 맥락 간 재실행을 허용하는 경우.
  • 만료된 Internet-Draft를 변경 불가능한 최종 표준으로 취급하는 경우.
  • 형식이 잘못되었거나 비정규이거나 무한원점인 인코딩을 받아들이는 경우.
  • 부분군 검사를 건너뛰고 잘못된 곡선 또는 작은 부분군 입력을 허용하는 경우.
  • 지정된 스위트와 테스트 벡터 대신 임의의 hash-to-curve 코드를 사용하는 경우.
  • 편향되거나, 0이거나, 중복되거나, 유출되거나, 예측 가능하게 도출된 비밀 키를 생성하는 경우.
  • 소유 증명과 도메인 가정이 다른 프로토콜에서 하나의 키를 재사용하는 경우.
  • 방식에서 요구하는 rogue-key 방어 없이 등록되지 않은 공개 키를 집계하는 경우.
  • 서로 다른 메시지나 일치하지 않는 루트에 동일 메시지 고속 검증을 호출하는 경우.
  • 공개 키와 메시지의 대응 관계를 순열, 중복 또는 누락하는 경우.
  • 위원회 소속과 고유 인덱스를 확인하지 않고 참가자 비트 목록을 신뢰하는 경우.
  • 프로토콜이 정의한 스테이크, 가중치 또는 임계값이 아니라 서명 수를 세는 경우.
  • 하나의 집계로 어떤 개별 서명이 무효인지 알 수 있다고 가정하는 경우.
  • 일반 집계, 다중 서명 및 임계 서명을 혼동하는 경우.
  • 서명 유효성을 데이터 가용성, 실행 정확성 또는 최종성의 증명으로 여기는 경우.
  • 이중 투표, 슬래싱 대상 메시지, 시간 창 또는 포크 선택 맥락을 무시하는 경우.
  • 하나의 라이브러리, CPU 기능 또는 검토되지 않은 일괄 검증 최적화에 의존하는 경우.
  • 페어링 비용, 서비스 거부 입력, 부채널, 키 보관, 업그레이드 및 양자 내성 부재를 과소평가하는 경우.

흔한 오해

  • 집계 서명은 모든 검증자가 참여했음을 입증한다.
  • 소유 증명 규칙 없이 어떤 BLS 공개 키와 서명도 안전하게 결합할 수 있다.
  • 고정 크기 집계를 사용하면 서명자 구성원 정보를 전송하거나 재구성할 필요가 없다.
  • BLS 집계와 threshold BLS는 같은 구성이다.
  • 유효한 BLS 서명이 있으면 서명된 블록, 브리지 메시지 또는 프로토콜이 경제적으로 안전하고 최종화된다.

관련 주제

출처

탐색

위키 검색...