양자 위협 대응을 위한 이중 서명 단편화 DNSSEC

기본 정보

• 논문 ID: 2411.07535
• 제목: Double-Signed Fragmented DNSSEC for Countering Quantum Threat
• 저자: Syed W. Shah, Lei Pan, Dinh Duc Nha Nguyen, Robin Doss, Warren Armstrong, Praveen Gauravaram
• 기관: Deakin Cyber Research and Innovation Centre (호주), Cyber Security Cooperative Research Centre (호주), Quintessence Labs (캔버라), Tata Consultancy Services (브리즈번)
• 분류: cs.CR (암호학 및 보안)
• 발표 회의: C'25, 2025년 11월 (예비 버전은 ITNAC 2025에서 수락됨)
• 논문 링크: https://arxiv.org/abs/2411.07535

초록

DNSSEC은 DNS 보안 확장으로서 도메인 이름을 IP 주소로 정확하게 변환하는 데 필수적입니다. 디지털 서명은 이러한 신뢰할 수 있는 변환의 기초를 제공하지만, 양자 컴퓨터의 발전으로 인해 전통적인 디지털 서명이 취약해졌습니다. NIST는 최근 기존 컴퓨터에서 실행되면서 양자 컴퓨터 공격에 저항할 수 있는 후량자 디지털 서명을 선택했습니다. 이러한 후량자 디지털 서명이 여전히 초기 개발 단계에 있으므로, 철저한 보안 분석 전에 DNSSEC의 전량자 디지털 서명을 후량자 후보로 교체하는 것은 위험합니다. 본 연구는 DNSSEC에서 "이중 서명"을 채택하는 가능성을 탐구하며, 후량자 디지털 서명과 고전적 서명을 결합합니다. 이중 서명은 양자 위협과 미지의 비양자 공격에 대한 보호를 동시에 제공합니다. 그러나 두 서명의 포함은 DNSSEC 응답의 최대 허용 크기(1232B, 물리적 링크 MTU로 제한됨)와 충돌합니다. 이 문제를 해결하기 위해 본 논문은 이중 서명이 있는 DNSSEC 응답을 처리하기 위해 애플리케이션 계층 단편화 방법을 채택합니다. OQS-BIND에서 구현된 솔루션은 이중 서명과 애플리케이션 계층 단편화가 해석 프로세스 효율성에 미치는 영향이 미미하며, 양자 컴퓨터가 완전히 구현되기 전의 과도기에 적합함을 보여줍니다.

연구 배경 및 동기

1. 핵심 문제

DNSSEC은 디지털 서명을 통해 DNS 응답의 진정성과 무결성을 보장하지만, 양자 시대의 세 가지 어려움에 직면해 있습니다:

• 양자 위협: 암호 관련 양자 컴퓨터(CRQC)는 Shor 알고리즘을 통해 정수 분해 및 이산 로그에 기반한 전통적 서명을 다항식 시간 내에 깨뜨릴 수 있습니다
• 후량자 미성숙: NIST가 선택한 후량자 서명(FALCON, DILITHIUM, SPHINCS+)은 아직 충분한 암호학적 분석을 거치지 않았으며, 고전 컴퓨터가 이용할 수 있는 설계 결함이 있을 수 있습니다
• 과도기 위험: 현재부터 CRQC가 완전히 구현될 때까지의 "과도기" 동안, 전통적 또는 후량자 서명 중 하나에만 의존하는 것은 보안 위험이 있습니다

2. 문제의 중요성

• DNS는 인터넷 기반 시설의 핵심이며, 모든 보안 결함은 사용자를 악의적 서버로 유도할 수 있습니다
• ENISA 권장사항에 따르면, 과도기 동안 단순한 암호 알고리즘 교체는 전체 보안성을 저하시킬 수 있습니다
• 공개되지 않은 CRQC 돌파 또는 후량자 알고리즘 결함은 DNSSEC을 무효화할 수 있습니다

3. 기존 방법의 한계

• 전통적 서명만 사용: 미래의 양자 공격에 저항할 수 없습니다
• 후량자 서명만 사용: 미지의 고전 공격 벡터가 있을 수 있습니다
• 기존 단편화 방안: ARRF는 비표준 RR을 사용하여 중간 박스 호환성 문제를 야기할 수 있습니다; QBF는 이중 서명 시나리오를 고려하지 않았습니다
• TCP 폴백 메커니즘: 많은 네임 서버가 TCP 지원이 부족하며, TCP는 UDP만큼 가볍지 않습니다

