참고
API 버전 0.9.51부터 구현되었습니다. 네트워크 배포 및 테스트 진행 중. 사소한 수정될 수 있습니다. 최종 사양은 I2NP 및 Tunnel-Creation-ECIES를 참조하십시오.
개요
요약
현재 암호화된 터널 빌드 요청 및 응답 레코드의 크기는 528입니다. 일반적인 가변 터널 빌드 및 가변 터널 빌드 응답 메시지의 총 크기는 2113바이트입니다. 이 메시지는 역방향 경로를 위해 세 개의 1KB 터널 메시지로 나뉩니다.
ECIES-X25519 라우터용 528바이트 레코드 형식 변경은 Prop152 및 Tunnel-Creation-ECIES에 지정되어 있습니다. 터널에 있는 ElGamal 및 ECIES-X25519 라우터가 혼합된 경우 레코드 크기는 528바이트로 유지되어야 합니다. 그러나 터널의 모든 라우터가 ECIES-X25519인 경우 ElGamal보다 ECIES-X25519 암호화의 오버헤드가 훨씬 적기 때문에 새롭고 작은 빌드 레코드가 가능합니다.
작은 메시지는 대역폭을 절약할 수 있습니다. 또한 메시지가 단일 터널 메시지에 맞을 수 있다면 역방향 경로는 세 배 더 효율적일 수 있습니다.
이 제안서는 새로운 요청 및 응답 레코드와 새로운 빌드 요청 및 빌드 응답 메시지를 정의합니다.
터널 생성자와 생성된 터널의 모든 홉은 ECIES-X25519이거나 최소 버전 0.9.51이어야 합니다. 이 제안서는 네트워크의 라우터 대다수가 ECIES-X25519가 될 때까지는 유용하지 않습니다. 2021년 말까지 이를 기대하고 있습니다.
목표
추가 목표는 Prop152 및 Prop156를 참조하십시오.
- 더 작은 레코드 및 메시지
- Prop152 및 Tunnel-Creation-ECIES에서와 같이 향후 옵션에 대한 충분한 공간 유지
- 역방향 경로에 하나의 터널 메시지에 맞추기
- ECIES 홉만 지원
- Prop152 및 Tunnel-Creation-ECIES에서 구현된 개선 사항 유지
- 현재 네트워크와의 호환성 최대화
- OBEP에서 인바운드 빌드 메시지 숨기기
- IBGW에서 아웃바운드 빌드 응답 메시지 숨기기
- 전체 네트워크에 대한 “플래그 데이” 업그레이드 요구하지 않음
- 위험을 최소화하기 위한 점진적 배포
- 기존 암호화 프리미티브 재사용
비목표
추가 비목표는 Prop156를 참조하십시오.
- 혼합 ElGamal/ECIES 터널에 대한 요구 없음
- 레이어 암호화 변경사항 없음, 이는 Prop153를 참조하십시오.
- 암호화 작업의 속도 향상이 없음. ChaCha20과 AES가 유사하다고 가정, 데이터 크기가 작은 경우에는 특히 AESNI와 함께라도.
설계
레코드
계산은 부록을 참조하십시오.
암호화된 요청 및 응답 레코드는 현재 528바이트에서 218바이트가 됩니다.
일반 텍스트 요청 레코드는 222바이트의 ElGamal 레코드와 비교하여 154바이트가 될 것이며, Prop152 및 Tunnel-Creation-ECIES에서 정의된 464바이트의 ECIES 레코드에서도 마찬가지입니다.
일반 텍스트 응답 레코드는 ElGamal 레코드의 496바이트와 Prop152 및 Tunnel-Creation-ECIES에서 정의된 512바이트의 ECIES 레코드에 비해 202바이트가 될 것입니다.
응답 암호화는 ChaCha20 (ChaCha20/Poly1305 아님)입니다, 따라서 일반 텍스트 레코드는 16바이트의 배수가 될 필요가 없습니다.
HKDF를 사용하여 레이어와 응답 키를 생성하여 요청에 명시적으로 포함할 필요가 없습니다.
터널 빌드 메시지
제안된 두 메시지는 기존의 가변 메시지와 마찬가지로 “가변"이며, 레코드 번호 필드가 1바이트입니다.
ShortTunnelBuild: 유형 25
평균 길이 (4개의 레코드 포함): 873바이트
인바운드 터널 빌드에 사용될 때, 원본에 의해 가상 암호화되는 것이 추천되지만 필수는 아닙니다, 인바운드 게이트웨이에 목표가 설정됩니다 (전달 지침 ROUTER), 인바운드 빌드 메시지를 OBEP로부터 숨기기 위해. IBGW는 메시지를 해독하고, 응답을 올바른 슬롯에 넣고, ShortTunnelBuildMessage를 다음 홉으로 보냅니다.
기록 길이는 가상 암호화된 STBM이 단일 터널 메시지에 맞을 수 있도록 선택됩니다. 아래 부록을 참조하십시오.
OutboundTunnelBuildReply: 유형 26
새로운 OutboundTunnelBuildReply 메시지를 정의합니다. 이는 아웃바운드 터널 빌드에만 사용됩니다. IBGW에서 아웃바운드 빌드 응답 메시지를 숨기기 위한 목적입니다. OBEP에 의해 원본에 암호화되며, (전달 지침 TUNNEL). OBEP는 터널 빌드 메시지를 해독하고, OutboundTunnelBuildReply 메시지를 구성하여 응답을 명확한 필드에 넣습니다. 다른 레코드는 다른 슬롯에 들어갑니다. 그 다음 원본과 유도된 대칭 키를 사용하여 메시지를 암호화합니다.
Notes
OTBRM 및 STBM을 암호화함으로써, 페어 터널의 IBGW 및 OBEP에서의 호환성 문제를 회피할 수 있습니다.
메시지 흐름
STBM: 짧은 터널 빌드 메시지 (유형 25)
OTBRM: 아웃바운드 터널 빌드 응답 메시지 (유형 26)
아웃바운드 빌드 A-B-C
기존 인바운드 D-E-F를 통해 응답
새 터널
STBM STBM STBM
생성자 ------> A ------> B ------> C ---\
OBEP \
| 암호화 래핑
| OTBRM
| (TUNNEL 전달)
| OBEP에서
| 생성자로
기존 터널 /
생성자 <-------F---------E-------- D <--/
IBGW
인바운드 빌드 D-E-F
기존 아웃바운드 A-B-C를 통해 전송
기존 터널
생성자 ------> A ------> B ------> C ---\
OBEP \
| 암호화 래핑 (선택)
| STBM
| (ROUTER 전달)
| 생성자로부터
새 터널 | IBGW로
STBM STBM STBM /
생성자 <------ F <------ E <------ D <--/
IBGW
레코드 암호화
요청 및 응답 레코드 암호화: Prop152 및 Tunnel-Creation-ECIES에 정의된 대로.
다른 슬롯의 응답 레코드 암호화: ChaCha20.
레이어 암호화
현재 이 사양을 통해 생성된 터널에 대한 레이어 암호화 변경 계획은 없습니다; 현재 모든 터널에 사용되는 AES로 유지될 것입니다.
레이어 암호화를 ChaCha20으로 변경하는 것은 추가 연구가 필요한 주제입니다.
새 터널 데이터 메시지
현재 이 사양을 통해 생성된 터널에 사용되는 1KB 터널 데이터 메시지를 변경할 계획은 없습니다.
이 터널에서 사용하기 위해 이 제안과 동시에 새 I2NP 메시지를 소개하는 것이 유용할 수 있습니다. 이렇게 하면 큰 메시지의 오버헤드가 줄어듭니다. 이것은 추가 연구가 필요한 주제입니다.
사양
짧은 요청 레코드
짧은 요청 레코드 암호화되지 않음
이것은 ECIES-X25519 라우터를 위한 터널 BuildRequestRecord의 제안된 사양입니다. Tunnel-Creation-ECIES에서의 변화 요약:
- 암호화되지 않은 길이를 464에서 154로 변경
- 암호화된 길이를 528에서 218로 변경
- [split()] 및 KDF에서 생성된 레이어 및 응답 키 및 IV 제거
요청 레코드에는 아무런 ChaCha 응답 키가 포함되어 있지 않습니다. 이 키는 KDF에서 유도됩니다.
모든 필드는 빅 엔디안입니다.
암호화되지 않은 크기: 154바이트.
bytes 0-3: 메시지 수신을 위한 터널 ID, 0이 아님
bytes 4-7: 다음 터널 ID, 0이 아님
bytes 8-39: 다음 라우터 식별자 해시
byte 40: 플래그
bytes 41-42: 추가 플래그, 미사용, 호환성을 위해 0으로 설정
byte 43: 레이어 암호화 타입
bytes 44-47: 요청 시간 (에포크 이후 분 단위, 내림 반올림)
bytes 48-51: 요청 만료 (생성 이후 초 단위)
bytes 52-55: 다음 메시지 ID
bytes 56-x: 터널 빌드 옵션 (매핑)
bytes x-x: 플래그 또는 옵션에 의해 암시된 기타 데이터
bytes x-153: 임의 패딩 (아래 참조)
플래그 필드는 Tunnel-Creation에 정의된 것과 동일하며 다음을 포함합니다::
비트 순서: 76543210 (비트 7은 MSB) 비트 7: 설정된 경우, 누구로부터 메시지를 허용 비트 6: 설정된 경우, 누구에게나 메시지를 허용하며, 지정된 다음 홉으로 터널 빌드 응답 메시지를 보냅니다. 비트 5-0: 정의되지 않음, 미래의 옵션과의 호환성을 위해 0으로 설정 필요
비트 7은 홉이 인바운드 게이트웨이(IBGW)가 될 것임을 나타냅니다. 비트 6은 홉이 아웃바운드 엔드포인트(OBEP)가 될 것임을 나타냅니다. 둘 다 동시에 설정할 수 없습니다.
레이어 암호화 타입: AES가 현재 터널에서 사용됨; 미래의 위해 1 (ChaCha?)
요청 만료는 향후 가변 터널 기간을 위한 것입니다. 현재로서는 지원되는 값은 600 (10분) 뿐입니다.
생성자 임시 공개 키는 ECIES 키이며, 빅 엔디안입니다. 이는 IBGW 레이어와 응답 키 및 IV의 KDF를 위해 사용됩니다. 이것은 인바운드 터널 빌드 메시지의 일반 텍스트 레코드에만 포함됩니다. 빌드 레코드의 레이어에 대한 DH가 없기 때문에 필요합니다.
터널 빌드 옵션은 Common에 정의된 매핑 구조입니다. 이는 향후 사용을 위한 것입니다. 현재 정의된 옵션은 없습니다. 매핑 구조가 비어 있으면, 이는 0x00 0x00의 두 바이트입니다. 매핑의 최대 크기(길이 필드 포함)는 98바이트이며, 매핑 길이 필드의 최대 값은 96입니다.
짧은 요청 레코드 암호화
모든 필드는 빅 엔디안이며, 임시 공개 키는 리틀 엔디안입니다.
암호화된 크기: 218바이트
bytes 0-15: 홉의 잘린 식별자 해시
bytes 16-47: 송신자의 임시 X25519 공개 키
bytes 48-201: ChaCha20로 암호화된 ShortBuildRequestRecord
bytes 202-217: Poly1305 MAC
짧은 응답 레코드
짧은 응답 레코드 암호화되지 않음
이것은 ECIES-X25519 라우터를 위한 터널 ShortBuildReplyRecord의 제안된 사양입니다. Tunnel-Creation-ECIES에서의 변화 요약:
- 암호화되지 않은 길이를 512에서 202로 변경
- 암호화된 길이를 528에서 218로 변경
ECIES 응답은 ChaCha20/Poly1305로 암호화됩니다.
모든 필드는 빅 엔디안입니다.
암호화되지 않은 크기: 202바이트.
bytes 0-x: Tunnel Build Reply Options (매핑)
bytes x-x: 옵션에 의해 암시된 기타 데이터
bytes x-200: 임의 패딩 (아래 참조)
byte 201: 응답 바이트
터널 빌드 응답 옵션은 Common에 정의된 매핑 구조입니다. 이는 향후 사용을 위한 것입니다. 현재 정의된 옵션은 없습니다. 매핑 구조가 비어 있으면, 이는 0x00 0x00의 두 바이트입니다. 매핑의 최대 크기(길이 필드 포함)는 201바이트이며, 매핑 길이 필드의 최대 값은 199입니다.
응답 바이트는 다음과 같은 값 중 하나입니다 Tunnel-Creation에서 정의된 값을 사용하여 지문을 피하기 위해:
- 0x00 (수용)
- 30 (TUNNEL_REJECT_BANDWIDTH)
짧은 응답 레코드 암호화
암호화된 크기: 218바이트
bytes 0-201: ChaCha20로 암호화된 ShortBuildReplyRecord
bytes 202-217: Poly1305 MAC
KDF
아래 KDF 섹션을 참조하십시오.
ShortTunnelBuild
I2NP 유형 25
이 메시지는 가운데 홉, OBEP, IBEP(생성자)에게 전송됩니다. IBGW로는 전송될 수 없습니다 (가상 래핑된 인바운드 터널 빌드를 대신 사용하십시오). OBEP에서 받은 경우, 이는 OutboundTunnelBuildReply로 변환되어 가상 래핑되며 원본으로 전송됩니다.
+----+----+----+----+----+----+----+----+
| num| ShortBuildRequestRecords...
+----+----+----+----+----+----+----+----+
num ::
1바이트 `정수`
유효한 값: 1-8
기록 크기: 218바이트
전체 크기: 1+$num*218
노트
- 일반적인 레코드 수는 4로, 전체 크기는 873입니다.
OutboundTunnelBuildReply
I2NP 유형 26
이 메시지는 OBEP가 IBEP(생성자)로만 전송합니다. 기존 인바운드 터널을 통해서만 가능합니다. 다른 홉으로는 전송될 수 없습니다. 항상 가상 암호화됩니다.
+----+----+----+----+----+----+----+----+
| num| |
+----+ +
| ShortBuildReplyRecords... |
+----+----+----+----+----+----+----+----+
num ::
총 레코드 수,
1바이트 `정수`
유효한 값: 1-8
ShortBuildReplyRecords ::
암호화된 기록
길이: num * 218
암호화된 기록 크기: 218바이트
전체 크기: 1+$num*218
노트
- 일반적인 레코드 수는 4로, 전체 크기는 873입니다.
- 이 메시지는 가상 암호화해야 합니다.
KDF
터널 빌드 레코드 암호화/복호화 후 노이즈 상태에서 ck를 사용하여 다음 키를 유도합니다: 응답 키, AES 레이어 키, AES IV 키 및 OBEP용 가상 응답 키/태그.
응답 키: 긴 레코드와 달리 우리는 응답 키에 ck의 왼쪽 부분을 사용할 수 없습니다, 왜냐하면 이것은 마지막이 아니며 나중에 사용될 것입니다. 응답 키는 다음 기록을 암호화하는 데 사용됩니다. AEAD/Chaha20/Poly1305 및 Chacha20에 사용할 수 있는 키는 동일하며, nonce는 메시지의 기록 위치를 0부터 시작합니다.
keydata = HKDF(ck, ZEROLEN, "SMTunnelReplyKey", 64)
replyKey = keydata[32:63]
ck = keydata[0:31]
레이어 키:
현재로서는 레이어 키는 항상 AES이지만, 같은 KDF는 Chacha20에서 사용할 수 있습니다.
keydata = HKDF(ck, ZEROLEN, "SMTunnelLayerKey", 64)
layerKey = keydata[32:63]
OBEP 기록을 위한 IV 키:
ivKey = keydata[0:31] (마지막이기 때문에)
OBEP 기록을 위한 IV 키:
ck = keydata[0:31]
keydata = HKDF(ck, ZEROLEN, "TunnelLayerIVKey", 64)
ivKey = keydata[32:63]
ck = keydata[0:31]
OBEP 가상 응답 키/태그:
keydata = HKDF(ck, ZEROLEN, "RGarlicKeyAndTag", 64)
replyKey = keydata[32:63]
replyTag = keydata[0:7]
정당화
이 디자인은 기존 암호화 프리미티브, 프로토콜 및 코드를 최대한 재사용합니다.
이 디자인은 위험을 최소화합니다.
작은 레코드에서 ChaCha20은 AES보다 약간 빨라집니다 (자바 테스트에서).
ChaCha20은 데이터 크기가 16의 배수가 될 필요가 없게 합니다.
구현 노트
- 기존 가변 터널 빌드 메시지와 마찬가지로, 4개 레코드보다 작은 메시지의 사용은 권장되지 않습니다. 일반적인 기본값은 3 홉입니다. 인바운드 터널은 원본이 마지막 홉임을 알지 못하도록 원본을 위한 추가 레코드를 가지고 생성되어야 합니다. 가운데 홉이 터널이 인바운드인지 아웃바운드인지 모르게 하기 위해, 아웃바운드 터널도 4개 레코드와 함께 생성되어야 합니다.
문제
마이그레이션
구현, 테스트 및 배포는 여러 릴리스와 약 1년이 소요됩니다. 단계는 다음과 같습니다. 각 단계의 특정 릴리스에 대한 할당은 아직 미정이며 개발 속도에 따라 다릅니다.
각 I2P 구현에 대한 구현과 마이그레이션의 세부사항은 다를 수 있습니다.
터널 생성자는 생성된 터널의 모든 홉이 ECIES-X25519이어야 하며 최소 버전 TBD 이상이어야 합니다. 터널 생성자는 ECIES-X25519일 필요가 없습니다; ElGamal일 수 있습니다. 그러나 생성자가 ElGamal일 경우 이는 가장 가까운 홉에 생성자인 것을 알립니다. 따라서 실제로 이러한 터널은 ECIES 라우터에 의해서만 생성되어야 합니다.
쌍의 OBEP 또는 IBGW가 ECIES인지 또는 특정 버전인지 여부는 필요하지 않아야 합니다. 새로운 메시지는 가상 암호화되어 페어 터널의 OBEP 또는 IBGW에서 볼 수 없습니다.
1단계: 구현, 기본 설정으로 활성화되지 않음
2단계 (다음 릴리스): 기본 설정으로 활성화
하위 호환성 문제는 없습니다. 새로운 메시지는 이들을 지원하는 라우터에게만 보내질 수 있습니다.
부록
암호화되지 않은 인바운드 STBM의 경우 가상 오버헤드 없이, ITBM을 사용하지 않는 경우:
현재 4 슬롯 크기: 4 * 528 + 오버헤드 = 3 터널 메시지
4 슬롯 빌드 메시지가 단일 터널 메시지에 맞도록 하기 위해, ECIES 전용:
1024
- 21 조각 헤더
----
1003
- 35 비조각 ROUTER 전달 지침
----
968
- 16 I2NP 헤더
----
952
- 1 슬롯 수
----
951
/ 4 슬롯
----
237 새로운 암호화된 빌드 레코드 크기 (현재 528 vs)
- 16 잘린 해시
- 32 임시 키
- 16 MAC
----
173 일반 텍스트 빌드 레코드 최대 (현재 222 vs)
암호화된 ‘N’ 노이즈 패턴 오버헤드로 인바운드 STBM의 경우, ITBM을 사용하지 않는 경우:
현재 4 슬롯 크기: 4 * 528 + 오버헤드 = 3 터널 메시지
4 슬롯 암호화된 빌드 메시지가 단일 터널 메시지에 맞도록 하기 위해, ECIES 전용:
1024
- 21 조각 헤더
----
1003
- 35 비조각 ROUTER 전달 지침
----
968
- 16 I2NP 헤더
- 4 길이
----
948
- 32 바이트 임시 키
----
916
- 7 바이트 날짜 시간 블록
----
909
- 3 바이트 암호화 블록 오버헤드
----
906
- 9 바이트 I2NP 헤더
----
897
- 1 바이트 가상 로컬 전달 지침
----
896
- 16 바이트 Poly1305 MAC
----
880
- 1 슬롯 수
----
879
/ 4 슬롯
----
219 새로운 암호화된 빌드 레코드 크기 (현재 528 vs)
- 16 잘린 해시
- 32 임시 키
- 16 MAC
----
155 일반 텍스트 빌드 레코드 최대 (현재 222 vs)
노트:
현재 빌드 레코드 평문 크기 사용되지 않은 패딩 전: 193
전체 라우터 해시 및 HKDF 생성 키/IV 제거는 향후 옵션에 충분한 공간을 제공합니다. 모든 것이 HKDF일 경우, 필요한 평문 공간은 약 58바이트 (옵션 없음)입니다.
가상 래핑된 OTBRM은 가상 래핑된 STBM보다 약간 작을 것입니다, 왜냐하면 전달 지침이 로컬이며, DATETIME 블록이 포함되지 않으며, 전체 ‘N’ 메시지에 대한 32바이트 임시 키 대신 8바이트 태그를 사용하기 때문입니다.