안녕하세요 여러분, 또 그 시간이 돌아왔네요
- Index
- squid/www/cvs/dev.i2p 복구됨 2) SSU 테스트 3) I2CP 암호화 4) ???
- squid/www/cvs/dev.i2p restored
여러 코로케이션 서버와 한참 씨름한 끝에, 몇 가지 예전 서비스가 복구되었습니다 - squid.i2p(기본 outproxy(외부 프록시) 두 개 중 하나), www.i2p(www.i2p.net으로의 보안 포인터), dev.i2p(dev.i2p.net으로의 보안 포인터로, 메일링 리스트 아카이브, cvsweb, 그리고 기본 netDb 시드를 찾을 수 있는 곳), 그리고 cvs.i2p(우리의 CVS 서버로의 보안 포인터 - cvs.i2p.net:2401). 제 블로그는 여전히 자취를 감췄지만, 어차피 콘텐츠가 유실되었으니 조만간 새로 시작해야 할 것 같습니다. 이제 이러한 서비스들이 안정적으로 다시 온라인에 올라왔으니, 다음 단계로 넘어갈 시간입니다…
- SSU testing
모든 사용자의 router 콘솔에 있는 작은 노란 상자에서 언급했듯이, 우리는 SSU에 대한 라이브 네트워크 테스트의 다음 라운드를 시작했습니다. 이 테스트는 모든 사람을 위한 것은 아니지만, 모험심이 있고 일부 수동 구성을 하는 데 익숙하다면, router 콘솔에 안내된 세부 정보를 확인해 보세요 (http://localhost:7657/index.jsp). 테스트는 여러 차례 진행될 수 있지만, 0.6 릴리스 이전에 SSU에 중대한 변경 사항이 있을 것으로는 예상하지 않습니다 (0.6.1에서는 포트 포워딩을 할 수 없거나 그 밖의 이유로 인바운드 UDP 연결을 수신할 수 없는 사용자를 위한 지원이 추가됩니다).
- I2CP crypto
새로운 소개 문서를 다시 검토하면서, I2CP SDK 내부에서 수행되는 추가적인 암호화 레이어를 정당화하기가 조금 어렵습니다. I2CP 암호화 레이어의 원래 목적은 전송되는 메시지에 대한 기본적인 종단 간 보호를 제공하고, 또한 I2CP 클라이언트(I2PTunnel, the SAM bridge, I2Phex, azneti2p 등)가 신뢰할 수 없는 router를 통해 통신할 수 있도록 하는 것이었습니다. 그러나 구현이 진행되면서, 모든 클라이언트 메시지는 router에 의해 garlic messages(여러 메시지를 하나로 묶는 I2P 방식) 내부에서 종단 간으로 암호화되고, 송신자의 leaseSet과 때때로 전달 상태 메시지가 함께 묶이기 때문에, I2CP 레이어의 종단 간 보호는 중복적인 것이 되었습니다. 이 garlic layer는 이미 송신자의 router에서 수신자의 router까지 종단 간 암호화를 제공합니다. 유일한 차이는, 해당 router 자체가 악의적인 경우에 대해서는 보호하지 못한다는 점입니다.
그런데 예상 가능한 사용 사례들을 살펴보면, 로컬 router를 신뢰하지 않는 타당한 시나리오는 떠올리기 어렵습니다. 최소한 I2CP 암호화는 router에서 전송되는 메시지의 내용만 숨길 뿐이며 - router는 여전히 그것을 어느 목적지로 보내야 하는지 알아야 합니다. 필요하다면 I2CP 클라이언트와 router가 서로 다른 머신에서 동작하도록 SSH/SSL I2CP listener를 추가할 수 있고, 그런 구성이 필요한 사람들은 기존 tunnelling 도구를 사용할 수도 있습니다.
현재 사용 중인 암호화 계층을 다시 한 번 정리하면 다음과 같습니다:
- I2CP의 종단 간 ElGamal/AES+SessionTag 계층으로, 발신자의 destination(목적지 식별자)에서 수신자의 destination까지 암호화합니다.
- router의 종단 간 garlic encryption 계층 (ElGamal/AES+SessionTag)로, 발신자의 router에서 수신자의 router 까지 암호화합니다.
- inbound 및 outbound 둘 모두에 대한 tunnel 암호화 계층은 각 tunnel을 따라 있는 홉에서 적용됩니다(단, outbound 엔드포인트와 inbound 게이트웨이 사이는 제외).
- 각 router 사이의 전송 암호화 계층.
그 계층들 중 하나를 제거하는 데는 꽤 신중하고 싶지만, 불필요한 작업으로 우리의 자원을 낭비하고 싶지는 않습니다. 제가 제안하는 것은 첫 번째 I2CP 암호화 계층을 제거하는 것입니다(물론 I2CP 세션 설정, leaseSet 권한 부여, 그리고 발신자 인증에 사용되는 인증은 계속 유지합니다). 그것을 유지해야 할 이유를 누가 제시할 수 있을까요?
- ???
당장은 대략 이 정도이지만, 늘 그렇듯이 많은 일이 진행 중입니다. 이번 주에도 회의는 없지만, 누군가 제기할 내용이 있다면 주저하지 말고 메일링 리스트나 포럼에 올려 주세요. 또한 제가 #i2p에서 이전 대화 기록을 읽기는 하지만, 더 많은 사람이 논의에 참여할 수 있도록 일반적인 질문이나 우려 사항은 메일링 리스트로 보내 주시기 바랍니다.
=jr