4. 연구 동기

"이중 서명" 전략(분리된 메시지 인터페이스) 채택:

• 하나의 서명이 안전하면 전체 시스템이 안전하게 유지됩니다
• 과도기에 최대 보안 보장을 제공합니다
• 이중 서명으로 인한 메시지 크기 초과 문제(>1232B는 IP 계층 단편화 트리거)를 해결해야 합니다

핵심 기여

1. 완전한 이중 서명 DNSSEC 구현: Docker 기반 DNSSEC 테스트 플랫폼을 개발하여 상용급 BIND9 소프트웨어를 사용하고, 단일 UDP 응답 메시지에서 전량자 및 후량자 서명과 공개 키를 동시에 처리할 수 있습니다
2. 애플리케이션 계층 단편화 및 재조립 메커니즘: 이중 서명 시나리오를 위해 개선된 QBF 단편화 방안을 설계합니다:
   • z-bits를 사용하여 후량자 알고리즘 유형 식별
   • TTL 오프셋을 사용하여 RR 원본 순서 유지 및 압축 포인터 오류 방지
   • 모든 전량자(ECDSA256, RSASHA256)와 후량자(FALCON512, DILITHIUM2, SPHINCS+) 조합 지원
3. BIND9 소스 코드 수정: BIND9 해석기 구성 요소를 심층 연구하고 수정하여 응답을 인증된 것으로 표시하기 전에 두 서명을 검증할 수 있도록 합니다
4. 성능 평가: 실증 분석을 통해 이중 서명이 DNSSEC 해석 시간에 미치는 영향이 무시할 수 있음(<9% 증가)을 증명하여 과도기 적용 가능성을 확인합니다

방법 상세 설명

작업 정의

입력: DNS 쿼리(예: test.example.com의 A 레코드)
출력: 이중 서명 검증이 있는 IP 주소
제약 조건:

• UDP 메시지 크기 ≤1232B (IP 계층 단편화 방지)
• 전량자 및 후량자 서명 동시 검증
• 기존 DNS 기반 시설과의 호환성 유지

이중 서명 아키텍처 설계

1. 서명 생성 (네임 서버 측)

분리된 메시지 인터페이스 채택:

• BIND9 도구를 사용하여 두 쌍의 키(ZSK 및 KSK) 생성
• 동일한 RRSet에 대해 독립적으로 두 개의 서명 생성:
  • 전량자 서명 X (ECDSA256 또는 RSASHA256)
  • 후량자 서명 Y (FALCON512/DILITHIUM2/SPHINCS+)
• 두 RRSIG 및 DNSKEY 모두 서명 영역 파일에 저장

예시 (그림 13):
test0.socratescrc. 3600 IN RRSIG A 13 ... (ECDSA 서명)
test0.socratescrc. 3600 IN RRSIG A 249 ... (후량자 서명)

2. 검증 전략 (해석기 측)

BIND9 검증 로직 수정:

• 두 서명을 독립적으로 검증
• 두 서명이 모두 검증을 통과할 때만 응답 수락
• 양자 및 고전 공격에 대한 이중 보호 제공

애플리케이션 계층 단편화 메커니즘

핵심 과제

일반적인 이중 서명 응답 크기:

• A 레코드 응답: ~2500B (ECDSA+FALCON512 최소 조합)
• DNSKEY 응답: 4462B (RSASHA256+FALCON512)
• 1232B 임계값을 훨씬 초과

단편화 전략

기본 원칙:

• 전량자 RRSIG 및 DNSKEY는 항상 첫 번째 단편에 완전히 전송됨 (크기가 작음)
• 후량자 서명/키는 필요에 따라 단편화됨

A 레코드 응답 단편화 (그림 8a):

1. 첫 번째 단편에는: 헤더 + 질문 + 완전한 전량자 RRSIG/DNSKEY + 부분 후량자 RRSIG 포함
2. 해석기는 첫 번째 단편에서 총 단편 수 추론
3. 나머지 단편을 병렬로 요청 (형식: ?n?domain_name)

DNSKEY 응답 단편화 (그림 8b):

• 특정 조합(예: RSASHA256)으로 인해 첫 번째 단편이 후량자 데이터를 수용할 수 없음
• 혁신적 솔루션:

