새로운 netDB 항목 | Proposals | I2P - 보이지 않는 인터넷 프로젝트

상태

이 제안의 일부는 완료되어 0.9.38 및 0.9.39 버전에 구현되었습니다.
공통 구조, I2CP, I2NP 및 기타 사양은
현재 지원되는 변경 사항을 반영하도록 업데이트되었습니다.

완료된 부분도 여전히 사소한 수정이 있을 수 있습니다.
이 제안의 다른 부분은 여전히 개발 중이며
상당한 수정이 있을 수 있습니다.

서비스 조회 (유형 9 및 11)는 우선순위가 낮으며
일정이 정해지지 않았으며, 별도의 제안으로 분리될 수 있습니다.

개요

이 문서는 다음 4개의 제안을 업데이트하고 통합한 것입니다:

110 LS2
120 대규모 멀티호밍을 위한 메타 LS2
121 암호화된 LS2
122 인증되지 않은 서비스 조회 (애니캐스팅)

이 제안들은 대부분 독립적이지만, 일관성을 위해
여러 제안에서 공통 형식을 정의하고 사용합니다.

다음 제안들은 다소 관련이 있습니다:

140 보이지 않는 멀티호밍 (이 제안과 불호환)
142 새로운 대칭 암호를 위한 새로운 암호 템플릿
144 ECIES-X25519-AEAD-Ratchet
145 ECIES-P256
146 Red25519
148 EdDSA-BLAKE2b-Ed25519
149 암호화된 LS2를 위한 B32
150 마늘 농장 프로토콜
151 ECDSA 블라인딩

제안

이 제안은 5개의 새로운 DatabaseEntry 유형과
네트워크 데이터베이스에 저장하고 검색하는 절차,
그리고 서명하고 그 서명을 검증하는 방법을 정의합니다.

목표

하위 호환성 유지
기존 스타일의 멀티호밍에서도 LS2 사용 가능
지원을 위해 새로운 암호나 원시 요소가 필요하지 않음
암호와 서명의 분리 유지; 현재 및 미래 모든 버전 지원
선택적 오프라인 서명 키 지원
지문 추적을 줄이기 위해 타임스탬프 정확도 감소
목적지에 대한 새로운 암호화 지원
대규모 멀티호밍 지원
기존 암호화된 LS의 여러 문제 해결
플러드필이 볼 수 있는 가시성 감소를 위한 선택적 블라인딩
암호화된 LS는 단일 키와 여러 철회 가능한 키 모두 지원
아웃프록시, 애플리케이션 DHT 부트스트랩 등에서 더 쉬운 조회를 위한 서비스 조회
비트토런트 등 32바이트 이진 목적지 해시에 의존하는 기능을 깨뜨리지 않음
라우터정보에서처럼 속성을 통해 leaseset의 유연성 추가
내용이 암호화되어 있어도 작동하도록 게시 타임스탬프와 가변 만료를 헤더에 포함 (가장 이른 임대에서 타임스탬프를 유도하지 않음)
모든 새로운 유형은 기존 leaseset과 동일한 DHT 공간 및 위치에 존재하여, 사용자가 기존 LS에서 LS2로 마이그레이션하거나 LS2, 메타, 암호화된 LS2 간 전환 시 목적지나 해시를 변경하지 않아도 됨
기존 목적지를 오프라인 키로 전환하거나 다시 온라인 키로 전환할 때 목적지나 해시를 변경하지 않아도 됨

비목표 / 범위 외

새로운 DHT 회전 알고리즘 또는 공유 난수 생성
새로운 암호화 유형과 그 유형을 사용하는 종단 간 암호화 방식은 별도의 제안에 포함됨. 여기에서는 새로운 암호를 지정하거나 논의하지 않음
RI 또는 터널 생성을 위한 새로운 암호화. 별도의 제안에 포함됨
I2NP DLM / DSM / DSRM 메시지의 암호화, 전송, 수신 방법. 변경 없음
메타를 생성하고 지원하는 방법, 백엔드 라우터 간 통신, 관리, 장애 조치 및 조정 포함. I2CP, i2pcontrol 또는 새로운 프로토콜에 지원이 추가될 수 있음. 표준화 여부는 미정
장기간 만료되는 터널을 실제로 구현하고 관리하거나 기존 터널을 취소하는 방법. 매우 어렵고, 이를 없이는 합리적인 점진적 종료가 불가능함
위협 모델 변경
오프라인 저장 형식 또는 데이터 저장/검색/공유 방법
구현 세부 사항은 여기서 논의하지 않으며 각 프로젝트에 맡김

정당성

LS2는 암호화 유형 변경 및 향후 프로토콜 변경을 위한 필드를 추가합니다.

암호화된 LS2는 전체 임대 집합을 비대칭 암호화하여 기존 암호화된 LS의 여러 보안 문제를 해결합니다.

메타 LS2는 유연하고 효율적이며 효과적인 대규모 멀티호밍을 제공합니다.

서비스 레코드 및 서비스 목록은 이름 조회 및 DHT 부트스트래핑과 같은 애니캐스트 서비스를 제공합니다.

NetDB 데이터 유형

유형 번호는 I2NP 데이터베이스 조회/저장 메시지에서 사용됩니다.

종단 간(end-to-end) 열은 마늘 메시지에서 목적지로 쿼리/응답이 전송되는지를 나타냅니다.

기존 유형:

NetDB 데이터	조회 유형	저장 유형
any	0	any
LS	1	1
RI	2	0
탐색용	3	DSRM

새로운 유형:

NetDB 데이터	조회 유형	저장 유형	표준 LS2 헤더?	종단 간 전송?
LS2	1	3	예	예
암호화된 LS2	1	5	아니오	아니오
메타 LS2	1	7	예	아니오
서비스 레코드	n/a	9	예	아니오
서비스 목록	4	11	아니오	아니오

참고 사항

조회 유형은 현재 데이터베이스 조회 메시지의 비트 3-2에 사용됩니다. 추가 유형은 비트 4를 사용해야 합니다.
이전 라우터는 데이터베이스 저장 메시지 유형 필드의 상위 비트를 무시하므로 모든 저장 유형은 홀수입니다. RI 압축 형식보다 LS로 파싱이 실패하는 것이 더 낫습니다.
서명이 적용되는 데이터에서 유형이 명시적, 암시적, 아니면 둘 다 아닌지 여부?

조회/저장 절차

유형 3, 5, 7은 표준 leaseset 조회(유형 1)에 대한 응답으로 반환될 수 있습니다.
유형 9는 조회에 대한 응답으로 절대 반환되지 않습니다.
유형 11은 새로운 서비스 조회 유형(유형 11)에 대한 응답으로 반환됩니다.

클라이언트 간 마늘 메시지에는 유형 3만 전송될 수 있습니다.

형식

유형 3, 7, 9는 모두 다음 공통 형식을 사용합니다::

표준 LS2 헤더

아래에 정의됨

유형별 부분

아래 각 부분에 정의됨

표준 LS2 서명:

서명 키의 서명 유형에 따라 암시되는 길이

