제가 언급한 프로젝트를 위해 이 스레드에서 gRPC를 통해 서로 통신할 노드 네트워크를 구축하고 있습니다. SSL/TLS(실제로는 mTLS)를 암호화뿐만 아니라 가장 중요하게는 인증을 위해 사용할 것입니다. 이를 통해 각 노드는 자신이 통신하는 노드, 즉 피어의 공개 키/지갑 주소를 정확히 알 수 있습니다. 물론 완전히 분산된 프로젝트에는 중앙 구성 요소가 없어야 하므로 인증 기관은 전혀 관여하지 않으며 모든 SSL 인증서는 자체 서명됩니다.
이제 문제가 있습니다. 원칙적으로 자체 서명된 인증서는 개인 키의 소유권을 증명하므로, 지갑과 자체 서명된 인증서에 동일한 키 쌍을 사용할 수 있습니다. 이렇게 하면 피어가 인증서가 자체 서명되었더라도 정확히 어떤 지갑과 통신하고 있는지 알 수 있습니다. 그러나 저는 거의 확실히 팔라스 곡선 위의 슈노어 서명 체계를 지갑에 사용할 예정이며(이유를 물어보셔도 좋습니다), 불행히도 SSL은 이를 지원하지 않습니다.
가능한 해결책
동일한 스레드에서 볼 수 있듯이, 저는 최근 타원곡선 암호화와 슈노어 체계에 대해 배우기 시작했습니다. 그리고 키 유도는 서명 체계와 독립적이며 특정 곡선에만 의존한다는 것을 알게 되었습니다. 그래서 이런 생각이 떠올랐습니다: 지갑과 자체 서명된 인증서에 동일한 개인 키 스칼라를 사용하고, 그런 다음 두 개의 결과 공개 키(인증서의 Ed25519 공개 키와 지갑의 팔라스 공개 키)가 상관관계가 있고 동일한 개인 키를 공유한다는 것을 어떻게든 증명할 수 있을까요?
그것에 가까워질 수 있을 것 같습니다. 그리고 상당한 맞춤형 암호화를 구현해야 할 것 같은데, 이는 위험할 수 있지만 여전히 추구할 만한 가치가 있다고 생각합니다.
일반적인 필드 외에도 제 mTLS 인증서에는 다음이 포함됩니다:
- 노드 지갑의 공개 팔라스 키,
- 개인 키를 공개하지 않고 Ed25519 공개 키와 팔라스 공개 키가 상관관계가 있다는 것을 피어에게 납득시키는 영지식 증명.
후자는 기본적으로 두 곡선(25519와 팔라스) 위에서 계산된 "이중" 슈노어 스타일 서명입니다. 서명이 두 곡선과 두 공개 키에서 모두 확인되면 피어는 납득하게 됩니다.
주의해야 할 점은 개인 키 스칼라가 두 곡선의 필드에서 모두 유효해야 하므로 min(n_{25519}, n_{Pallas})보다 엄격히 작아야 한다는 것입니다. n_C는 곡선 C의 스칼라 필드 순서(기본 필드 순서와 혼동하지 말 것)입니다. 두 곡선 모두 스칼라 필드 순서가 2^{25something}(2^{252} for 25519 및 2^{255} for 팔라스) 근처에 있기 때문에 문제가 되지 않을 것 같습니다.