Z-bits 식별 방법:

RFC 1035의 z-bits(3비트) 활용:
- 후량자 알고리즘 유형 인코딩 (FALCON/DILITHIUM/SPHINCS+)
- 해석기는 z-bits 및 수신한 전량자 RR을 기반으로 총 크기 추론

TTL 오프셋 메커니즘:

문제: DNS 압축 포인터는 RR 순서에 따라 다름
해결: DNSKEY 응답의 TTL 필드에 오프셋 추가
작용: 재조립 시 RR 원본 위치 복원, "bad compression pointer" 오류 방지

워크플로우 (그림 10)

네임 서버 데몬:

1. DNS 응답을 가로채고 크기가 >1232B인지 확인
2. 필요한 단편 수 계산
3. z-bits(필요한 경우) 및 TTL 오프셋 설정
4. TC flag=1 설정, 첫 번째 단편 전송
5. 나머지 단편 캐시

해석기 데몬:

1. 첫 번째 단편 수신, TC flag 확인
2. z-bits 파싱하여 후량자 알고리즘 결정
3. 전량자 RR 정보를 활용하여 총 단편 수 추론
4. 모든 나머지 단편을 병렬로 요청 (?2?test.socrates, ?3?test.socrates...)
5. 모든 단편 수집 후 재조립:
   • TTL 오프셋을 사용하여 원본 RR 순서 복원
   • TC flag 및 기타 헤더 값 재설정
6. 완전한 메시지를 OQS-BIND 검증으로 전달

기술 혁신 포인트

1. 표준 RR 호환성: ARRF의 사용자 정의 RR과 달리, 표준 DNS 형식을 사용하여 중간 박스 호환성 보장
2. z-bits 재사용: 미충분하게 사용된 헤더 비트를 창의적으로 활용하여 DNSKEY 응답 정보 부족 문제 해결
3. TTL 오프셋 방안: DNS 압축 메커니즘과 단편화 재조립의 충돌을 해결하며, 이는 이중 서명 시나리오에 특유한 문제입니다
4. 병렬 단편 요청: 해석기가 모든 단편을 병렬로 획득하여 지연 최소화
5. 알고리즘 독립성: 모든 NIST 선택 후량자 알고리즘과 일반적인 전량자 알고리즘의 임의 조합 지원

실험 설정

테스트 플랫폼 아키텍처

기반 시설:

• Amazon EC2 t2.xlarge 인스턴스 (4코어 2.3GHz Intel Xeon, 16GB RAM)
• Docker 컨테이너화 배포 (Docker 25.0.3)
• 구성 요소: 클라이언트, 해석기, 루트 서버, 권한 있는 서버

소프트웨어 스택:

• OQS-BIND: BIND9의 후량자 강화 버전
  • OpenSSL 1.1.1
  • OQS liboqs 0.7.2
  • FALCON512, DILITHIUM2-AES, SPHINCS+-SHA256-128S 지원 (128비트 보안 수준)
• 수정된 QBF 데몬: 이중 서명 단편화/재조립 로직 구현

네트워크 토폴로지 (그림 11):

클라이언트 → 해석기 → 루트 서버 → 권한 있는 서버
        ↑                            ↓
        └────────────────────────────┘

데이터 세트 설정

• 테스트 도메인: 10개의 A 레코드 (test0.socratescrc - test9.socratescrc)
• 서명 조합: 6가지 이중 서명 구성
  • 전량자: ECDSA256, RSASHA256
  • 후량자: FALCON512, DILITHIUM2, SPHINCS+-SHA256-128S
• 신뢰 체인: DS 레코드 올바르게 구성, 완전한 신뢰 체인 구축

평가 지표

1. 해석 시간: 쿼리 전송부터 검증된 응답 수신까지의 종단 간 지연
2. 단편 수량: A 레코드 및 DNSKEY 응답에 필요한 단편 수
3. 성능 오버헤드: 이중 서명 대비 단일 후량자 서명의 시간 증가 백분율

네트워크 조건 시뮬레이션

Linux tc 도구를 사용하여 시뮬레이션:

• 대역폭: 50 Mbps
• 지연: 10 ms
• 실제 인터넷 조건 시뮬레이션

실험 방법