유형 5(암호화된)는 목적지로 시작하지 않으며 다른 형식을 가집니다. 아래 참조.

유형 11(서비스 목록)은 여러 서비스 레코드의 집합이며 다른 형식을 가집니다. 아래 참조.

개인정보/보안 고려사항

TBD

표준 LS2 헤더

유형 3, 7, 9는 아래에 명시된 표준 LS2 헤더를 사용합니다:

형식

표준 LS2 헤더:
  - 유형 (1바이트)
    실제로 헤더에 포함되지 않지만, 서명이 적용되는 데이터의 일부임.
    데이터베이스 저장 메시지의 필드에서 가져옴.
  - 목적지 (387+ 바이트)
  - 게시 타임스탬프 (4바이트, 빅엔디언, 에포크 이후 초, 2106년에 오버플로)
  - 만료 (2바이트, 빅엔디언) (게시 타임스탬프 이후 초 단위 오프셋, 최대 18.2시간)
  - 플래그 (2바이트)
    비트 순서: 15 14 ... 3 2 1 0
    비트 0: 0이면 오프라인 키 없음; 1이면 오프라인 키 있음
    비트 1: 0이면 표준 게시된 leaseset.
           1이면 게시되지 않은 leaseset. 홍수 전파, 게시 또는 쿼리에 대한 응답으로 전송해서는 안 됨. 이 leaseset이 만료되면 비트 2가 설정되지 않는 한 netdb에서 새 것을 조회하지 않음.
    비트 2: 0이면 표준 게시된 leaseset.
           1이면 이 암호화되지 않은 leaseset은 게시 시 블라인딩되고 암호화됨. 이 leaseset이 만료되면 netdb에서 블라인딩된 위치를 조회하여 새 것을 가져옴.
           이 비트가 1로 설정되면 비트 1도 1로 설정해야 함.
           0.9.42 릴리스부터.
    비트 3-15: 향후 사용과의 호환성을 위해 0으로 설정
  - 플래그가 오프라인 키를 나타내면, 오프라인 서명 섹션:
    만료 타임스탬프 (4바이트, 빅엔디언, 에포크 이후 초, 2106년에 오버플로)
    일시적 서명 유형 (2바이트, 빅엔디언)
    일시적 서명 공개 키 (서명 유형에 따라 암시되는 길이)
    목적지 공개 키로 서명한 만료 타임스탬프, 일시적 서명 유형 및 공개 키의 서명,
    목적지 공개 키 서명 유형에 따라 암시되는 길이.
    이 섹션은 오프라인에서 생성할 수 있으며, 생성해야 함.

정당성

게시되지 않음/게시됨: 종단 간 데이터베이스 저장을 보낼 때, 보내는 라우터가 이 leaseset을 다른 사람에게 보내지 않도록 표시하려 할 수 있음. 현재는 이 상태를 유지하기 위해 휴리스틱을 사용하고 있음.
게시됨: leaseset의 ‘버전’을 결정하기 위해 필요한 복잡한 논리를 대체함. 현재 버전은 가장 늦게 만료되는 임대의 만료 시간이며, 게시 라우터는 오래된 임대만 제거하는 leaseset을 게시할 때 최소 1ms 이상 만료 시간을 증가시켜야 함.
만료: netdb 항목의 만료를 마지막으로 만료되는 leaseset보다 일찍 설정할 수 있음. LS2에서는 leaseset이 11분 최대 만료로 유지될 것으로 예상되므로 유용하지 않을 수 있지만, 다른 새로운 유형(아래 메타 LS 및 서비스 레코드 참조)에서는 필요함.
오프라인 키는 초기/필수 구현 복잡성을 줄이기 위해 선택 사항임.

문제점

타임스탬프 정확도를 더 줄일 수 있음 (10분?) 하지만 버전 번호를 추가해야 함. 이는 멀티호밍을 깰 수 있음. 순서 보존 암호화가 없으면 타임스탬프 없이도 할 수 없음.
대안: 3바이트 타임스탬프 (에포크 / 10분), 1바이트 버전, 2바이트 만료
유형이 데이터/서명에서 명시적 또는 암시적인가? 서명을 위한 “도메인” 상수?

참고 사항

라우터는 1초에 한 번 이상 LS를 게시해서는 안 됩니다.
만약 그렇게 한다면, 이전에 게시된 LS보다 게시 타임스탬프를 인위적으로 1초 증가시켜야 합니다.
라우터 구현은 검증을 매번 하지 않도록 일시적 키와 서명을 캐시할 수 있습니다. 특히 플러드필과 장기간 연결의 양 끝에 있는 라우터가 이로부터 이득을 볼 수 있습니다.
오프라인 키와 서명은 장기간 존재하는 목적지(즉, 서버)에만 적합하며, 클라이언트에는 적합하지 않습니다.

새로운 DatabaseEntry 유형

LeaseSet 2

기존 LeaseSet과의 변경 사항:

게시 타임스탬프, 만료 타임스탬프, 플래그 및 속성 추가
암호화 유형 추가
철회 키 제거

조회: 표준 LS 플래그 (1) 저장: 표준 LS2 유형 (3) 저장 위치: 목적지의 해시 이 해시는 LS1과 동일하게 일일 “라우팅 키"를 생성하는 데 사용됨 일반적인 만료: 10분, 일반적인 LS와 동일 게시자: 목적지

형식

위에 명시된 표준 LS2 헤더

  표준 LS2 유형별 부분
  - 속성 (공통 구조 사양에 명시된 대로 매핑, 없으면 2바이트 0)
  - 다음에 올 키 섹션 수 (1바이트, 최대 TBD)
  - 키 섹션:
    - 암호화 유형 (2바이트, 빅엔디언)
    - 암호화 키 길이 (2바이트, 빅엔디언)
      이는 명시적이므로, 알 수 없는 암호화 유형을 가진 LS2도 플러드필이 파싱할 수 있음
    - 암호화 키 (지정된 바이트 수)
  - lease2 수 (1바이트)
  - Lease2s (각각 40바이트)
    이들은 임대이지만, 8바이트 대신 4바이트 만료,
    에포크 이후 초 (2106년에 오버플로)

  표준 LS2 서명:
  - 서명
    플래그가 오프라인 키를 나타내면, 이는 일시적 공개 키로 서명됨,
    그렇지 않으면 목적지 공개 키로 서명됨
    서명 키의 서명 유형에 따라 암시되는 길이
    위의 모든 내용에 대한 서명

정당성

속성: 향후 확장성과 유연성. 나머지 데이터 파싱에 필요할 수 있으므로 먼저 배치됨.
여러 암호화 유형/공개 키 쌍은 새로운 암호화 유형으로의 전환을 용이하게 함. 다른 방법은 DSA 및 EdDSA 목적지를 위해 현재 수행하는 것처럼 동일한 터널을 사용하여 여러 leaseset을 게시하는 것임. 터널에서 들어오는 암호화 유형의 식별은 기존 세션 태그 메커니즘과/또는 각 키를 사용한 시험적 복호화로 수행할 수 있음. 들어오는 메시지의 길이도 단서를 제공할 수 있음.

