개요
이 문서는 기존의 ElGamal 비대칭 암호화 방식을 대체하거나 새로운 방식을 추가할 때 고려해야 할 중요한 사항들을 설명합니다.
이 문서는 정보 제공용 문서입니다.
동기
ElGamal은 오래되었고 느리며, 더 나은 대안들이 존재합니다. 그러나 새로운 알고리즘을 추가하거나 변경하기 전에 반드시 해결되어야 할 몇 가지 문제가 있습니다. 이 문서는 이러한 미해결 문제들을 강조합니다.
배경 조사
새로운 암호화 방식을 제안하려는 사람은 다음 문서들을 먼저 숙지해야 합니다:
- 제안 111 NTCP2
- 제안 123 LS2
- 제안 136 실험적 서명 타입
- 제안 137 선택적 서명 타입
- 위 각 제안에 대한 토론 스레드 (각 제안 문서 내에 링크됨)
- 2018년 제안 우선순위
- ECIES 제안
- 새로운 비대칭 암호화 개요
- 저수준 암호화 개요
비대칭 암호화 용도
복습 차원에서, 우리는 ElGamal을 다음 용도로 사용합니다:
터널 생성 메시지 (키는 RouterIdentity에 있음)
라우터 간 netdb 및 기타 I2NP 메시지 암호화 (키는 RouterIdentity에 있음)
클라이언트 종단 간 ElGamal+AES/SessionTag (키는 LeaseSet에 있음, Destination 키는 사용되지 않음)
NTCP 및 SSU를 위한 임시 DH
설계
ElGamal을 다른 방식으로 대체하려는 모든 제안은 다음 세부 정보를 반드시 제공해야 합니다.
명세
새로운 비대칭 암호화를 제안할 경우, 다음 사항들을 완전히 명시해야 합니다.
1. 일반 사항
제안서에서 다음 질문들에 답변하십시오. 아래 2)의 구체적인 내용과 별도의 제안서로 작성해야 할 수도 있으며, 기존 제안 111, 123, 136, 137 또는 기타 제안과 충돌할 수 있음을 유의하십시오.
- 위의 사례 1-4 중에서 어떤 용도에 새 암호화 방식을 사용할 것을 제안합니까?
- 또는 2) (라우터)에 사용할 경우, 공개 키는 RouterIdentity 또는 RouterInfo props 중 어디에 위치해야 합니까? 키 인증서에 암호화 타입을 사용할 의도가 있습니까? 완전히 명시하고, 선택한 방식에 대해 정당화하십시오.
- (클라이언트)에 사용할 경우, 공개 키를 Destination에 저장하고 키 인증서에 암호화 타입을 사용할 것인지 (ECIES 제안처럼), 아니면 LS2에 저장할 것인지 (제안 123처럼), 또는 다른 방식을 사용할 것인지 명시하십시오. 완전히 명시하고, 결정 사항을 정당화하십시오.
- 모든 용도에 대해, 지원 여부는 어떻게 공표될 것입니까? 3)에 사용할 경우 LS2에 포함됩니까, 아니면 다른 곳에 포함됩니까? 1) 및 2)에 사용할 경우 제안 136 및/또는 137과 유사한 방식입니까? 완전히 명시하고, 결정 사항을 정당화하십시오. 아마도 이를 위한 별도의 제안서가 필요할 것입니다.
- 이 방식이 어떻게 하위 호환 가능한지, 그리고 마이그레이션 계획을 완전히 명시하십시오.
- 귀하의 제안을 위해 전제 조건이 되는 구현되지 않은 제안은 무엇입니까?
2. 특정 암호화 타입
제안서에서 다음 질문들에 답변하십시오:
- 일반 암호화 정보, 구체적인 곡선/파라미터, 선택 사유를 완전히 정당화하십시오. 명세 및 기타 정보에 대한 링크를 제공하십시오.
- ElGamal 및 기타 대안과 비교한 속도 테스트 결과 (해당 시). 암호화, 복호화, 키 생성 속도를 포함하십시오.
- C++ 및 Java(OpenJDK, BouncyCastle, 타사 라이브러리 포함)에서의 라이브러리 가용성
타사 또는 비자바 라이브러리의 경우 링크와 라이선스를 제공하십시오. - 제안하는 암호화 타입 번호(실험용 범위 여부 포함)