1. 각 도메인에 대해 해석기에 반복 쿼리
2. 각 쿼리의 해석 시간 기록
3. 10회 쿼리의 평균 해석 시간 계산
4. 이중 서명과 단일 후량자 서명의 성능 비교

실험 결과

단편 수량 분석 (표 1)

주요 발견:

• FALCON 및 DILITHIUM 조합은 단 1개의 단편만 증가
• SPHINCS+ 조합은 추가 단편을 증가시키지 않음 (데몬 최적화로 비필수 RR 제거)
• 단편 증가량은 제어 가능하며 지수적 증가를 야기하지 않음

평균 해석 시간

FALCON 조합 (표 2):

DILITHIUM 조합 (표 3):

SPHINCS+ 조합 (표 4):

주요 결과

1. 성능 오버헤드 수용 가능:
   • 모든 이중 서명 조합의 성능 오버헤드 <9%
   • TCP 폴백 오버헤드(일반적으로 >50%)보다 훨씬 낮음
2. 최적 구성:
   • FALCON+RSASHA: 204.5ms (가장 빠른 이중 서명)
   • DILITHIUM+RSASHA: 220.7ms
   • SPHINCS+ 단일 서명(245.6ms)보다 14-22% 빠름
3. RSA가 ECDSA보다 우수:
   • 모든 조합에서 RSA 검증 속도가 더 빠름
   • 예: DILITHIUM+RSA(220.7ms) vs DILITHIUM+ECDSA(225.6ms)
4. 서명 검증 성공률:
   • 모든 조합의 이중 서명이 올바르게 검증됨
   • 수정된 BIND9 해석기가 두 서명을 성공적으로 검증 (그림 14)

실험 발견

1. 격자 기반 알고리즘의 장점:
   • FALCON 및 DILITHIUM (격자 기반) 서명 크기가 작음
   • SPHINCS+ (해시 기반)보다 해석 시간이 현저히 짧음
2. SPHINCS+의 단점:
   • 서명 크기가 가장 큼 (A 레코드에 23개 단편)
   • NIST가 선택한 이유는 주로 격자 기반 알고리즘에 대한 과도한 의존성 회피
   • 이중 서명 시나리오에서는 최적 선택이 아님
3. 단편 재조립 신뢰성:
   • TTL 오프셋 메커니즘이 압축 포인터 문제를 효과적으로 해결
   • z-bits 방안이 알고리즘 정보를 정확하게 전달
   • 메시지 손실 또는 검증 실패 없음
4. 보안성 증가:
   • 이중 서명은 "fail-safe" 메커니즘 제공
   • 격자 기반 알고리즘이 돌파되더라도 RSA/ECDSA가 여전히 고전 보안성 제공
   • 양자 컴퓨터가 구현되더라도 후량자 알고리즘이 보호 제공

관련 연구

후량자 DNSSEC 연구

1. Müller et al. (2020):
   • NIST 3차 후보 알고리즘의 DNSSEC 요구사항 분석
   • 이중 서명 방안 미고려
2. Beernink (2022):
   • 대형 키의 대역 외 전달 방법 제안
   • 이중 서명의 메시지 크기 문제 미해결
3. Goertzen & Stebila (2022) - ARRF:
   • 요청 기반 애플리케이션 계층 단편화
   • RRFRAGS 의사 RR 도입 (비표준)
   • 메모리 고갈 공격 위험
4. Rawat & Jhanwar (2024) - QBF:
   • QName 기반 단편화, 표준 RR 사용
   • 병렬 단편 요청으로 효율성 향상
   • 이중 서명 미지원

본 논문의 기여 비교

암호학 조합기 연구

• ENISA (2022)는 과도기에 혼합 암호 시스템 사용 권장
• 본 논문은 DNSSEC에서 이중 서명을 구현하고 평가한 첫 번째 작업
• 분리된 메시지 인터페이스 채택 (더 쉬운 통합)

결론 및 토론

주요 결론

1. 기술적 가능성: 이중 서명 DNSSEC은 기존 기반 시설에서 완전히 가능하며 프로토콜 수준 수정이 필요하지 않습니다
2. 성능 수용 가능: 성능 오버헤드 <9%로 TCP 폴백보다 훨씬 낮으며 사용자 경험에 큰 영향을 주지 않습니다
3. 보안성 향상: 양자 및 고전 공격에 대한 이중 보호를 제공하여 과도기 배포에 적합합니다
4. 모범 사례: FALCON 또는 DILITHIUM과 RSA의 조합 사용을 권장하여 보안성과 성능의 균형을 맞춥니다

