|
:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
14/10/14 15:54
다 잠재적으로 가지고 있어서 업계 전체와 회동하겠다 뭐 그런 어필도 하긴 했죠. 그 점에서 카톡이 억울하긴 억울할 겁니다. 국적으로 인한 한계가 드러난 거라... 그러니까 외국계 메신저로 다같이 망명가야 합니다. 그 정도는 해야 나라가 바뀌죠. 근데 안할거니까 흠... 뭐 다 그렇게 살게 되겠죠.
14/10/14 16:01
근데 아마 초창기 수많은 메신져들이 경쟁하는 상황에서, 저런식으로 보안체계를 만든 회사들은 다 낙오했을 겁니다.
한국 사회가 절대적으로 조그마한 비용에 민감하고 조금의 불편조차 원하지 않는데. 그것까지 감안해서 만들 여유가 있는 회사가 몇 군대나 있을지... 물론 지금의 카톡은 충분히 거대해졌고 자본력도 받쳐주니 보안에 대해 준비 못 했다고 비판은 할 수 있다고 봅니다.
14/10/14 16:05
첫 문단의 경우, 대화내용을 서버에 저장하지 않으면 '좋다'고 말할 수는 있겠지만, 그걸 원칙이라고 말할 수는 없죠. 법적으로 대화내용은 (저장하면 안될) 개인정보에 해당하지 않습니다. 그리고 질게 글에서도 답변했던 내용이지만 대화내용 저장은 실제로 사용자 편의에 구체적인 효용이 있습니다.
보안채팅 시장까지 선점해.. 라고 하셨는데 그런 시장은 유의미하게 존재하지 않습니다. 이제와서 이슈가 되었을 뿐, 종단 암호화 및 서버 데이터 말소에 대한 소비자의 수요는 그 전에는 거의 존재하지 않았다고 봐도 과언이 아닙니다. 내리신 결론도 엉뚱합니다. 1. 사용성을 저해하고 비용이 든다는 이유로 db를 완전 암호화 하지 않은 건, 있는 그대로의 사실입니다. 고객이 납득할 수 없는 이유란 건 이제서야 나온 말이고, 그 이전의 고객들은 충분히 납득해 왔습니다. 2. 카톡과 같은 방식을 보안이 취약하다고 표현하는 건 잘못된 표현입니다. 열쇠에 열리는 문이 열쇠에 열린다고 보안에 취약하다고 말한다면, 보안이란 단어를 오용하는 거죠. 검열로부터 자유롭지 않다는 사실을 사전에 고지 하지 않은점? 검열로부터 자유로운 서비스란게 한국에 어딨고, 언제부터 그런걸 사전에 고지했죠? 3. 거부를 하면 더 좋았을 수 있을겁니다. 하지만 거부하지 않았다는 것이 잘못이란 것은 합법의 테두리를 넘어선 자의적인 판단이고, 하물며 고객정보를 자산으로 취급했기 때문에 나올 수 있는 행동도 아닙니다. 어차피 문 닫을리도 없지만, 충분히 억울한 일입니다.
14/10/14 16:07
서버 저장 이슈는 개인정보 보호는 아닐지언정, 통신보호의 대상은 됩니다. 물론 인터넷 상의 개인정보 드립은 잘못된 것입니다만 카톡과 정부가 이 문제에 대해서 책임이 없다고 볼 수가 없습니다. 특히 카톡이요. 국적에 의한 억울함은 있을 수 있지만 침해당한 입장에서 그걸 감수해줄 이유가 딱히 없습니다.
14/10/14 16:20
서버 저장 그 자체는 잘못이 아닙니다만, '서버 저장을 하지 않음'으로 피해나갈 수도 있지 않았느냐는 비판은 충분히 유효합니다. 적어도 후행적 감시에 대해서는 효과가 있습니다. 아예 카톡이 앞으로 상시 패킷 관리를 받는다면 그때는 이슈가 달라집니다만, 현재 이슈에서 기본적인 비판점은 '개인의 통신정보에 대한 임의 검열' 문제고 이에 대해서 미리 생각해볼 수 있는 대응책으로 '서버 미저장'을 거론하는 것은 문제가 없습니다. 고로 서버 저장 그 자체가 잘못이 없다는 말씀은 옳습니다만, 주된 비판점과는 거리가 있는 이야기입니다.
14/10/14 16:19
보안채팅에 대한 수요가 가시적으로 없는 거나 마찬가지였다는 거에는 동의합니다. 사실 시장은 만들기 나름이라고 생각하기 때문에 정보보안 이슈가 일반인들에게도 강하게 인지되고 있는 현 시점에서 '보안 채팅'이라는 키워드를 선점해서 시장을 리딩했다면 시장지배자적 입장에 있는 카톡이 어느 정도 새로운 시장을 만들어낼 수 있지 않았을까 하는 생각 때문에 적어 본거에요.
1. 그 이전 고객들이 충분히 납득했다기 보다는 그런 개념 자체가 없었다는 게 더 맞을 것 같습니다. 서비스 약관이나 소개에서 그런 취약점에 대해 서비스 주체가 설명한 내역도 사실 없구요. 2. 개인의 암호화키 (패스워드 등)을 보관하거나 유출하지 않게 하는 사회공학적인 영역의 보안은 사용자의 몫인 것이 맞지만 플랫폼 자체의 취약점에 기인하여 발생하는 보안 문제는 서비스 주체가 책임 지는 게 맞다고 봅니다. 플랫폼에 잠재적인 문제점이 있다면 사전에 고지 하던지 그런 문제가 발생했을 때의 Use case를 고객이 인지하게 하는 것이 리스크 관리에 도움이 되겠죠. 3. 거부는 안해도 됩니다. 거부할 방법도 없죠. 하지만 그렇게 티나게 서버를 뒤져서 검찰에 필요 정보를 제공하는 행위는 사실 빼도 박도 못할 일입니다. 물론 이건 검찰측 얘기라 사실이 아니라는 얘기도 있어서 조심스럽지만 백업 서버 제공 정도가 아니라 서버 데이터 탐색후 필요 데이터 취합 제공... 이런 식으로 진행된거라면 문제가 크다고 생각합니다.
14/10/14 16:05
글 잘 읽었습니다. 대한민국의 IT업체들은 덕분에 글로벌한 서비스를 하는데 큰 제약을 얻게 됐습니다. 조금 된 이야기지만 IDC를 국내에 넣어볼까 고민하던(전기값이 싸서) 어떤 회사도 결국 계획을 취소하기도 했구요. 이유는 언제든 털러 나올수 있는데 내가 미쳤어? 라는 농담반진담반의 이야기가 있지요. 한국은 IT관련 서비스의 실험에는 좋은 나라이나 법인 넣어놓고 사업하기엔 좋은지 모르겠는 나라입니다..
중간에 말씀하신 종단간 암호화방식은 현재 트렌드에 맞지 않는 묘한 불편함을 가져오게 하는 역설적인 점이 존재합니다. 현재 트렌드는 N스크린부터 시작해서, 클라우드까지 내가 하던걸 그대로 다른 곳에서도 그대로 이어서 혹은 편하게 접근할 수 있어야 한다라는 점인데 종단간 암호화는 결국 한개의 기기와 한개의 기기만 받을 수 있도록 만들어야 하기 때문에 애매한 상황이 생깁니다. 카카오톡 PC가 존재하는것 역시 종단간, 아니 개인간 암호화를 실시하면 쓸모가 떨어질 수 있습니다. 일반 채팅이야 상관없겠지만.. 뭐 저보다 유능하신 분들이니 뭔가 대안과 깰만한 새로운 방법들을 만들어낼 수 있지 않을까 생각하구요... 추가적인 이슈들도 있습니다. ISP(KT, T-Broad, U+등)에서는 패킷 검출을 위한 장비들에 상당한 투자를 진행했고, 이 결과물로 종량제 인터넷 혹은 패킷 모니터링을 통한 소수의 다량이용자 검출.... 그리고 가장 있어서는 안될거라고 생각하는 그것(실시간 감청)까지도 가능할 수 있을듯 하나. 아직은 확실하게 이렇다 하는건 없습니다. 아래글에서의 GPS를 이용한 네비게이션과 관련한 부분들도 있구요... 카카오의 경우 이번 건과 관련해서 글을 써보려고 하면서 두 개의 사건(국정원의 홍씨 카카오톡 관련 정보 제공 / 정진우 부대표 검찰측이 요청한 카카오톡 관련 정보 제공)이 하나로 묘하게 합쳐진듯 이야기가 흘러가는 부분에서 혼동도 됐었고, 그 외에도 좀 찾아볼게 있어 검색을 해보니 중간중간 보안에 문제가 있던 부분들이 있었는데 조금씩이나마 개선이 됐던 것으로 보입니다. 기술적으로 패킷모니터링만으로는 어떤 대화를 하는지 찾아내는데는 좀 어렵도록 점차 개선이 된것 같긴 합니다만. 모든 일의 출발지인 서버쪽 데이터에는 별도의 뭔가를 수행하지 않았다는 것이 놀랍기는 했는데, 과연 이 글을 보는 아니 관련 뉴스를 보신 분들이 과연 완벽하게 다른쪽 생태계(ex, 텔레그램)으로 이주할 수 있을지는 의문입니다. 어쩌다보니 mntalk를 좀 쓰다가, 카카오는 약관 개정논란이 있던 2010년 10월 이후로 작년 9월까지 안쓰고 잘도 버텼습니다만, 게임 관련으로 결국 쓰게 됐음에도 쉽게 다른곳으로 갈아타기가 어려운 상황인데.. 지속적으로 쓰시던 분들이 다른 메신저 서비스로 옮긴다라.. 이용자의 대규모 쏠림현상이 한번 더 생기기는 쉬워보이지 않습니다. 물론 다음카카오가 계속적으로 사고를 친다면 가능해 보이기도 합니다.
14/10/14 16:15
저는 DB 암호화(+공개 키 알고리즘)를 강제하면 서비스 capability는 떨어질 수밖에 없다고 보기 때문에 그게 강제되는 건 반대합니다.
예를 들어 구글 행아웃은 대놓고 모든 메시지를 무기한으로 저장하고 있고, 공개 키 암호화도 하고 있지 않습니다. 때문에 지메일의 경우에는 수사 목적으로 정부에 자료를 넘긴 적도 있습니다. (아동 섬범죄자였던 걸로 기억) 하지만 이렇게 개인 정보를 바친 대가로 얻는 것도 있죠. 저에게는 대화 기록 검색이 가능하다는 게 가장 큽니다. 핸드폰을 교체하거나 잃어버려도 친구랑 1년 전에 나눈 대화를 조회해 볼 수 있기 때문입니다. 가끔 재미난 글감을 발굴해서 게시판에 올릴 때도 있고요. 이런 장점은 핸드폰 주소록을 구글에 바친 대가로 핸드폰을 분실하더라도 연락처를 날릴 염려가 없게 된 것과 비슷합니다. 저는 털털한 사람이라서 지금까지 두 번이나 주소록을 날렸었거든요... 서버에서 데이터를 소거하는 방향으로 나아가면 이런 서비스도 불가능하겠죠. 결국 [클라우드 서비스] 자체가 개인 정보를 서버에 저장하는 걸 가정하고 만들어지는 겁니다. 클라우드 자체를 이용 안 할 거면 모를까, 사람들이 클라우드의 편의성에 중독(?)되는 상황에서는 본문과 같은 보안 조치의 강제는 받아들이기 힘듭니다. 비단 개발자 입장에서만이 아니라, 소비사 입장에서도 저렇게 되면 무척 불편해질 것 같습니다. 당장 카카오톡은 이번 사건으로 관련 클라우드 서비스를 개발하는 데 타격이 갈 거라고밖에 생각할 수 없습니다. (예를 들어 웹 버전 카카오톡이라든지...) ps: 그러고 보니 본문과 같은 보안 조치 강제가 이루어진다면 웹 메일 쓰기도 상당히 불편해질 겁니다. 단순히 로그인해서 메일을 볼 수 있는 게 아니라, 별도의 채널로 브라우저에 개인 키를 저장한 다음에 열어야 할 테니 말입니다.
14/10/14 16:19
사실 메일도 POP3로 쓰고, 바로바로 삭제하고 개인의 컴퓨터에서 저장하는 방식......이라고 하면 서버상에 실제적으로 남는 데이터는 없을테고, 보내고 받을때 그 데이터를 일부러 사본으로 저장하지 않는 이상 정보제공이 매우 어려워질 수 있을거라고 생각해봅니다.
14/10/14 16:20
그게 불편해서 웹 메일이 나온 거니까요... POP3 쓰던 시절 오프라인 메일 클라이언트의 묘한 매력(-o-;;)이 있긴 했습니다만, 관리도 어렵고 해서 다시 돌아가라면 돌아가고 싶지 않군요. (웹 메일 나왔어도 몇 년 간은 POP3를 열심히 썼었는데... 게을러져서... ㅠㅠ)
웹 메일과 POP3의 관계를 구글 행아웃과 텔레그램(혹은 비밀 대화?)의 관계로 생각해 볼 수 있겠군요. 무언가 얻는 게 있다면, 잃는 것도 있는 법이죠.
14/10/14 16:22
결국엔 한곳에서만 쓸거냐 아니냐의 문제 때문에 웹메일이 더 흥하게 된건데(사용하기도 쉬웠고), 보안을 생각한다면 불편해도 저게 또 답이죠.. 여러모로 재밌는 세상입니다 크크크..
14/10/14 16:25
보안성과 사용성 두마리 토끼를 완벽히 잡을 수 있는 서비스가 나온다면 만사 오케이겠지만 과도기적인 상황에서는 결국 자신의 컨텐츠나 개인정보가 제3자에 의해 열람되거나 유출될 수 있는 불안정성이 있다는 것을 일반 사용자들이 인지할 수 있어야 한다고 생각합니다. 전 지금까지의 IT 서비스 사용자들이 이런 개념을 인지하고 클라우드 서비스나 인스턴스 메신저를 사용하지 않았다고 보는 입장이거든요.
두마리 토끼를 잡는 기술을 서비스 주체에게 강제하기 보다는 법적으로 이러한 현 시점의 제약 사항을 고객들에게 고지하는 것을 강제하는 것이 더 현실적이겠죠. 이제 개인의 영역을 디지털 공간으로 확장하는 행위는 정말 리스크가 크다는 것을 전 국민이 좀 알수 있어야 한다고 생각합니다.
14/10/14 19:02
저도 동의합니다.
얼마전까지의 카톡만 해도, 핸드폰이나 PC 등 한 쪽 기기에서 열람한 내용은 며칠 후면 서버에서 사라져버려서 다른 디바이스에서는 열람할 수가 없었죠. 개인적으로는 그것만으로도 굉장한 불편함을 느꼈는데, 분위기가 오히려 이걸 더 줄이는 쪽으로 가버리니 사용자 입장에서는 썩 유쾌하진 않습니다. 좀 더 개인적인 생각을 덧붙이자면, 사용자들이 자신의 정보가 이미 공개적이라는 사실(말씀하신것처럼 서버에 저장된다거나, 영장을 통해 열람 가능해진다는 사실)을 모르다가 이제서야 깨닫게 된건데 하필 그 본보기로 걸린게 카카오톡이라서 뭇매를 맞는다는 생각을 지울 순 없네요. 카톡이 대응 과정에서 실수한 점들도 꽤 있지만 여러모로 안타깝긴 합니다.
14/10/14 19:14
저도 카카오톡이 옛날 폰에만 깔려 있는데 가끔 충전하는 걸 깜빡 해서 1주일 넘게 배터리 방전되면 메시지를 날리곤 했습니다. 그런데 이제는 3일 제한이니 더 불편해져서 안타깝군요. 애초에 다음-카카오가 그런 식의 해결책을 제시하면 안 되는 거였습니다. 이런 문제는 신뢰 회복이나 새로운 기술 도입(비밀 대화라든지...)으로 풀어야지 단순히 1주일을 3일로 줄이는 건 문제 해결은 커녕 여론을 변화시키는 데에도 아무런 도움이 안 된다고 보거든요.
솔직히 말해서 저는 사람들 반응이 참 의아한 게... 그럼 여태 클라우드 서비스가 뭐라고 생각한 걸까요... 그나마 이번 사건으로 클라우드의 실체를 사람들이 잘 파악하게 되면 다행이겠지만, 지금 여론으로 봐서는 그냥 카카오톡 때리기로 끝날 것 같아 씁쓸하군요.
14/10/14 16:22
다대다 환경에서 암복호화는 복잡하지도, 복잡할 것도 없습니다.
갑자기 뜬금없이 이슈가 되고 있는 공개키 암호화 알고리즘은, 아래와 같은 방식으로 암호화/복호화가 이루어집니다. 1. 키는 2개가 있습니다. (공개키/비밀키) 2. 공개키로 암호화 한 것은 비밀키로만 풀 수 있고, 비밀키로 암호화 한 것은 공개키로만 풀 수 있습니다. 3. 공개키는 널리 알리고, 비밀키는 나만 가지고 있습니다. 초창기 인터넷에서, 공개키는 자신의 신원을 증명하기 위한 용도로도 사용되었었습니다. 즉 대외적으로 내 공개키가 이것이다라고 계속 알리고(게시판에 글을 쓰거나 할 때 시그니쳐로 달아놓습니다.) 메일을 보내거나 할 때는 비밀키로 암호화해서 보냅니다. 이를 통해 메일을 받는 사람은 공개키로 이것을 풀어봄으로써 이것이 조작되지 않은, 원저자에게서 온 메일이라는 것을 확신할 수 있습니다. 반대로 이사람에게 메일을 보낼때는 공개키로 암호화 해서 대상만 볼 수 있도록 했었구요. 메일 주소는 얼마든지 수정 가능하기 때문에, 보낸 사람을 확신하기 위해서 이런 방법을 사용하고는 했죠. 다대다 채팅에서는 아래와 같은 방법으로 메시지를 전체 암호화 합니다. 1. 방에 입장할 때, 자신의 공개키를 모두에게 알리고, 다른 사람들의 공개키를 받아서 저장합니다. 2. 메시지를 보낼 때 단일키로 메시지를 암호화하고, 메시지 헤더에 사용자들의 공개키로 해당 단일키를 암호화한 내용 들을 추가하여 메시지 서버로 보냅니다. 3. 메시지를 받은 사람은 메시지 헤더에서 단일키를 복호화하여, 그것으로 메시지 내용을 복호화 합니다. 이 경우, 클라이언트와 중계 서버간의 패킷량은 늘어나지만 (공개키로 암호화 한 단일키 길이 * (방에 있는 사람수 - 1)), 크게 걱정할 수준은 아닙니다. 기술적으로도 그닥 어렵지는 않구요. 대체 이게 왜 빠른 시일내에 구현이 안되는지 전 정말 모르겠습니다.
14/10/14 16:25
이 부분에서 궁금한게 상대와 제가 각각 PC / 모바일 카카오톡을 이용합니다.
그러면 보내고 받아야 할 곳이 총 3군데(자기 포함하면 4군데)가 되는데 이런 경우에는 어떻게 처리를 할것이며, 만약 PC를 공용에서 쓴다거나 하는 경우의 다른 예외처리도 쉽게 해결이 될것 같지는 않은데요. 확정적인 4명이 모바일로만 단체 대화를 한다면 크게 예외적 상황이 안나올것 같지만요;;
14/10/14 16:30
같은 문제는 공인인증서에서도 발생합니다. 동일한 공인인증서를 여러 PC/모바일에서 사용하니까요.
그리고 각 은행은 공인인증서 전송 기능을 통해 이것을 해결하는데, 같은 방법으로 해결 가능합니다. 모바일을 본진이라고 했을 때, PC에 설치할 때 아이디 비밀번호와 핸드폰 인증을 받고, 이때 잠시 비밀키 이동 서비스를 제공합니다. 비밀키 이동서비스는 1. PC에서 랜덤하게 단일키를 하나 생성 후 화면에 보여줍니다. (seed 값만 생성하면 되니까 6자리 숫자정도면 됩니다.) 2. 모바일에서 이 단일키를 입력하면, 이 단일키로 암호화된 비밀키가 카톡 서버를 통해 PC로 전송됩니다. 카톡 서버는 양심적으로 이 데이터를 전송만하고, 저장하지 않습니다. (뭐 저장해도 문제가 되지는 않긴 합니다만...) 3. PC에서는 암호화된 비밀키를 랜덤하게 생성했던 단일키로 복호화하여 저장합니다. 4. 모바일/PC 양쪽에 내 비밀키가 모두 존재하게 되므로, 통신에 문제가 없습니다.
14/10/14 16:32
공용 PC의 경우는, private chat을 할 수 없도록 하면 됩니다.....(비밀키 저장때문에 이건 답이 없어요. 캐리어 가야 해요.)
14/10/14 18:42
오 재미있는 이야기네요. 다대다일때 궁금한게 있는데
그럼 톡방 초기화시(handshake?) 임의의 일반키를 만들고 다른 이의 공개키로 암호화해서 한번만 전송해놓으면 된다는거죠? 그 이후부터는 나는 일반키로 압축을 해서 보내고 다른 이들은 내가 보내준 일반키로 복호화를 하구요 그럼 톡방마다 일반키가 생겨나겠군요. 맞나요?
14/10/14 18:52
매 톡방마다 해도 상관없고, 매 톡마다 해도 상관없습니다. 대충 예상되는 bandwidth 등에 따라 맞춰서 하면 됩니다. 톡방마다 만들어서 handshake하는게 패킷량은 더 적어지긴 할텐데, 일반키 하나가 오래 유지되는 단점도 있고 해서요. 주기적으로 갱신하는 방법도 있겠죠. 톡방을 오래 유지하는게 요즘 추세다보니, 한시간마다 갱신한다거나 하는 식으로요.
14/10/14 19:02
메시지마다 달고 가는거 생각보다 오버헤드가 클 수도 있을 것 같구요. 클라이언트에서야 별 차이가 없겠지만 서버 사이드에서는 당장 메세지의 몇 배가 되는 데이터를 받게 되는지라..
그러면 다대다 멀티 디바이스의 경우는 일반키 처리는 어떻게 되는건가요? 말씀하신대로 모바일에서 일반키가 방마다 갱신되거나 시간별로 갱신된다면 갱신될때마다 다른 디바이스(예를 들면 PC)에서 받아야 하는건가요?
14/10/14 21:11
음. 이쯤되면 구현 상세라;; 뭔가 일을 하는 것 같은 기분이 듭니다만, 시간별로 무조건 갱신이 아니라 마지막으로 갱신한지 n시간이 지난 후 메시지를 보낼때 갱신을 기준으로 삼는다면 멀티 디바이스 중 하나에서 메시지를 보낼때 갱신할 거고, 다른 디바이스에서는 보낸 일반키를 기준으로 다시 암호화 해서 보내고 하는 식이 되겠죠. 키 갱신에 대한 건 메시지 서버에서 컨트롤이 가능할 거구요.
14/10/14 22:17
오버헤드 안큽니다. 요즘 장비는 암복호화 하드웨어 박아서 나와요. 스마트폰도 여러분이 모르는 사이에 전용 암복호화 하드웨어가 SIMD 형식으로 박혀 나오고 있습니다. 이미 보급됐어요.
그냥 그 부분만 어셈으로 SIMD 쓰게 구현하면 cost는 아주 적어집니다. 속도때문에 구현 못할 속성의 작업은 전혀 아니예요. 말씀하신 모델을 약간 수정하자면 초기 공개키 모델로 챗방 참가자들에게 대칭키를 주고 타임 인터벌마다 대칭키를 업데이트 시켜주면 코스트 거의 없이 엔드투엔드 암호화가 됩니다. 공개키는 하드웨어 써도 오버헤드가 약간 있긴 해서 보통은 대칭키 배포용으로 쓰고요. 대칭키는 코스트가 거의 없지요. 아무튼 챗방 엔드투엔드는 기술적으로 전혀 문제될게 없습니다. 카톡이 이걸 내년까지 미루는건 귀찮아서, 게을러서, 하기싫어서 지금 이 상황만 어떻게든 넘겨나 보자는거겠죠. 아무튼 참 정이 안가는 기업이예요.
14/10/14 22:32
그렇군요. MagnaDea 님이 해주신 설명대로라면 메세지마다 암호화된 대칭키를 달고 가야해서 코스트가 제법 들거라고 생각했었거든요. 톡방에 스무명이면 메세지마다 대칭키를 공개키로 암호화 작업 20번에 + 메세지를 대칭키로 암호화 하는 작업이 들어갈테니까요. 사실 서버단에서 까볼 이유가 없으니(없겠죠? 다른 단말로 전송만 하면 되니) 서버쪽의 암복호화 하드웨어는 별로 의미가 없을 것 같고 암호화된 대칭키 스무개가 들어갈테니 메세지에 오버헤드가 있을거라고 생각했습니다. 구형의 스마트폰에서도 암복화 하드웨어가 내장되어 있나요? 그렇다면 진작에 고려해볼만한데 말이죠...
14/10/14 23:28
갤럭시S도 하드웨어가 들어가 있습니다. 우리나라에서 판매된 핸드폰 중 팬택의 이자르와 그 변형 모델 정도만 아니라면 하드웨어는 다 들어가 있을겁니다. 아마도 텔레그램이 하드웨어를 쓸텐데, 실험삼아 텔레그램 사용해 보세요. 엔드투엔드 암호화해도 텔레그램 속도만큼은 나옵니다. 개인적으로 텔레그램이 라인보다 더 빠르게 느껴지더군요.
그리고 대칭키는 암복호화 코스트가 워낙 적어서 텍스트 몇백바이트 암호화정도야 그냥 소프트웨어로도 순삭합니다. 요즘엔 웹페이지 전체를 SSL로 암호화시켜도 장비가 버텨주는 세상이라(그 말은 SSL적용된 사이트 보는 핸드폰도 그걸 다 풀어서 본다는 뜻), 대칭키로 겨우 몇백바이트 텍스트 암복호화 하거나 몇십메가 이미지 암복호화 하는건 CPU 입장에선 하품나오는 작업입니다.
14/10/14 19:20
허공에 대화내용만 서버에 들어가는 것도 아니고 최소한으0 식별을 위해 전화번호나 아이디가 같이 DB에 들어가 있을텐데
이런 DB를 암호화하지 않았다는게 이상하네요. 개인정보보호법이 강화되면서 일정 가입자 이상은 개인정보가 포함된 DB에 대하여 전부 암호화 해야 하는 거 아니었나요?
14/10/14 22:15
엔드 투 엔드 암호화로 멀티 디바이스나 단톡방 만드는거 기술적으로 어려울 것 하나 없습니다. 돈 주시면 제가 만들어 드리죠.
카톡은 엔드 투 엔드 암호화를 내년도까지 모든 대화에 적용하겠다고 하는데, 이건 (그간 보여줬던 모습과 판박이처럼)카톡이 얼마나 게으른지 잘 보여주는겁니다. 일을 할 의지가 없어요 카톡은. 그게 아니라면 개선할 의지 자체가 없다거나죠. 일단 지금의 비만 피하자는 마인드. 게으른 기업 카카오. 카카오를 대표할 수 있는 단어는 게으름이 가장 적격일겁니다.
14/10/15 11:48
그 돈 받으시면 저랑 반띵하고 공동 작업 어떠십니까. 흐흐...
정말 아무리 생각해도, 모든 대화에 적용하고 내부 테스트 완전히 끝내고 나가는데까지 일정 두달이면 떡을 칠 것 같은데 안하는 걸 보면 의지가 없다. 혹은 게으르다 말고는 없어보여요.
|
||||||||||