논의

이 제안은 종단 간 암호화 키로 leaseset의 공개 키를 계속 사용하며, 현재와 마찬가지로 목적지의 공개 키 필드는 사용하지 않습니다. 목적지 키 인증서에는 암호화 유형이 지정되지 않으며, 0으로 유지됩니다.

거부된 대안은 목적지 키 인증서에 암호화 유형을 지정하고, 목적지의 공개 키를 사용하며, leaseset의 공개 키를 사용하지 않는 것입니다. 우리는 이를 계획하지 않습니다.

LS2의 장점:

실제 공개 키의 위치가 변경되지 않음
목적지를 변경하지 않고도 암호화 유형이나 공개 키를 변경할 수 있음
사용되지 않는 철회 필드 제거
이 제안의 다른 DatabaseEntry 유형과의 기본 호환성
여러 암호화 유형 허용

LS2의 단점:

공개 키 및 암호화 유형의 위치가 RouterInfo와 다름
leaseset에서 사용되지 않는 공개 키 유지
네트워크 전체에서 구현 필요; 대안으로, 실험적 암호화 유형을 허용하는 플러드필이 허용하는 경우 실험적 암호화 유형을 사용할 수 있음 (실험적 서명 유형 지원에 관한 관련 제안 136 및 137 참조). 대안 제안은 실험적 암호화 유형에 대해 구현하고 테스트하기 더 쉬울 수 있음.

새로운 암호화 문제

이 일부는 이 제안의 범위를 벗어나지만, 아직 별도의 암호화 제안이 없으므로 잠시 여기에 메모를 남깁니다. ECIES 제안 144 및 145도 참조하세요.

암호화 유형은 곡선, 키 길이, 종단 간 방식을 포함한 조합을 나타내며, 필요한 경우 KDF 및 MAC도 포함됨.
알 수 없는 암호화 유형에 대해서도 LS2가 파싱 가능하고 플러드필에 의해 검증 가능하도록 키 길이 필드를 포함했습니다.
제안될 첫 번째 새로운 암호화 유형은 아마도 ECIES/X25519일 것입니다. 종단 간에서 어떻게 사용되는지 (ElGamal/AES+SessionTag의 약간 수정된 버전 또는 ChaCha/Poly와 같은 완전히 새로운 방식)는 하나 이상의 별도 제안에서 지정될 것입니다. ECIES 제안 144 및 145도 참조하세요.

참고 사항

임대의 8바이트 만료가 4바이트로 변경됨.
철회를 구현한다면, 만료 필드를 0으로 설정하거나, 임대를 0개로 설정하거나, 둘 다 설정하는 방식으로 할 수 있음. 별도의 철회 키는 필요 없음.
암호화 키는 서버 선호도 순서대로, 가장 선호하는 키가 먼저 오도록 정렬됨. 기본 클라이언트 동작은 지원되는 암호화 유형 중 첫 번째 키를 선택하는 것입니다. 클라이언트는 암호화 지원, 상대적 성능 및 기타 요소에 따라 다른 선택 알고리즘을 사용할 수 있음.

암호화된 LS2

목표:

블라인딩 추가
여러 서명 유형 허용
새로운 암호 원시 요소가 필요하지 않음
선택적으로 각 수신자에게 암호화, 철회 가능
표준 LS2 및 메타 LS2만 암호화 지원

암호화된 LS2는 종단 간 마늘 메시지에서 절대 전송되지 않습니다. 위의 표준 LS2를 사용하세요.

기존 암호화된 LeaseSet과의 변경 사항:

보안을 위해 전체를 암호화
AES만 사용하지 않고 안전하게 암호화
각 수신자에게 암호화

조회: 표준 LS 플래그 (1) 저장: 암호화된 LS2 유형 (5) 저장 위치: 블라인딩된 서명 유형과 블라인딩된 공개 키의 해시 2바이트 서명 유형 (빅엔디언, 예: 0x000b) || 블라인딩된 공개 키 이 해시는 LS1과 동일하게 일일 “라우팅 키"를 생성하는 데 사용됨 일반적인 만료: 일반적인 LS처럼 10분, 또는 메타 LS처럼 몇 시간 게시자: 목적지

정의

암호화된 LS2에 사용되는 암호화 빌딩 블록에 해당하는 다음 함수를 정의합니다:

CSRNG(n) 암호학적으로 안전한 난수 생성기에서 n바이트 출력.

