|
:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
10/01/08 17:09
예전부터 암호와 관련해 궁금한 점이 있습니다만....
예를들어 파일의 암호를 찾아내는데 1시간이라는 시간이 걸린다고 하면... 그건 1시간 중 어느 시간안에 임의로 풀린다는 건가요? 아니면 무조건 1시간이 걸린다는 건가요? 만약 001~100사이에 002라는 암호를 걸어놓은 경우. 컴퓨터가 암호를 풀 때 001부터 차례대로 시작하면 다음차례에 바로 풀리지 않나요? 예전부터 궁금했는데 컴맹인 고로....
10/01/08 17:13
튼튼한 나무님//
만약 001~100사이에 002라는 암호를 걸어놓은 경우. 컴퓨터가 암호를 풀 때 001부터 차례대로 시작하면 다음차례에 바로 풀리지 않나요? 넵 이 말이 맞습니다~
10/01/08 17:15
튼튼한 나무님// 전수검사를 할때 1시간이라는 이야기겠죠. 말씀대로 처음에 시도한 암호가 우연히 같은 암호일 경우도 있으니.
그러므로 암호 작성시 남들이 흔히 생각할 수 없는 복잡한 암호로 만들라고 권장하는 거죠.
10/01/08 17:15
저도 갑자기 궁금증이 생겨서 대충 구글링을 해봤는데요, ZIP 파일의 경우, AES 알고리즘을 사용해서 암호화를 한다고 하네요.
그렇다면, 사실상 리버스 엔지니어링 등을 통해서 푸는 방법은 없다는 얘기고, Brute-Force(맨땅에 헤딩) 방식밖에 없다는 얘긴데... 길게 글을 써 주셨는데 김 빼서 죄송하지만, 말씀하신 부분은 보안업계의 오랜 이슈입니다. zip 파일 뿐만 아니라, 은행 등에서 사용하는 인증서, 보안이 유지되어야 하는 통신, 방화벽... 등등에서 계속 화제가 되었죠. 슈퍼컴퓨터건 뭐건 간에, 128bit 이상으로 암호화된 문서는 Brute-Force 방식으로는 푸는게 불가능하다는게 정론입니다. 이런 분야에 관심이 많으시다면, "해킹.파괴의 광학" 이라는 책을 권해드립니다. 프로그래밍적인 이슈를 다루고 있어서, 관련 전공이 아니라면 따라가기 좀 힘들지만, 다루고 있는 내용들을, 소설처럼 읽기만 해도 꽤나 흥미진진한 책입니다. 아래는 링크입니다. http://book.naver.com/bookdb/book_detail.nhn?bid=2622381
10/01/08 17:27
workbee님// Gidol님//
그렇군요..역시 보안을 위해선 특문을 넣은 복잡한 암호를 사용해야 하는군요... 이해는 하지만 실천은 어렵네요.
10/01/08 17:41
암호라는게 꼭 맞춰야만 깨지는건 아닙니다. 그외의 방법은 많죠 하이재킹이라던가;;; 수없이 때려넣어서 걸리는 시간으로 계산하는건 컴퓨터 성능측정 밖에 안된다고 봐야죠.
10/01/08 17:50
WizardMo진종님// 그건 그렇네요. 보안이 뚫리는 사건 중 대다수는 보안 알고리즘이 파해되었다기보다는 시스템 자체의 허술함 혹은 사람의 실수 부주의 나태 때문이라고 하니..
10/01/08 18:18
튼튼한 나무님//
001~100사이에 002라는 암호를 걸어놓은 경우는 알고리즘에 따라 다르겠지만 이렇게 될 겁니다. 암호의 자릿수를 모르기 때문에... 0, 1, 2, 3, ..., 9, 00, 01, 02, ..., 99, 000, 001, 002 WizardMo진종님// 압축 파일에 암호를 걸었을 때 그 방법으로 압축을 풀어낼 수 있나요?
10/01/08 18:28
ArcanumToss님// AES 방식으로 압축된 문서를 풀어내는 방법은, 현재까지 알려진 바로는 Brute-Force 밖에 없습니다.
하이재킹이란, 사용자의 입력이나, 네트웍 신호 등을 빼앗아오는 해킹 기법이죠. 사용자의 키보드 로그를 저장한다거나, 네트웍으로 주고받는 데이터를 훔치는 방법 등 말입니다. 즉.. "암호를 만든 사람을 찾아 내서 적당한(?) 방법으로 암호를 알아내는 것"이 하이재킹 되겠습니다. ^^;
10/01/08 19:35
AhnGoon님//
오~ 그렇군요. 그렇다면 압축 파일을 만들 때 독한 맘 품고 300글자 짜리 암호를 만들면 죽었다 깨어나도 절대 못 깨는 거군요.
10/01/08 20:51
ArcanumToss님// 300글자짜리를 만들어봐야, 어차피 AES에서 Key로 쓰는건 최대 256 bit(32 byte) 입니다.
그러니까, 결국 32글자 이상의 암호는 별 의미 없긴 합니다. 그래도 2^256 은 엄청난 숫자죠. 암호 Key는, 자신이 입력한 그대로 넣는 것이 아니라, 해시를 이용해서 한번 Encoding 합니다. 그러나, Key는 Encoding만 가능하지, Decoding이 불가능합니다. 즉, Key를 알았다고, 원래의 암호를 알아내는건 아니죠.
10/01/08 20:54
Zakk Wylde님// 네~ 복잡하고 긴게 능사는 아닙니다.
하지만 긴 암호를 만들고 싶으면 자신만이 알고 있는 자작시를 이용하면 만든 사람이 못 풀 확률이 좀 줄어 듭니다. :) 그리고 프로그래밍적인 암호의 접근은 어렵다 하시는 분들은 사이먼 싱이 지은 코드북이란 책을 추천드려요~ 암호의 인문사회학적인 접근이라고나 할까요.
10/01/08 21:50
ArcanumToss님// 의미 없는 300글짜 자리를 외우실수 있을까요? 어딘가에 적어놓거나 메모해놓거나 타이핑을 하거나 하겠죠. 그걸 가져가는게 하이재킹 입니다. 이미 암호화와는 관계가 없습니다. 보안이 더 중요하죠. 제일 좋은건 의미없는 긴~ 암호인데 이건 못외우니까 어딘가에 따로 보관해두게 됩니다. 그걸 슥삭 하는거죠. 오히려 이쪽이 훨씬 쉬우면서 대부분의 해킹을 의미합니다. 락을 깨는건 문을 박격포로 부시고 들어가는겁니다;;; 열쇠를 훔치거나 문근처에서 숨어있다가 따라 들어가거나 하는방법을 택하죠;;
10/01/09 00:17
리버스엔지니어링을 이용한 사례가 없다면 키의 값을 무차별 적으로 대입해서 암호문을 복호화시켜야되는데, 과연 당신이 데커라면 언제풀릴지 모를 암호화된 파일을 풀것인가?
아님 암호화된 압축을 한 사용자컴퓨터의 키로거나 패킷 스니핑을 이용하여 사용자의 다른 아이디와 비밀번호를 알아내서 참고, 추론하여 디코딩하는게 빠를것인가? 결국은 기술적인 문제보다 안일한 보안의식에 인해서 더 많이 발생한다고 보는 1인입니다.
10/01/09 18:27
피날레님// 실제로도 그렇고, 대부분의 전문가들이 그 부분을 지적하더군요.
RSA와 AES의 등장 이후, 양자컴퓨터가 나오기 전 까지는, 암호화된 문서를 기술적인 방법으로 풀어낼 방법은 존재하지 않는다는게 정설이고, 언제나 문제가 생기는건 보안 담당자의 실수 내지는 부주의가 원인이니까요.
|
||||||||||