블록체인 핸드셰이크: 무신뢰 키 교환

두 Z-Text 사용자가 메시지를 교환하기 전에, "핸드셰이크" — 공유 암호화 키를 설정하는 암호학적 프로토콜 — 를 완료해야 합니다. 이 글에서는 그것이 어떻게 작동하는지와 보안에 왜 중요한지를 설명합니다.

왜 핸드셰이크가 필요한가?

기존의 암호화 메신저에서는 중앙 서버가 키 교환을 중개합니다. Signal에서 누군가에게 메시지를 보낼 때, Signal의 서버가 초기 키 합의를 촉진합니다. 이는 잘 작동하지만 신뢰 의존성을 도입합니다 — 서버가 올바른 키를 전달한다고 신뢰해야 합니다.

Z-Text에는 서버가 없습니다. 핸드셰이크는 전적으로 블록체인 거래를 통해 수행되므로, 트러스트리스하고 검증 가능합니다. 어떤 중개자도 키 교환을 조작하거나 관찰할 수 없습니다.

프로토콜

Z-Text 핸드셰이크는 블록체인 기반 전달에 맞게 조정된 수정된 Diffie-Hellman 키 교환 프로토콜을 따릅니다:

1단계: 시작

Alice가 Bob에게 메시지를 보내려 합니다. 그녀는 Bob의 z-address를 알고 있습니다. Alice의 앱은 임시 키 쌍을 생성하고 Bob의 z-address로 차폐 거래를 만듭니다. 거래 메모에는 Alice의 임시 공개 키와 그녀의 z-address가 포함됩니다.

이것은 차폐 거래이므로, 블록체인을 관찰하는 누구도 Alice가 Bob에게 무언가를 보냈다거나, 메모에 무엇이 포함되어 있는지 볼 수 없습니다.

2단계: 감지

Bob이 지갑을 동기화하면, 그의 앱이 수신 거래를 감지하고 메모를 읽습니다. 메모 형식의 특정 프로토콜 마커 때문에 이것이 핸드셰이크 요청임을 인식합니다.

Bob의 앱은 Alice의 z-address와 함께 핸드셰이크 요청을 표시하며, 수락 또는 거절을 요청합니다.

3단계: 응답

Bob이 수락하면, 그의 앱은 자체 임시 키 쌍을 생성하고 Alice의 z-address로 응답 거래를 보냅니다. 메모에는 Bob의 임시 공개 키가 포함됩니다.

4단계: 키 파생

Alice와 Bob은 이제 서로의 임시 공개 키를 가지고 있습니다. 각각은 Elliptic Curve Diffie-Hellman (ECDH)을 사용하여 독립적으로 공유 비밀을 계산합니다. ECDH의 수학적 속성은 양쪽이 공유 비밀이 전송되지 않고도 동일한 공유 비밀에 도달하는 것을 보장합니다.

이 공유 비밀은 Alice와 Bob 간의 모든 향후 메시지에 대한 대칭 암호화 키를 파생하는 기초로 사용됩니다.

보안 속성

블록체인 핸드셰이크는 여러 중요한 보안 속성을 제공합니다:

• 기밀성: 키 교환은 차폐 거래 안에 숨겨져 있어, 관찰자에게 보이지 않습니다
• 무결성: 블록체인의 작업 증명은 거래가 조작될 수 없도록 보장합니다
• 진정성: z-address 개인 키의 보유자만이 핸드셰이크 응답을 만들 수 있습니다
• MITM 불가: 중앙 서버가 없으므로, 키를 대체할 수 있는 중개자가 없습니다

Signal Protocol과의 비교

Signal Protocol은 중앙 서버를 사용하여 사전 키를 저장하고 전달합니다. 이는 비동기적 키 교환 (오프라인인 사람에게 메시지를 보낼 수 있음)을 가능하게 하지만, Signal의 서버가 올바른 키를 전달한다고 신뢰해야 합니다.

Z-Text의 블록체인 핸드셰이크도 비동기적입니다 (Alice가 요청을 보낼 때 Bob이 온라인일 필요가 없음). 그러나 전달 메커니즘은 기업 서버가 아닌 탈중앙화된 블록체인입니다. 핸드셰이크 단계는 G-stream mempool push를 통해 감지되어, 단계당 수 초 만에 완료되며, 신뢰 모델은 근본적으로 더 강력합니다.

실용적 고려사항

핸드셰이크는 일반적으로 G-stream mempool push를 통해 단계당 수 초 이내에 완료됩니다. 각 단계는 소량의 BTCZ 거래 수수료가 필요합니다. 설정이 완료되면, 공유 키는 로컬에 저장되며 갱신할 필요가 없습니다 — 두 연락처 간의 모든 향후 메시지는 동일한 키를 사용합니다.

연락처가 삭제되고 다시 추가되면, 완전히 새로운 공유 비밀을 생성하는 새 핸드셰이크를 수행해야 합니다.