CSRNG가 암호학적으로 안전하다는 요구 외에도 (따라서 키 소재 생성에 적합함), 일부 n바이트 출력이 네트워크에서 노출되는 바이트 시퀀스 바로 앞과 뒤에 사용될 때도 안전해야 합니다 (예: 솔트 또는 암호화된 패딩). 신뢰할 수 없는 소스에 의존하는 구현은 네트워크에 노출될 출력을 해싱해야 합니다. [PRNG 참조](http://projectbullrun.org/dual-ec/ext-rand.html) 및 [Tor 개발자 토론](https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html) 참조.

H(p, d) 개인화 문자열 p와 데이터 d를 받아 32바이트 출력을 생성하는 SHA-256 해시 함수.

다음과 같이 SHA-256 사용::

    H(p, d) := SHA-256(p || d)

STREAM RFC 7539 Section 2.4 에 명시된 ChaCha20 스트림 암호, 초기 카운터는 1로 설정. S_KEY_LEN = 32 및 S_IV_LEN = 12.

ENCRYPT(k, iv, plaintext)
    암호화 키 k와 고유한 iv를 사용하여 평문을 암호화. 키가 비밀이면 전체 암호문이 무작위와 구분 불가능해야 함.

DECRYPT(k, iv, ciphertext)
    암호화 키 k와 iv를 사용하여 암호문을 복호화. 평문을 반환.

SIG 키 블라인딩이 있는 RedDSA 서명 방식 (서명 유형 11에 해당). 다음 함수를 가짐:

DERIVE_PUBLIC(privkey)
    주어진 개인 키에 해당하는 공개 키를 반환.

SIGN(privkey, m)
    주어진 메시지 m에 대한 개인 키 privkey의 서명을 반환.

VERIFY(pubkey, m, sig)
    공개 키 pubkey와 메시지 m에 대해 서명 sig를 검증. 서명이 유효하면 true, 그렇지 않으면 false 반환.

또한 다음 키 블라인딩 작업을 지원해야 함:

GENERATE_ALPHA(data, secret)
    데이터와 선택적 비밀을 아는 자를 위한 알파 생성. 결과는 개인 키와 동일하게 분포되어야 함.

BLIND_PRIVKEY(privkey, alpha)
    비밀 알파를 사용하여 개인 키를 블라인딩.

BLIND_PUBKEY(pubkey, alpha)
    비밀 알파를 사용하여 공개 키를 블라인딩.
    주어진 키쌍 (privkey, pubkey)에 대해 다음 관계가 성립::

        BLIND_PUBKEY(pubkey, alpha) ==
        DERIVE_PUBLIC(BLIND_PRIVKEY(privkey, alpha))

DH X25519 공개 키 합의 시스템. 개인 키 32바이트, 공개 키 32바이트, 출력 32바이트. 다음 함수를 가짐:

GENERATE_PRIVATE()
    새로운 개인 키 생성.

DERIVE_PUBLIC(privkey)
    주어진 개인 키에 해당하는 공개 키를 반환.

DH(privkey, pubkey)
    주어진 개인 키와 공개 키에서 공유 비밀 생성.

HKDF(salt, ikm, info, n) 일부 입력 키 소재 ikm (좋은 엔트로피를 가져야 하지만 균일한 무작위 문자열일 필요는 없음), 32바이트 길이의 솔트, 컨텍스트별 ‘info’ 값과 함께 작동하는 암호학적 키 도출 함수이며, 키 소재로 사용하기에 적합한 n바이트 출력을 생성.

[RFC 5869](https://tools.ietf.org/html/rfc5869)에 명시된 대로 HKDF 사용, [RFC 2104](https://tools.ietf.org/html/rfc2104)에 명시된 HMAC 해시 함수 SHA-256 사용. 즉, SALT_LEN은 최대 32바이트임.

형식

암호화된 LS2 형식은 세 개의 중첩된 계층으로 구성됩니다:

저장 및 검색을 위한 필요한 평문 정보를 포함하는 외부 계층.
클라이언트 인증을 처리하는 중간 계층.
실제 LS2 데이터를 포함하는 내부 계층.

전체 형식은 다음과 같습니다::

계층 0 데이터 + Enc(계층 1 데이터 + Enc(계층 2 데이터)) + 서명

암호화된 LS2는 블라인딩됨에 유의하세요. 헤더에 목적지가 없습니다. DHT 저장 위치는 SHA-256(sig 유형 || 블라인딩된 공개 키)이며, 매일 회전됨.

위에 명시된 표준 LS2 헤더를 사용하지 않습니다.

계층 0 (외부)

유형 1바이트

실제로 헤더에 포함되지 않지만, 서명이 적용되는 데이터의 일부임.
데이터베이스 저장 메시지의 필드에서 가져옴.

블라인딩된 공개 키 서명 유형 2바이트, 빅엔디언 항상 유형 11이며, Red25519 블라인딩된 키를 식별함.

블라인딩된 공개 키 서명 유형에 따라 암시되는 길이

게시 타임스탬프 4바이트, 빅엔디언

에포크 이후 초, 2106년에 오버플로

만료 2바이트, 빅엔디언

게시 타임스탬프 이후 초 단위 오프셋, 최대 18.2시간

플래그 2바이트

비트 순서: 15 14 ... 3 2 1 0

비트 0: 0이면 오프라인 키 없음; 1이면 오프라인 키 있음

기타 비트: 향후 사용과의 호환성을 위해 0으로 설정

일시적 키 데이터 플래그가 오프라인 키를 나타내면 존재

만료 타임스탬프
    4바이트, 빅엔디언

    에포크 이후 초, 2106년에 오버플로

일시적 서명 유형
    2바이트, 빅엔디언

일시적 서명 공개 키
    서명 유형에 따라 암시되는 길이

서명
    블라인딩된 공개 키 서명 유형에 따라 암시되는 길이

    만료 타임스탬프, 일시적 서명 유형 및 일시적 공개 키에 대한 서명.

    블라인딩된 공개 키로 검증.

lenOuterCiphertext 2바이트, 빅엔디언

outerCiphertext lenOuterCiphertext 바이트

암호화된 계층 1 데이터. 키 도출 및 암호화 알고리즘은 아래 참조.

서명 사용된 서명 키의 서명 유형에 따라 암시되는 길이

위의 모든 내용에 대한 서명.

플래그가 오프라인 키를 나타내면, 서명은 일시적 공개 키로 검증됨. 그렇지 않으면, 블라인딩된 공개 키로 검증됨.

계층 1 (중간)

플래그 1바이트

비트 순서: 76543210

비트 0: 0이면 모두에게, 1이면 클라이언트별, 다음에 인증 섹션 있음

비트 3-1: 인증 방식, 클라이언트별로 비트 0이 1로 설정된 경우에만, 그렇지 않으면 000
          000: DH 클라이언트 인증 (또는 클라이언트별 인증 없음)
          001: PSK 클라이언트 인증

비트 7-4: 사용되지 않음, 향후 호환성을 위해 0으로 설정

DH 클라이언트 인증 데이터 플래그 비트 0이 1로 설정되고 플래그 비트 3-1이 000으로 설정된 경우 존재.

ephemeralPublicKey
    32바이트

clients
    2바이트, 빅엔디언

    다음에 올 authClient 항목 수, 각각 40바이트

authClient
    단일 클라이언트에 대한 인증 데이터.
    아래의 클라이언트별 인증 알고리즘 참조.

    clientID_i
        8바이트

    clientCookie_i
        32바이트

PSK 클라이언트 인증 데이터 플래그 비트 0이 1로 설정되고 플래그 비트 3-1이 001로 설정된 경우 존재.

authSalt
    32바이트

clients
    2바이트, 빅엔디언

    다음에 올 authClient 항목 수, 각각 40바이트

authClient
    단일 클라이언트에 대한 인증 데이터.
    아래의 클라이언트별 인증 알고리즘 참조.

    clientID_i
        8바이트

    clientCookie_i
        32바이트

innerCiphertext lenOuterCiphertext에 의해 암시되는 길이 (남은 데이터)

암호화된 계층 2 데이터. 키 도출 및 암호화 알고리즘은 아래 참조.

계층 2 (내부)

유형 1바이트

3(LS2) 또는 7(메타 LS2) 중 하나

데이터 주어진 유형에 대한 LeaseSet2 데이터.

헤더와 서명을 포함.

블라인딩 키 도출

Ed25519 및 ZCash RedDSA 를 기반으로 한 다음 방식을 키 블라인딩에 사용합니다. Re25519 서명은 Ed25519 곡선에서 SHA-512를 해시로 사용합니다.

Tor의 rend-spec-v3.txt 부록 A.2 는 유사한 설계 목표를 가지지만, 그 블라인딩된 공개 키가 소수 차수 부분군에 있지 않을 수 있고, 보안 의미가 알려지지 않았기 때문에 사용하지 않습니다.

목표

블라인딩되지 않은 목적지의 서명 공개 키는 Ed25519(sig 유형 7) 또는 Red25519(sig 유형 11)여야 하며; 다른 서명 유형은 지원되지 않음
서명 공개 키가 오프라인인 경우, 일시적 서명 공개 키도 Ed25519여야 함
블라인딩은 계산적으로 간단해야 함
기존 암호화 원시 요소 사용
블라인딩된 공개 키는 블라인딩 해제될 수 없어야 함
블라인딩된 공개 키는 Ed25519 곡선과 소수 차수 부분군에 있어야 함
블라인딩된 공개 키를 도출하기 위해 목적지의 서명 공개 키를 알아야 함 (전체 목적지는 필요하지 않음)
선택적으로 블라인딩된 공개 키를 도출하기 위해 추가 비밀이 필요할 수 있음

보안

블라인딩 방식의 보안은 알파의 분포가 블라인딩되지 않은 개인 키와 동일해야 함을 요구합니다. 그러나 Ed25519 개인 키(sig 유형 7)를 Red25519 개인 키(sig 유형 11)로 블라인딩할 때 분포가 다릅니다. zcash 섹션 4.1.6.1 의 요구사항을 충족하기 위해, “재난수화된 공개 키와 그 키에 대한 서명의 조합이 재난수화된 키를 드러내지 않도록” Red25519(sig 유형 11)를 블라인딩되지 않은 키에도 사용해야 합니다. 기존 목적지에는 유형 7을 허용하지만, 암호화될 새로운 목적지에는 유형 11을 권장합니다.

정의

B Ed25519 에서와 같이 Ed25519 기준점(생성자) 2^255 - 19

L Ed25519 에서와 같이 Ed25519 차수 2^252 + 27742317777372353535851937790883648493

DERIVE_PUBLIC(a) Ed25519에서처럼 개인 키를 공개 키로 변환 (G로 곱함)

alpha 목적지를 아는 자가 아는 32바이트 난수

GENERATE_ALPHA(destination, date, secret) 목적지를 알고 비밀을 아는 자를 위해 현재 날짜에 대한 알파 생성. 결과는 Ed25519 개인 키와 동일하게 분포되어야 함.

a 목적지를 서명하는 데 사용되는 블라인딩되지 않은 32바이트 EdDSA 또는 RedDSA 서명 개인 키

A 목적지에 있는 블라인딩되지 않은 32바이트 EdDSA 또는 RedDSA 서명 공개 키, = DERIVE_PUBLIC(a), Ed25519에서처럼

a’ 암호화된 leaseset을 서명하는 데 사용되는 블라인딩된 32바이트 EdDSA 서명 개인 키 유효한 EdDSA 개인 키입니다.

A’ 목적지에 있는 블라인딩된 32바이트 EdDSA 서명 공개 키, DERIVE_PUBLIC(a’) 또는 A와 alpha에서 생성 가능. 곡선과 소수 차수 부분군에 있는 유효한 EdDSA 공개 키입니다.

LEOS2IP(x) 입력 바이트 순서를 리틀엔디언으로 뒤집음

H*(x) 32바이트 = (LEOS2IP(SHA512(x))) mod B, Ed25519 해시-감소와 동일

블라인딩 계산

매일(UTC) 새로운 비밀 알파와 블라인딩된 키를 생성해야 합니다. 비밀 알파와 블라인딩된 키는 다음과 같이 계산됩니다.

모든 당사자에 대한 GENERATE_ALPHA(destination, date, secret):

// GENERATE_ALPHA(destination, date, secret)

  // 비밀은 선택사항, 없으면 길이 0
  A = 목적지의 서명 공개 키
  stA = A의 서명 유형, 2바이트 빅엔디언 (0x0007 또는 0x000b)
  stA' = 블라인딩된 공개 키 A'의 서명 유형, 2바이트 빅엔디언 (0x000b)
  keydata = A || stA || stA'
  datestring = 현재 날짜 UTC의 8바이트 ASCII YYYYMMDD
  secret = UTF-8 인코딩된 문자열
  seed = HKDF(H("I2PGenerateAlpha", keydata), datestring || secret, "i2pblinding1", 64)
  // seed를 64바이트 리틀엔디언 값으로 취급
  alpha = seed mod L

leaseset을 게시하는 소유자에 대한 BLIND_PRIVKEY():

// BLIND_PRIVKEY()

  alpha = GENERATE_ALPHA(destination, date, secret)
  // Ed25519 개인 키(유형 7)의 경우
  seed = 목적지의 서명 개인 키
  a = seed의 SHA512 왼쪽 절반, Ed25519에 대해 일반적으로 클램핑
  // 그렇지 않으면, Red25519 개인 키(유형 11)의 경우
  a = 목적지의 서명 개인 키
  // 스칼라 산술을 사용한 덧셈
  블라인딩된 서명 개인 키 = a' = BLIND_PRIVKEY(a, alpha) = (a + alpha) mod L
  블라인딩된 서명 공개 키 = A' = DERIVE_PUBLIC(a')

leaseset을 검색하는 클라이언트에 대한 BLIND_PUBKEY():

// BLIND_PUBKEY()

  alpha = GENERATE_ALPHA(destination, date, secret)
  A = 목적지의 서명 공개 키
  // 군 원소(곡선의 점)를 사용한 덧셈
  블라인딩된 공개 키 = A' = BLIND_PUBKEY(A, alpha) = A + DERIVE_PUBLIC(alpha)

두 가지 A’ 계산 방법 모두 동일한 결과를 산출하며, 이는 요구됩니다.

서명

블라인딩되지 않은 leaseset은 블라인딩되지 않은 Ed25519 또는 Red25519 서명 개인 키로 서명되며, 블라인딩되지 않은 Ed25519 또는 Red25519 서명 공개 키(sig 유형 7 또는 11)로 검증됩니다.

서명 공개 키가 오프라인인 경우, 블라인딩되지 않은 leaseset은 블라인딩되지 않은 일시적 Ed25519 또는 Red25519 서명 개인 키로 서명되며, 블라인딩되지 않은 Ed25519 또는 Red25519 일시적 서명 공개 키(sig 유형 7 또는 11)로 검증됩니다. 암호화된 leaseset에 대한 오프라인 키에 대한 추가 참고 사항은 아래 참조.

암호화된 leaseset의 서명을 위해, RedDSA 를 기반으로 한 Red25519를 사용하여 블라인딩된 키로 서명하고 검증합니다. Red25519 서명은 Ed25519 곡선에서 SHA-512를 해시로 사용합니다.

Red25519는 표준 Ed25519와 동일하지만 아래에 명시된 부분을 제외하고는 동일합니다.

서명/검증 계산

암호화된 leaseset의 외부 부분은 Red25519 키와 서명을 사용합니다.

Red25519는 Ed25519와 거의 동일합니다. 두 가지 차이점이 있습니다:

Red25519 개인 키는 난수에서 생성된 후 위에 정의된 L로 mod를 취해야 합니다. Ed25519 개인 키는 난수에서 생성된 후 바이트 0과 31에서 비트 마스킹을 사용하여 “클램핑"됩니다. Red25519에서는 이 작업을 수행하지 않습니다. 위에 정의된 GENERATE_ALPHA() 및 BLIND_PRIVKEY() 함수는 mod L을 사용하여 적절한 Red25519 개인 키를 생성합니다.

Red25519에서 서명을 위한 r 계산은 추가 난수 데이터를 사용하며, 개인 키의 해시 대신 공개 키 값을 사용합니다. 난수 데이터로 인해 동일한 데이터를 동일한 키로 서명하더라도 모든 Red25519 서명이 다릅니다.

서명:

T = 80 난수 바이트
  r = H*(T || 공개키 || 메시지)
  // 나머지는 Ed25519와 동일

검증:

// Ed25519와 동일

암호화 및 처리

하위 자격 증명 도출

블라인딩 프로세스의 일부로, 암호화된 LS2는 해당 목적지의 서명 공개 키를 아는 자만이 복호화할 수 있도록 해야 합니다. 전체 목적지는 필요하지 않습니다. 이를 위해 서명 공개 키에서 자격 증명을 도출합니다:

A = 목적지의 서명 공개 키
  stA = A의 서명 유형, 2바이트 빅엔디언 (0x0007 또는 0x000b)
  stA' = A'의 서명 유형, 2바이트 빅엔디언 (0x000b)
  keydata = A || stA || stA'
  credential = H("credential", keydata)

개인화 문자열은 자격 증명이 일반 목적지 해시와 같은 DHT 조회 키로 사용되는 해시와 충돌하지 않도록 보장합니다.

주어진 블라인딩된 키에 대해 하위 자격 증명을 도출할 수 있습니다:

subcredential = H("subcredential", credential || 블라인딩된공개키)

하위 자격 증명은 아래의 키 도출 프로세스에 포함되어, 해당 키를 목적지의 서명 공개 키에 대한 지식에 바인딩합니다.

계층 1 암호화

먼저, 키 도출 프로세스의 입력을 준비합니다:

outerInput = subcredential || 게시타임스탬프

다음으로, 난수 솔트를 생성합니다:

outerSalt = CSRNG(32)

그런 다음, 계층 1을 암호화하는 데 사용되는 키를 도출합니다:

keys = HKDF(outerSalt, outerInput, "ELS2_L1K", 44)
  outerKey = keys[0:31]
  outerIV = keys[32:43]

마지막으로, 계층 1 평문을 암호화하고 직렬화합니다:

outerCiphertext = outerSalt || ENCRYPT(outerKey, outerIV, outerPlaintext)

계층 1 복호화

솔트는 계층 1 암호문에서 파싱됩니다:

outerSalt = outerCiphertext[0:31]

그런 다음, 계층 1을 암호화하는 데 사용되는 키를 도출합니다:

outerInput = subcredential || 게시타임스탬프
  keys = HKDF(outerSalt, outerInput, "ELS2_L1K", 44)
  outerKey = keys[0:31]
  outerIV = keys[32:43]

마지막으로, 계층 1 암호문을 복호화합니다:

outerPlaintext = DECRYPT(outerKey, outerIV, outerCiphertext[32:end])

계층 2 암호화

클라이언트 인증이 활성화된 경우, 아래에 설명된 대로 authCookie가 계산됩니다. 클라이언트 인증이 비활성화된 경우, authCookie는 길이가 0인 바이트 배열입니다.

암호화는 계층 1과 유사한 방식으로 진행됩니다:

innerInput = authCookie || subcredential || 게시타임스탬프
  innerSalt = CSRNG(32)
  keys = HKDF(innerSalt, innerInput, "ELS2_L2K", 44)
  innerKey = keys[0:31]
  innerIV = keys[32:43]
  innerCiphertext = innerSalt || ENCRYPT(innerKey, innerIV, innerPlaintext)

계층 2 복호화

복호화는 계층 1과 유사한 방식으로 진행됩니다:

innerInput = authCookie || subcredential || 게시타임스탬프
  innerSalt = innerCiphertext[0:31]
  keys = HKDF(innerSalt, innerInput, "ELS2_L2K", 44)
  innerKey = keys[0:31]
  innerIV = keys[32:43]
  innerPlaintext = DECRYPT(innerKey, innerIV, innerCiphertext[32:end])

클라이언트별 인증

목적지에 대해 클라이언트 인증이 활성화된 경우, 서버는 암호화된 LS2 데이터를 복호화하도록 승인된 클라이언트 목록을 유지합니다. 클라이언트별로 저장되는 데이터는 인증 메커니즘에 따라 달라지며, 각 클라이언트가 생성하고 안전한 비대칭 메커니즘을 통해 서버에 보내는 키 소재의 일부 형태를 포함합니다.

클라이언트별 인증을 구현하는 두 가지 대안이 있습니다:

DH 클라이언트 인증

각 클라이언트는 DH 키쌍 [csk_i, cpk_i]를 생성하고 공개 키 cpk_i를 서버에 보냅니다.

서버 처리 ^^^^^^^^^^^^^^^^^ 서버는 새로운 authCookie와 일시적 DH 키쌍을 생성합니다:

authCookie = CSRNG(32)
  esk = GENERATE_PRIVATE()
  epk = DERIVE_PUBLIC(esk)

그런 다음, 승인된 각 클라이언트에 대해 서버는 공개 키로 authCookie를 암호화합니다:

sharedSecret = DH(esk, cpk_i)
  authInput = sharedSecret || cpk_i || subcredential || 게시타임스탬프
  okm = HKDF(epk, authInput, "ELS2_XCA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]
  clientCookie_i = ENCRYPT(clientKey_i, clientIV_i, authCookie)

서버는 각 [clientID_i, clientCookie_i] 튜플을 암호화된 LS2의 계층 1에 epk와 함께 배치합니다.

클라이언트 처리 ^^^^^^^^^^^^^^^^^ 클라이언트는 개인 키를 사용하여 예상 클라이언트 식별자 clientID_i, 암호화 키 clientKey_i, 암호화 IV clientIV_i를 도출합니다:

sharedSecret = DH(csk_i, epk)
  authInput = sharedSecret || cpk_i || subcredential || 게시타임스탬프
  okm = HKDF(epk, authInput, "ELS2_XCA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]

그런 다음, 클라이언트는 clientID_i를 포함하는 항목을 계층 1 인증 데이터에서 검색합니다. 일치하는 항목이 있으면, 클라이언트는 이를 복호화하여 authCookie를 얻습니다:

authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i)

사전 공유 키 클라이언트 인증

각 클라이언트는 비밀 32바이트 키 psk_i를 생성하고 서버에 보냅니다. 또는 서버가 비밀 키를 생성하여 하나 이상의 클라이언트에게 보낼 수 있습니다.

서버 처리 ^^^^^^^^^^^^^^^^^ 서버는 새로운 authCookie와 솔트를 생성합니다:

authCookie = CSRNG(32)
  authSalt = CSRNG(32)

그런 다음, 승인된 각 클라이언트에 대해 서버는 사전 공유 키로 authCookie를 암호화합니다:

authInput = psk_i || subcredential || 게시타임스탬프
  okm = HKDF(authSalt, authInput, "ELS2PSKA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]
  clientCookie_i = ENCRYPT(clientKey_i, clientIV_i, authCookie)

서버는 각 [clientID_i, clientCookie_i] 튜플을 암호화된 LS2의 계층 1에 authSalt와 함께 배치합니다.

클라이언트 처리 ^^^^^^^^^^^^^^^^^ 클라이언트는 사전 공유 키를 사용하여 예상 클라이언트 식별자 clientID_i, 암호화 키 clientKey_i, 암호화 IV clientIV_i를 도출합니다:

authInput = psk_i || subcredential || 게시타임스탬프
  okm = HKDF(authSalt, authInput, "ELS2PSKA", 52)
  clientKey_i = okm[0:31]
  clientIV_i = okm[32:43]
  clientID_i = okm[44:51]

authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i)

보안 고려사항

위의 두 클라이언트 인증 메커니즘 모두 클라이언트 멤버십에 대한 개인정보를 제공합니다. 목적지를 아는 자만이 현재 몇 명의 클라이언트가 구독 중인지 알 수 있지만, 어떤 클라이언트가 추가되거나 철회되는지는 추적할 수 없습니다.

서버는 클라이언트가 목록에서 자신의 위치를 알거나 다른 클라이언트가 추가되거나 철회되는 것을 추론하지 못하도록 암호화된 LS2를 생성할 때마다 클라이언트 순서를 무작위로 해야 합니다.

서버는 인증 데이터 목록에 무작위 항목을 삽입하여 구독 중인 클라이언트 수를 숨길 수 있습니다.

DH 클라이언트 인증의 장점 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

이 방식의 보안은 클라이언트 키 소재의 비대칭 교환에만 의존하지 않습니다. 클라이언트의 개인 키는 장치를 떠날 필요가 없으므로, 비대칭 교환을 가로챌 수 있는 공격자가 DH 알고리즘을 깨지 못하면 암호화된 LS2를 복호화하거나 클라이언트가 얼마나 오래 액세스 권한을 부여받았는지 알 수 없습니다.

DH 클라이언트 인증의 단점 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

서버 측에서 N 클라이언트에 대해 N + 1개의 DH 연산이 필요합니다.
클라이언트 측에서 하나의 DH 연산이 필요합니다.
클라이언트가 비밀 키를 생성해야 합니다.

PSK 클라이언트 인증의 장점 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

DH 연산이 필요하지 않습니다.
서버가 비밀 키를 생성할 수 있습니다.
원하는 경우 여러 클라이언트와 동일한 키를 공유할 수 있습니다.

PSK 클라이언트 인증의 단점 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

이 방식의 보안은 클라이언트 키 소재의 비대칭 교환에 매우 의존합니다. 특정 클라이언트의 교환을 가로챈 공격자는 해당 클라이언트가 승인된 이후의 모든 후속 암호화된 LS2를 복호화할 수 있으며, 클라이언트의 액세스가 언제 철회되는지 알 수 있습니다.

Base 32 주소를 사용한 암호화된 LS

제안 149 참조.

비트토런트에는 암호화된 LS2를 사용할 수 없습니다. 컴팩트 공지 응답이 32바이트이기 때문입니다. 32바이트에는 해시만 포함되어 있습니다. leaseset이 암호화되었음을 나타내거나 서명 유형을 나타낼 공간이 없습니다.

오프라인 키를 사용한 암호화된 LS

오프라인 키를 사용한 암호화된 leaseset의 경우, 블라인딩된 개인 키도 매일 오프라인에서 생성되어야 합니다.

선택적 오프라인 서명 블록은 암호화된 leaseset의 평문 부분에 있으므로, 플러드필을 스크래핑하는 자는 이를 사용하여 leaseset을 여러 날에 걸쳐 추적할 수 있습니다 (복호화는 불가). 이를 방지하기 위해 키 소유자는 매일 새로운 일시적 키도 생성해야 합니다. 일시적 키와 블라인딩된 키 모두 미리 생성하여 라우터에 일괄적으로 전달할 수 있습니다.

이 제안에서는 여러 일시적 및 블라인딩된 키를 패키징하고 클라이언트 또는 라우터에 제공하기 위한 파일 형식을 정의하지 않습니다. 오프라인 키를 사용한 암호화된 leaseset을 지원하기 위한 I2CP 프로토콜 확장을 이 제안에서 정의하지 않습니다.

참고 사항

암호화된 leaseset을 사용하는 서비스는 암호화된 버전을 플러드필에 게시합니다. 그러나 효율성을 위해, 인증 후 (예: 화이트리스트를 통해) 클라이언트에게 마늘 메시지에서 암호화되지 않은 leaseset을 보냅니다.
플러드필은 남용을 방지하기 위해 최대 크기를 합리적인 값으로 제한할 수 있습니다.
복호화 후, 내부 타임스탬프와 만료가 최상위 수준과 일치하는지 확인해야 합니다.
AES보다 ChaCha20를 선택했습니다. AES 하드웨어 지원이 있는 경우 속도는 비슷하지만, AES 하드웨어 지원이 없는 경우(예: 저가형 ARM 장치) ChaCha20가 2.5-3배 더 빠릅니다.
속도에 너무 신경 쓰지 않아서 키가 있는 BLAKE2b를 사용하지 않습니다. 가장 큰 n 요구 사항을 수용할 만큼 충분한 출력 크기를 가지며 (또는 원하는 키마다 카운터 인수로 한 번 호출할 수 있음). BLAKE2b는 SHA-256보다 훨씬 빠르며, 키가 있는 BLAKE2b는 해시 함수 호출 총 수를 줄일 수 있습니다. 그러나 제안 148을 참조하세요. 여기서 다른 이유로 BLAKE2b로 전환하는 것이 제안됩니다. 안전한 키 도출 성능 참조.

메타 LS2

이것은 멀티호밍을 대체하는 데 사용됩니다. 다른 leaseset과 마찬가지로, 생성자가 서명합니다. 이것은 목적지 해시의 인증된 목록입니다.

메타 LS2는 트리 구조의 최상위 노드이자 중간 노드일 수 있습니다. LS, LS2 또는 다른 메타 LS2를 가리키는 여러 항목을 포함하여 대규모 멀티호밍을 지원합니다. 메타 LS2는 LS, LS2 및 메타 LS2 항목의 혼합을 포함할 수 있습니다. 트리의 리프는 항상 LS 또는 LS2입니다. 트리는 DAG입니다. 루프는 금지되며, 조회를 수행하는 클라이언트는 루프를 감지하고 따르지 않아야 합니다.

메타 LS2는 표준 LS 또는 LS2보다 훨씬 더 긴 만료 시간을 가질 수 있습니다. 최상위 수준은 게시 날짜 이후 몇 시간 후에 만료될 수 있습니다. 최대 만료 시간은 플러드필과 클라이언트에 의해 시행되며, TBD입니다.

메타 LS2의 사용 사례는 대규모 멀티호밍이지만, LS 또는 LS2가 현재 제공하는 것보다 라우터와 leaseset의 상관 관계(라우터 재시작 시)에 대한 보호가 더 많지 않습니다. 이것은 “페이스북” 사용 사례와 동일하며, 아마도 상관 관계 보호가 필요하지 않을 것입니다. 이 사용 사례는 아마도 오프라인 키가 필요할 것이며, 트리의 각 노드에서 표준 헤더에 제공됩니다.

리프 라우터, 중간 및 마스터 메타 LS 서명자 간의 조정을 위한 백엔드 프로토콜은 여기에서 지정되지 않습니다. 요구 사항은 매우 간단합니다 - 피어가 작동 중인지 확인하고 몇 시간마다 새 LS를 게시합니다. 유일한 복잡성은 장애 시 최상위 또는 중간 수준 메타 LS의 새 게시자를 선택하는 것입니다.

여러 라우터의 임대를 결합하고 서명하여 단일 leaseset에 게시하는 믹스 앤 매치 leaseset은 제안 140, “보이지 않는 멀티호밍"에서 문서화되어 있습니다. 이 제안은 작성된 대로 실현 불가능합니다. 스트리밍 연결이 단일 라우터에 “스티키"하지 않기 때문입니다. http://zzz.i 2p/topics/2335 참조.

보이지 않는 멀티호밍의 경우 백엔드 프로토콜과 라우터 및 클라이언트 내부와의 상호 작용은 매우 복잡할 것입니다.

최상위 메타 LS의 플러드필을 과부하하지 않기 위해 만료 시간은 최소 몇 시간이어야 합니다. 클라이언트는 최상위 메타 LS를 캐시하고 만료되지 않은 경우 재시작 시에도 유지해야 합니다.

클라이언트가 트리를 탐색하고, 폴백을 포함하여 사용이 분산되도록 하는 알고리즘을 정의해야 합니다. 해시 거리, 비용 및 무작위성의 일부 함수. 노드가 LS 또는 LS2와 메타 LS를 모두 가진 경우, 언제 이러한 leaseset을 사용할 수 있고 언제 트리를 계속 탐색해야 하는지 알아야 합니다.

조회: 표준 LS 플래그 (1) 저장: 메타 LS2 유형 (7) 저장 위치: 목적지의 해시 이 해시는 LS1과 동일하게 일일 “라우팅 키"를 생성하는 데 사용됨 일반적인 만료: 시간 단위. 최대 18.2시간 (65535초) 게시자: “마스터” 목적지 또는 조정자, 또는 중간 조정자

형식

위에 명시된 표준 LS2 헤더

  메타 LS2 유형별 부분
  - 속성 (공통 구조 사양에 명시된 대로 매핑, 없으면 2바이트 0)
  - 항목 수 (1바이트) 최대 TBD
  - 항목. 각 항목은 다음을 포함함: (40바이트)
    - 해시 (32바이트)
    - 플래그 (2바이트)
      TBD. 향후 사용과의 호환성을 위해 모두 0으로 설정.
    - 유형 (1바이트) 참조하는 LS의 유형;
      1은 LS, 3은 LS2, 5는 암호화된, 7은 메타, 0은 알 수 없음.
    - 비용 (우선순위) (1바이트)
    - 만료 (4바이트) (4바이트, 빅엔디언, 에포크 이후 초, 2106년에 오버플로)
  - 철회 수 (1바이트) 최대 TBD
  - 철회: 각 철회는 다음을 포함함: (32바이트)
    - 해시 (32바이트)

  표준 LS2 서명:
  - 서명 (40+ 바이트)
    위의 모든 내용에 대한 서명.

플래그 및 속성: 향후 사용

참고 사항

이 기능을 사용하는 분산 서비스는 서비스 목적지의 개인 키를 가진 하나 이상의 “마스터"를 가집니다. 그들은 (비대칭적으로) 현재 활성 목적지 목록을 결정하고 메타 LS2를 게시합니다. 중복성을 위해 여러 마스터가 메타 LS2를 멀티호밍(즉, 동시 게시)할 수 있습니다.
분산 서비스는 단일 목적지에서 시작하거나 기존 스타일의 멀티호밍을 사용한 다음 메타 LS2로 전환할 수 있습니다. 표준 LS 조회는 LS, LS2 또는 메타 LS2 중 하나를 반환할 수 있습니다.
서비스가 메타 LS2를 사용할 때, 터널(임대)이 없습니다.

서비스 레코드

이것은 목적지가 서비스에 참여하고 있다는 개별 레코드입니다. 참가자가 플러드필로 보냅니다. 개별적으로 플러드필이 보내는 것은 아니며, 서비스 목록의 일부로만 보냅니다. 서비스 레코드는 만료를 0으로 설정하여 서비스 참여를 철회하는 데에도 사용됩니다.

이것은 LS2가 아니지만 표준 LS2 헤더 및 서명 형식을 사용합니다.

조회: n/a, 서비스 목록 참조 저장: 서비스 레코드 유형 (9) 저장 위치: 서비스 이름의 해시 이 해시는 LS1과 동일하게 일일 “라우팅 키"를 생성하는 데 사용됨 일반적인 만료: 시간 단위. 최대 18.2시간 (65535초) 게시자: 목적지

형식

위에 명시된 표준 LS2 헤더

  서비스 레코드 유형별 부분
  - 포트 (2바이트, 빅엔디언) (지정되지 않은 경우 0)
  - 서비스 이름의 해시 (32바이트)

  표준 LS2 서명:
  - 서명 (40+ 바이트)
    위의 모든 내용에 대한 서명.

참고 사항

만료가 모두 0이면, 플러드필은 레코드를 철회하고 더 이상 서비스 목록에 포함하지 않아야 합니다.
저장: 플러드필은 이러한 레코드의 저장을 엄격히 제한하고 해시당 저장된 레코드 수와 만료를 제한할 수 있습니다. 해시의 화이트리스트도 사용할 수 있습니다.
동일한 해시에 있는 다른 netdb 유형은 우선 순위를 가지므로, 서비스 레코드는 LS/RI를 덮어쓸 수 없지만, LS/RI는 해당 해시의 모든 서비스 레코드를 덮어씁니다.

서비스 목록

이것은 LS2와 전혀 다르며 다른 형식을 사용합니다.

서비스 목록은 플러드필에 의해 생성되고 서명됩니다. 누구나 서비스 레코드를 플러드필에 게시하여 서비스에 가입할 수 있으므로 인증되지 않습니다.

서비스 목록은 전체 서비스 레코드가 아닌 짧은 서비스 레코드를 포함합니다. 이들은 서명을 포함하지만 해시만 포함하며 전체 목적지를 포함하지 않으므로 전체 목적지를 알지 않고는 검

상태

개요

제안

목표

비목표 / 범위 외

정당성

NetDB 데이터 유형

참고 사항

조회/저장 절차

형식

개인정보/보안 고려사항

표준 LS2 헤더

형식

정당성

문제점

참고 사항

새로운 DatabaseEntry 유형

LeaseSet 2

형식

정당성

논의

새로운 암호화 문제

참고 사항

암호화된 LS2

정의

형식

계층 0 (외부)

계층 1 (중간)

계층 2 (내부)

블라인딩 키 도출

목표

보안

정의

블라인딩 계산

서명

서명/검증 계산

암호화 및 처리

하위 자격 증명 도출

계층 1 암호화

계층 1 복호화

계층 2 암호화

계층 2 복호화

클라이언트별 인증

DH 클라이언트 인증

사전 공유 키 클라이언트 인증

보안 고려사항

Base 32 주소를 사용한 암호화된 LS

오프라인 키를 사용한 암호화된 LS

참고 사항

메타 LS2

형식

참고 사항

서비스 레코드

형식

참고 사항

서비스 목록

커뮤니티 설문 조사