한계

1. 제한된 테스트 규모:
   • 단일 EC2 인스턴스에서만 테스트
   • 대규모 인터넷 배포 시나리오 미시뮬레이션
   • 실제 네트워크 트래픽 테스트 부족
2. 단순화된 네트워크 조건:
   • 50Mbps 대역폭과 10ms 지연만 시뮬레이션
   • 패킷 손실, 지터 등 복잡한 상황 미고려
   • 다양한 MTU 환경 미테스트
3. 데몬 오버헤드:
   • 단편화/재조립 로직이 독립 데몬에서 구현됨
   • 프로세스 간 통신이 추가 지연 야기 가능
   • BIND9 핵심에 직접 통합되지 않음
4. 중간 박스 호환성:
   • 방화벽, NAT 등 중간 박스 동작에 대한 전면 테스트 미실시
   • z-bits 재사용이 특정 구현에서 문제 야기 가능
5. 캐시 영향:
   • 단편화가 DNS 캐시 효율성에 미치는 영향 미분석
   • 여러 단편이 캐시 복잡도 증가 가능
6. 보안성 분석 부족:
   • 형식적 보안 증명 미실시
   • DoS 공격에 대한 견고성 미평가
   • 단편 재조립의 측면 채널 위험 미분석

향후 방향

1. BIND9 직접 통합:
   • 단편화 로직을 BIND9 핵심에 직접 통합
   • 해석 시간 추가 단축 예상
2. 대규모 배포 테스트:
   • 실제 DNS 기반 시설에서 파일럿 수행
   • 다양한 중간 박스와의 호환성 평가
3. 최적화된 알고리즘 선택:
   • 쿼리 유형에 따라 동적으로 알고리즘 조합 선택
   • 자적응형 단편화 전략 탐구
4. 표준화 추진:
   • IETF에 초안 제출
   • 이중 서명을 과도기 표준 실행으로 추진
5. 보안성 강화:
   • DoS 방어 메커니즘 추가
   • 단편 재조립의 타이밍 공격 방어 연구

심층 평가

장점

1. 정확한 문제 정위:
   • 과도기의 보안 딜레마를 명확히 식별
   • 이중 서명 전략이 ENISA 등 권위 있는 기관 권장과 일치
   • 실제 배포의 핵심 기술 장애물 해결
2. 완전한 기술 방안:
   • z-bits 및 TTL 오프셋은 창의적인 공학 솔루션
   • 성능, 호환성, 보안성을 균형 있게 고려
   • 구현 세부사항 충분 (소스 코드 수정, 데몬 설계)
3. 합리적인 실험 설계:
   • 상용급 BIND9 소프트웨어 사용으로 실용성 강화
   • 모든 주류 알고리즘 조합 테스트
   • 네트워크 조건 시뮬레이션이 실제 시나리오 반영
4. 강력한 결과 설득력:
   • 성능 데이터 명확 (<9% 오버헤드)
   • 모든 조합의 정확성 검증
   • 명확한 배포 권장사항 제공 (FALCON/DILITHIUM+RSA)
5. 높은 공학 가치:
   • 오픈 소스 OQS-BIND 기반으로 재현성 우수
   • Docker화 배포로 보급 용이
   • 실제 배포를 위한 실행 가능한 경로 제공

부족한 점

1. 이론적 분석 부재:
   • 이중 서명 방안의 형식적 보안 증명 부재
   • 서명 조합의 암호학적 강도 미논의
   • "하나의 서명 실패 시 다른 하나는 여전히 안전"이라는 가정의 엄격한 논증 부재
2. 제한된 평가 범위:
   • 테스트 도메인 10개로 샘플 크기 작음
   • 고부하, 고동시성 시나리오 미테스트
   • 장기 안정성 테스트 부재
3. 기존 방안과의 비교 부족:
   • TCP 폴백과의 직접적 성능 비교 미실시
   • EDNS(0) 패딩 등 대체 방안 대비 장점 미평가
   • 순수 FALCON, 순수 DILITHIUM 배포와의 보안성 비교 분석 부족
