로그인 회원에게만 열람할수있게 옵션을 만든다거나 그런식의 기능이 들어가면 괜찮을것같다고 봐요. 완벽하게 가리는건 좀 힘들겠네요

로그인 회원뿐이라고 해도 미코가 예전처럼 하꼬 사이트도 아니고 회원수만 몇천은 될텐데(아닌가요..?) 그분들 중에 안 좋은 의도를 가지고 개인정보를 수집하는 분들이 없을거라고 단정할 수 없는 상황에서 오픈하는건 좋은 생각은 아닌 것 같습니당..

전문가라고 하기엔 너무 야매 프로그래머라 ㅈ문가 정도로 하겠슴다

유사컴공도 보기힘든데 컴공은 오늘도 야근에 죽어납니다 히히히힣ㅎㅎ

여기서 사용자의 비밀번호라는 것은 그냥 그 대화에 대해 사용자가 임의로 지정한 비밀번호 라는 뜻 같습니다.

구형 사이트에 로그인 안 하고 댓글 달 때 비밀번호 설정해놓는 것처럼 임의로요.

그렇다 하더라도 상호간에 비밀번호를 알아야된다는건데 비밀번호는 서로 평문으로 주고 받으시겠죠

저도 글을 다시 읽어보았는디 본문의 글이 약간 애매하기는 하네요...

저는 글 스르륵 읽고 Public key/Private key 따로 쓰는 방식이라는 줄 알았는데 자세히 보니 그게 아닌 것 같군요.

아니면 간략하게 설명하시다가 의도적으로 뺀 부분일수도요.

사용자의 비밀번호는 결국 단방향 함수로 돌리지 않으면 복호화가 됩니다. 설령 단방향 함수로 암호화 한다고 해도 그 값으로 키를 똑같이 만들수 있겠죠.

패스워드에 사용하는 해시함수는 결국 어떠한 단어를 지칭하는지 알지 못하게 만들어 버리는 것 뿐입니다. 

제가 이쪽에 능통하지 못해서...

지금 두 분 다 말씀하시는 게

암호화를 단방향 함수로 해서 입력값을 알기 힘들게 만들었다 하더라도

각자가 서로가 보낸 메세지를 각자의 기기에서 복호화(해독)하는 데 필요한 키를 평문으로 보낸다면

서버에 그 키가 남아서

지금과 같이 언제든지 관리자분이 보실 수 있다

라는 하시는 건가요?

음 저도 자세히 모르지만 제가 아는 선에서 대답해드리겠습니당...

암호화를 단방향 함수로 해서 -> 이 부분은 아마 쪽지 내용이겠죠? 아니면 서로간에 키를 받고 암호를 입력하는 그 암호를 말씀하시는 건가요?

일단 쪽지내용은 절대 단방향으로 돌리면 안됩니다. 다시 평문을 볼 수 없기 때문이죠.

암호의 경우는 그 사람이 입력한 비밀번호를 우리가 알 필요가 없기때문에 단방향 함수에 넣고 돌립니다.

회원가입 때 비밀번호로 1234를 입력하면 단방향 함수가 돌아서 qwerty0000로 들어갑니다.

그럼 다음에 로그인 할 때 사용자가 1234를 입력하면 그 값을 다시 해시해서 나온값이 qwerty0000인지 비교해서 일치하면 로그인처리를 해줍니다.

각자가 서로에게 해독하는데 필요한 키를 평문으로 보낸다면 

-> 이 부분은 결국 서버가 배포해주는 키이기 때문이죠. 만약 서버가 아닌 클라이언트에서 생성돼서 서로에게 전달 된다고 해도 그 쪽지를 다시 열람하려면 

웹 특성상 상태가 유지 되는 것이 아니기에 또 같은 키 생성 후 키를 서로 교환해서 일치 했을 때만 쪽지 열람이 되어야겠죠. (비 효율)

그래서 결국 그 키를 서버에 저장하는건데 결국 개발자 또는 관리자 손아귀에 있는건 변함이 없죠....

제가 기술 설명능력이 많이 부족한데 요약해서 적겠습니다 부족하더라도 이해부탁드립니다.

1. 서버에서 공통된 마스터키를 A가 지정한 비밀번호/B가 지정한 비밀번호를 이용해 A의 마스터키/B의 마스터키를 별도로 지정합니다.

공개키-비밀키 형태의 암호화형태를 사용하기에는 메신저처럼 단일 디바이스 혹은 자유롭게 기술이 추가/제거가 가능한 서비스가 아닌 미코라는 서비스의 특성을 감안했기에 어느정도 취약점은 존재하더라도 이런 형태를 생각해냈습니다.

2. 스니핑까지 가면 정말 작정하고 진행하는것이기 때문에 중앙화된 서버에서 메세징을 주고받는 이상 100% 완벽한 해답은 없다고 봅니다.

네 곰곰히 생각해보니 어플리케이션 영역에선 충분히 가능할 것 같습니다.

다만 웹 영역에선 지정된 프로토콜을 통해야 하기때문에 결국 키가 노출될 것 같습니다.

개인키가 중요한데 개인키를 웹에서 발급하는 형태일 것이기 때문입니다.

그리고 유저가 작성하는 평문을 서버로 전송할때는 어찌 전송할까요.

Js로 암호화 한다고 치면.. 결국 JS 가 키를 어딘가에서 받아와야 겠는데요.

브라우저가 일단 공개키던 개인키던 사이트별로 보관하는게 현재 표준에서 되나요?

지금 우리 모두가 생각하는 방식은 결국 외부자가 봤을 때의 보안에 대해서만 이야기 하는 것 같습니다..

가장 많이 발생하는 보안사고가 내부의 인원으로 인해서 정보가 노출되는 경우가 굉장히 흔합니다. 이 내부 인원은 때에 따라서 개인적인 대화를 열람해야 할 수도 있기 때문이죠.

예를들어 대화 중에 발생한 문제로 공권력이 달라고 하면 서버를 줘야하는데 그럼 당연히 복호화 가능하게 해서 줘야겠죠.?

카카오톡도 다 가능하고 대화 내용을 제공 가능 한 것으로 알고 있습니다. 

결론은 내부 인원은 맘만 먹으면 항상 볼 수 있다. 다만 이것을 외부로 노출해서 누군가 알게 되면 그때부터 범죄가 되는 것이죠. 나 혼자 알고 있으면 다른 사람이 모르기에 신고 자체도 안되구요.

관심법으로 마음을 보지 않는한요 ㅋㅋ

암호화 채팅같은 형태로 보셔도 됩니다. 그렇지만 암호키가 지속적으로 바뀌어서 한개의 키가 노출되더라도 지속적으로 변경할경우 쉽게 해석하지 못하는것을 목적으로 종료함을 추가하게 됐습니다.

그냥 기타 사이트들도 쪽지기능 유지하는걸 보면 운영자 양심선언과 법규에 의존하는게 맞아보입니다.

폐쇄가 답인건 너무 1차원 적인 솔루션 이잖아요..?

작성해주신 내용은 웹 암호화시에 고려할 내용들이네요.

참고하겠습니다.

언젠간 웹에서도 구현이 가능한 내용이라고 봅니다..

해당 쪽지를 열람할때마다 키가 필요한데.. 브라우저에 저장이 말이 안되는 거쥬..

pc에서 보던 쪽지가 컴터에서 안열리면... 그런점도 고려해야하구요.

맞습니다. 여러모로 불가능한 솔루션인 듯 합니다

야나두!