I2P 개발자 회의 - 2006년 2월 7일

15:36 <jrandom> 0) 안녕하세요 15:36 <jrandom> 1) 네트워크 현황 15:36 <jrandom> 2) _PRE net 진행 상황 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) 안녕하세요 15:37 * jrandom 손을 흔든다 15:37 <jrandom> 주간 상태 노트를 여기에 올렸습니다 @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> 안녕하세요 15:38 <jrandom> 그 지극히 '흥미진진한' 자료를 파헤치시는 동안, 그럼 1) 네트워크 현황으로 바로 들어가죠 15:38 <jrandom> 지난주 라이브 네트워크에서는 I2P 관점에서 크게 바뀐 게 없어서, 여기서 덧붙일 말이 많진 않아요 15:39 <jrandom> 현재 네트워크 현황과 관련해 이야기할 것 있나요? 15:39 <KBlup> I2P를 오래 돌리면 클라이언트 실패가 심하게 급증하는 스파이크를 봤어요... 1) 항목에 맞는 얘긴지 모르겠지만 15:39 <jrandom> KBlup: 그게 CPU 부하나 대역폭 소모와 상관이 있나요? 15:40 <KBlup> 결과적으로 msg-delay> 10000ms :-/ 15:40 <jrandom> 아, 그게 _PRE net을 개발하는 이유 중 하나일 가능성이 큽니다 :) 15:40 <KBlup> 그러다 새 tunnel을 만들려고 시도하다가 계속 실패해서, 때로는 300개 이상의 작업이 쌓이는 것 같아요... 15:41 <KBlup> 제 머신은 꽤 강한데도 그걸로 과부하가 걸려요... 15:41 <jrandom> 맞아요, 그 부분은 0.6.1.10을 준비하면서 전반적으로 손봤어요, 준비될 때까지 조금만 기다려주세요 15:43 <jrandom> 좋아요, 1)에 더 있을까요, 아니면 2) _PRE net 진행 상황으로 슬슬 넘어갈까요 15:43 <+Complication> 0.6.1.10에는 확실히 상당한 변경이 들어간 것 같네요 15:45 <jrandom> 네, 내용이 상당히 많습니다. 현재로서는 새로운 생성 코드가 들어가 있고 제대로 동작하는 것 같지만, 이 기회에 하부 이슈들을 더 디버깅하고 있어요 15:46 <+Complication> 사전에 CPU 시간을 많이 써야 한다고 하셨죠 15:47 <+Complication> 이 비용이 이제 어떤 종류의 tunnel을 구성하는 것과도 연관되나요? 15:48 <+Complication> (즉, 구성 전에 짧은 동안 무거운 암호 연산을 한 묶음 수행해야 한다는 뜻인가요) 15:48 <jrandom> 네, 모든 tunnel 생성 요청은 k개의 무거운 암호 연산을 수행해야 합니다(k = 생성 중인 tunnel의 hop(중간 경유 노드) 수) 15:49 <+Complication> 제가 묻고 싶었던 건... 간격만 전보다 더 촘촘해진 건가요, 아니면 양도 더 늘어난 건가요? 15:50 <jrandom> 양은 더 많아지고, 더 적어지고, 더 촘촘해졌습니다. 더 촘촘해졌다는 건 전부를 사전에 한꺼번에 수행한다는 뜻이고, 더 많아졌다는 건 앞선 hop이 거부하더라도 해당 hop의 암호화를 건너뛰는 식으로 지름길을 쓸 수 없게 되었기 때문이며, 더 적어졌다는 건 앞선 hop들이 실패하는 일이 훨씬 줄어들었기 때문입니다 15:51 <jrandom> 게다가 이전 릴리스와 달리 이제 tunnel 요청에는 ElGamal/AES+SessionTag를 더 이상 사용하지 않고, (상당히) 순수한 ElGamal을 사용합니다 15:52 <+Complication> ...그리고 최종적으로 성공할 세트를 알지 못하면 사전 계산은 불가능한 거죠? 15:52 <jrandom> 즉, 예전에는 비대칭 연산 없이도 요령을 부릴 수 있었지만, 이제는 그렇게 요령을 부리지 않습니다(그 자체가 한 부류의 공격을 노출시켰기 때문이에요) 15:53 <+Complication> (피어 집합) 15:53 <jrandom> 음, 요청할 tunnel의 피어가 누구일지 안다면 분명히 사전 계산할 수는 있겠죠 15:54 <jrandom> 새로운 tunnel 생성 과정은 별도 스레드에서 돌기 때문에, 부하 시 메인 작업 큐를 질식시키지 않고 스스로 속도를 더 잘 제어할 수 있습니다 15:54 <+Complication> 또, 이용 가능한 정보에 변화가 없다면 시도가 실패할 때 누구에게 요청할지 몇 명 정도는 미리 알 수 있다고 가정할 수 있나요? 15:54 <jrandom> 흠, 말씀을 완전히 이해하진 못하겠네요 15:55 <+Complication> 아니면 그 구조를 처음부터 다시 만들어야 하니, 그들을 알아도 소용없나요? 15:56 <+Complication> (즉, 최소한 ElGamal 암호화를 처음부터 다시 해야 한다는 의미로요) 15:56 <jrandom> 아, 구조는 http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 에 있습니다 15:56 <jrandom> 그러니, 맞아요. 다음 hop이 바뀌면 ElGamal을 다시 해야 합니다 15:56 <jrandom> (사전 계산한다면) 15:56 <+Complication> 그렇군요, 바로 확신이 서진 않았습니다 15:57 <+Complication> 지금은 이해했습니다 15:57 <jrandom> 반면에, 우리는 생성 성공률을 진짜로 끌어올리려 하고 있고, 새 생성 프로세스는 불필요한 생성을 최소화하도록 적응할 수 있을 겁니다 15:58 <+Complication> 실제로는 어떻게 보이나요? 15:58 <jrandom> (아, 그 구조는 _PRE 브랜치에서 약간 수정되었습니다: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ) 15:59 <+Complication> ElGamal 암호화가 훨씬 빨라졌다는 세부사항을 봤어요... 15:59 <jrandom> 음, 생성 성공률은 라이브 네트워크보다 훨씬 훨씬 높지만, 그건 _PRE net의 규모가 작기 때문일 수도 있어요 16:00 <jrandom> 네, 예를 들어 2 hop 구조를 만드는 데 1120회 수행 기준 평균 44ms가 걸리고, 라이브 네트워크의 ElGamal 암호화 시간은 1344회 수행 기준 542ms였습니다 16:02 <jrandom> (같은 박스에서) 16:02 <+Complication> 542ms에는 실패 시 재시도까지 포함되나요, 아니면 순수한 생성만인가요? 16:02 <+Complication> 순수 생성만이라면, 턱이 빠졌네요... 어디 바닥 어딘가에 있을 겁니다. :P 16:02 <KBlup> 그 지수 변경과 관련해서: 익명성에는 어느 정도로 영향을 주나요? 16:02 <jrandom> 아니요, 그건 순수 ElGamal 통계입니다. 라이브 네트워크는 새 _PRE net 구조를 생성하지 않으니까요 16:04 <jrandom> KBlup: 익명성? 영향 없습니다. 보안성? 제가 읽은 바에 따르면 228비트면 2048비트 ElGamal에 상응하기에 충분합니다 16:04 * Complication은 ElGamal의 x와 y에 대해선 잘 모릅니다 16:04 <+Complication> 의미 있게 논평할 만큼 알진 못해요 16:06 <+Complication> 진지한 연구자들이 더 짧은 x도 충분히 어렵다고 보고, 암호 전문가들도 비명을 지르며 도망치지 않았다면... 16:06 <@cervantes> 그뿐만 아니라, 1024/160으로 낮추는 것의 함의도 있죠 16:07 <KBlup> 논문을 나중에 읽어봐야겠네요 ;) 16:07 <+Complication> cervantes: 네, 분명 그보다는 낫습니다 16:08 <+Complication> 게다가, 이 암호가 막아야 하는 가장 주요한 공격은 무엇이며, 그 공격이 유효한 기간은 얼마나 되나요? 16:09 <+Complication> 빨리 깨냈을 때만 이득이 있는 유형인가요, 아니면 언젠가 결국 깨도 이득이 있나요? 16:11 <+Complication> 제가 제대로 이해했다면, 이게 즉각적으로 보호하는 비밀은 다음 tunnel 참여자죠? 16:11 <+Complication> (정확히는 다다음 참여자) 16:11 <@modulus> 회의 진행 중? 16:11 <+Complication> (이는 바로 다음 참여자만 알 수 있음) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> 현실적인(그러나 엄청나게 강력한) 적대자라면, tunnel 수명 안에 이를 깨야만 의미가 있습니다. tunnel 수명 이후에 깨는 건, 모든 네트워크 트래픽을 기록해 두고 모든 tunnel을 깨는 경우에만 도움이 됩니다(즉, 일시적인 전송 계층 암호를 깬 다음 tunnel 계층 암호를 공략하는 경우) 16:11 <jrandom> 그러니 여기서 말하는 건 수십 년이 아니라 분 단위입니다 16:12 <jrandom> (그래서 1024비트도 아마 과한 수준일 겁니다) 16:12 <@cervantes> 그 위험을 의미 있게 측정할 방법이 있나요? 16:13 <+Complication> 게다가 hop이 더 많은 tunnel이라면, 적은 여러 개를 깨야 하죠? 16:13 <+Complication> (물론 구축자도 여러 개를 만들어야 하지만요) 16:13 <@cervantes> 1024비트 이상이 필요 없다면, 더 쓸 필요가 정말 있을까요? 16:14 <@cervantes> 양자 컴퓨터가 훨씬 강력해질 3년 뒤엔 언제든 더 강한 알고리즘으로 바꿀 수 있잖아요 16:14 <@modulus> jrandom: 적이 hh:mm에 중요한 것이 tunnel을 통해 전송될 걸 안다면, 로깅으로 어떻게든 깨낼 가능성이 있을까요? 16:14 <jrandom> Complication: 맞아요, 여러 개를 깨야 합니다(그리고 전송 계층을 보호하는 DH 키도요) 16:14 <@modulus> 제가 아는 한 1024비트는 큰 계산 자원이면 깨는(break()) 게 가능합니다 16:15 <jrandom> 엄청난 자원과 10년쯤의 시간 16:15 <jrandom> (혹은 30년) 16:15 <@cervantes> jrandom: 더 약한 암호를 시험해 보는 게 어렵나요? 16:15 <@modulus> 1024비트 합성수는 요즘 몇 달이면 인수분해 가능하다는 인식이었는데요. 16:15 <@cervantes> pre net에 배포해보고 16:15 <@cervantes> 실제로 이점이 큰지 볼 수 있을까요 16:16 <@cervantes> modulus: 맞지만, 여러 개를 깨야 하죠 16:16 <@modulus> 이게 이산 로그 영역 기반이고 그런 거라면 전 아는 게 없네요 16:16 <@modulus> cervantes: 아하 16:16 <jrandom> cervantes: 현재 512byte 슬롯을 사용하므로 많은 구조를 바꿔야 합니다. 다만 테스트용으로는 앞 256바이트를 0x00으로 채워 넣는 방식도 가능하겠네요 16:17 <jrandom> modulus: ElGamal은 이산 로그에 기반합니다 16:17 <@cervantes> jrandom: 시험해 볼 가치가 있을까요? 16:17 <@modulus> 맞아요 맞아요, 전 RSA를 떠올리고 있었네요 16:17 <@cervantes> 아니면 다른 것에 집중하고 필요하면 나중에 돌아오는 게 나을까요 16:18 <jrandom> 시험해 볼 가치는 확실히 있어요. 다만 지금은 전송 계층 평가를 좀 해치우고 있습니다 16:18 <+Complication> 현실에서 그 계산을 어떻게 감당할 수 있는지에 달린 문제 같네요 16:18 <jrandom> (그리고 지금으로서는 44ms 암호화 시간도 충분하지만, 4ms면 더 좋겠죠 :) 16:19 <+Complication> 현재 컴퓨터에서도 잘 버틴다면, 새 머신에서는 더 나아질 거예요 16:19 <@modulus> 특히 암호 하드웨어가 나오기 시작했듯 더 보급되면요 16:19 <jrandom> 물론 이 파라미터를 가볍게 혹은 즉시 바꾸진 않을 겁니다. 다만 피해야 할 충분한 이유가 있다면 알려 주세요 16:21 <jrandom> modulus: 전용 AES와 RSA 칩은 들어봤지만 DH/ElGamal용은 못 들었어요. 반면, NSA 등처럼 자체 제작이 가능한 적을 상정하면 가능하긴 하죠 16:22 <@cervantes> 그들은 링에 스프링클을 뿌린 도넛 기술로 만든 암호 머신을 가지고 있죠 16:23 * Complication은 스프링클 도넛의 파고를 막을 수만 있다면 Celeron 300을 Athlon 600으로 업그레이드할 의향이 있습니다 :D 16:23 <tethra> heheh 16:24 <jrandom> 음~ 도넛 16:25 <jrandom> 좋아요, 2) _PRE net 진행 상황에 대해 더 있을까요? 16:25 <jrandom> 없다면, 3) I2Phex 0.1.1.37로 넘어가죠 16:26 <jrandom> Complication: 요점 좀 알려줄래요? 16:26 <+Complication> 음, 작동은 하는 것 같습니다. :) 16:26 <+Complication> 추가 중복성을 위해 곧 더 많은 웹 캐시를 확보할 수 있을 것 같아요. 16:27 <jrandom> 좋죠 16:27 <jrandom> 흠, 웹 캐시가 더 필요할까요? 하나만 살아 있어도 되는 거 아닌가요? 많다고 나쁠 건 없지만요 16:27 <+Complication> (legion이 첫 시도 때 붙잡혔던 미스터리를 풀어내면요) 16:27 <+Complication> 수수께끼 같은 버그도 하나 있는데, 심하게 물어뜯진 않고, 찾는 중입니다. 16:28 <+Complication> 하나만 살아 있어도 충분합니다 16:28 <+Complication> 더 많으면 그중 하나가 살아 있을 확률이 올라갈 뿐이죠 16:28 <jrandom> 좋네요 16:28 <+Complication> 현재 단계에선 웹 캐시를 나쁘다고 판단해 버리는 일은 없을 겁니다. 너무 적거든요. 16:29 <+Complication> (그 루틴은 10개 이상 있을 때만 활성화됩니다) 16:29 <+Complication> (제 기억이 맞다면요) 16:29 <+Complication> 버그에 관해서는: 장시간 동작 후 웹 캐시 서브시스템이 가끔 멈춥니다 16:30 <+Complication> 아마 httpclient의 GET 요청을 정상적으로 중단하지 못해서인 듯해요 16:31 <@modulus> 그럼 가끔 죽여줘야 하나요? 16:31 <+Complication> 안전하고, 새로 합류한 머신에는 문제를 일으키지 않는 듯합니다 16:31 <jrandom> 흠, 기능적으로는 무슨 뜻이죠? 한동안 지나면 웹 캐시에 등록을 멈춰서, 새로 오는 사람들이 그들에게 대한 참조를 받지 못한다는 건가요? 16:31 <+Complication> 그게 네트워크에 잘 통합된 머신에 발생하더라도, 그 머신은 이미 연결된 피어들에게서 충분한 피어를 얻을 수 있습니다 16:31 <+Complication> 그래서 현재로선 영향이 거의 0에 가깝습니다 16:31 <@modulus> 좋네요 16:32 <+Complication> 그냥 흥미로운 현상일 뿐이죠 16:32 <@modulus> 언제 실패하는지 등의 규칙성은 없는 건가요? 16:32 <+Complication> modulus: 보통 20시간 이전에는 안 나타납니다 16:33 <+Complication> 그리고 제가 강제로 발생시킬 방법이 없어서, 디버깅이 좀 느립니다 16:33 <@modulus> :_) 16:34 <+Complication> 어쨌든, 찾으면 고치고, 못 찾으면 다른 걸 만지작거리겠죠 :) 16:34 <jrandom> :) 16:34 <jrandom> streaming lib / eepproxy에서 본 몇 가지 버그의 증상일 뿐인 것 같네요. 그래서 그것들을 고치면 이것도 해결될 겁니다 16:35 <+Complication> 그럴 수도 있죠 16:38 <jrandom> 좋아요, 훌륭해요. 수고했어요, Complication 16:38 <jrandom> 3) I2Phex 0.1.1.37에 대해 더 있을까요, 아니면 잡다한 4) ???로 넘어갈까요 16:41 <jrandom> (이미 넘어간 걸로 하죠) 16:41 <jrandom> 좋아요, 회의에서 더 다룰 내용 있나요? 16:42 <tmp> 아니면 영원히 숨을 참으실 건가요? 16:43 <jrandom> 영원히, 영원히요 16:43 * jrandom 마무리 준비 16:43 * jrandom *baf* 하며 회의를 마칩니다