4. 실용성 고려 불완전:
   • 키 관리 복잡도 미논의 (두 쌍의 키)
   • 기존 DNSSEC 기반 시설 업그레이드 비용 미분석
   • 하위 호환성 테스트 부재 (구형 해석기)
5. 작성 개선 가능:
   • 일부 기술 세부사항 설명이 장황함 (섹션 2의 DNS 기초)
   • 도표가 더 명확할 수 있음 (그림 8, 그림 10이 복잡)
   • 알고리즘 의사 코드 부재

영향력

분야에 대한 기여:

• 개척적: DNSSEC 이중 서명을 구현하고 평가한 첫 번째 작업
• 시의성: NIST PQC 표준화 프로세스에 적시 대응
• 실용성: 즉시 배포 가능한 과도기 솔루션 제공

실용적 가치:

• 단기: DNS 운영자에게 과도기 보안 강화 방안 제공
• 중기: IETF 표준화를 위한 실증 데이터 제공
• 장기: 다른 프로토콜의 양자 보안 과도기를 위한 참고 자료

재현성:

• ✓ 오픈 소스 소프트웨어 기반 (OQS-BIND)
• ✓ 상세한 구현 설명
• ✗ 코드 공개 발표 미실시 (논문에서 GitHub 링크 미언급)
• ✓ Docker화 배포로 재현 난이도 감소

잠재적 영향:

• DNS 커뮤니티의 이중 서명 전략 채택 추진 가능
• 다른 애플리케이션 계층 프로토콜 (TLS, SSH)의 단편화 전략 참고 자료 제공
• 후량자 암호학의 실제 배포 가속화 지원

적용 시나리오

이상적 적용 시나리오:

1. 중요 기반 시설 DNS: 금융, 정부 등 보안 요구사항이 극히 높은 도메인
2. 과도기 배포: 2025-2030년 CRQC 위협이 임박하지만 후량자 알고리즘이 여전히 검증 필요한 시기
3. 고가치 목표: 국가 수준 공격자 위협에 쉽게 노출되는 조직

부적용 시나리오:

1. 자원 제약 환경: IoT 기기, 임베디드 시스템 (계산 및 저장 오버헤드)
2. 저지연 요구사항: 실시간 통신 시스템 (추가 8% 지연이 수용 불가)
3. 후량자 시대: 후량자 알고리즘이 완전히 성숙하면 이중 서명의 필요성 감소

배포 권장사항:

• 루트 서버 및 TLD 서버에 우선 배포
• FALCON+RSA 또는 DILITHIUM+RSA 조합 사용
• 기존 DNSSEC 기반 시설과 공존 (점진적 업그레이드)
• 성능 및 보안성 추적 모니터링 메커니즘 구축

참고 문헌 (주요 문헌)

1. Shor (1994): "Algorithms for quantum computation" - 양자 위협의 이론적 기초
2. NIST PQC 표준화: FALCON, DILITHIUM, SPHINCS+ 알고리즘 규격
3. RFC 4034: DNSSEC 리소스 레코드 규격
4. RFC 6891: EDNS(0) 확장 메커니즘
5. ENISA (2022): "Post-Quantum Cryptography Integration Study" - 이중 서명 전략의 정책 근거
6. Goertzen & Stebila (2022): ARRF 단편화 방안
7. Rawat & Jhanwar (2024): QBF 단편화 방안 (본 논문의 직접적 기초)

요약

본 논문은 DNSSEC 양자 보안 과도기의 독특한 과제에 대해 공학적으로 실행 가능한 이중 서명 솔루션을 제시합니다. 영리한 애플리케이션 계층 단편화 설계(z-bits 식별, TTL 오프셋)를 통해 이중 서명으로 인한 메시지 초과 문제를 성공적으로 해결합니다. 실험은 성능 오버헤드가 제어 가능함(<9%)을 증명하여 실제 배포에 적합함을 보여줍니다. 이는 "공학 주도 연구"의 전형적 사례로, 이론적 혁신은 제한적이지만 공학적 가치는 현저합니다. DNS 커뮤니티에 시의적절하고 실용적인 과도기 솔루션을 제공합니다. 논문의 주요 가치는 최초 구현 및 검증에 있으며, 이는 응용 암호학 분야에서도 동등하게 중요합니다. 저자들이 후속 작업에서 형식적 보안 분석과 대규모 배포 테스트를 보완하고 코드를 오픈 소스화하여 영향력을 높일 것을 권장합니다.