가끔 암호화/복호화와 관련해서
뭣도 모르고 무턱대고 덤벼들다가 역시나 뭣도 모르는 그 무지(無知) 때문에 낭패를 보는 사람들도 많고,
나 역시도 나름 십여 년간에 걸쳐 이리저리 만들어보기도 하고 컨버전해보기도 하는 등 많이 경험해봤지만
세월에 따라 추가됐거나 변한 내용들도 있고, 대충 따라만 하다보니 정리가 잘 안되거나 헛갈리는 내용들도 간혹 있어
이참에 깔끔하게 정리를 시도해본다. 정리가 과연 될랑가 모르겠지만. ^^;
암호화/복호화는 보안 문제 때문에 쓴다. 당연히.
보통 휴대폰번호나 주민번호 같은 민감한 개인정보를 저장할 때 많이 쓰고
그런 정보들을 인터넷으로 웹 브라우저 쿠키에 저장할 때도 많이 쓴다.
또 많이 쓰이는 데는 인증서를 이용한 암호화다.
우리가 흔히 알고 있기로 인증서를 이용하니까 비대칭키(RSA 등) 암호화 아니냐 하지만
인증서의 비대칭키 알고리즘(개인키/공개키를 이용한)으로는 대칭키 알고리즘의 "키"를 암호화하는 용도로만 쓰고
실제 메시지 암호화에는 대칭키 알고리즘을 쓴다. (대한민국 공인인증에서는 SEED라는 대칭키 알고리즘을 사용한다.)
이유는 속도 때문이다. 비대칭키 암호화로 긴~~~ 메시지 본문을 암호화하기엔 터무니없는 시간이 걸릴 테니까.
(*주: "Algorithm"은 "알고리듬", "알고리즘" 등 다양한 한글 표현으로 많이 사용되고 있고,
실제 보안/암호화 관련 전문가들은 "듬"이라 쓰는 걸 선호하는 듯 하기도 한데,
나는 편의상, 그리고 일반적으로 시중에서 제일 많이 사용되는 "알고리즘"이란 용어로 쓰겠다.
외래어 표기 규칙으로도 "즘"이 맞기도 하고... 실제 어원도 "Al-Khowarizmi"라는 사람 이름이라
"듬"보다는 "즘" 발음이 더 어원에도 가까우니까. 또 "Algorithm" 뿐만 아니라 "Algorism"으로도 쓰니까.)
개요는 이쯤하고 본론으로 들어가자면,
DES, TripleDES(= 3DES = DES-EDE), SEED, AES 등의 대칭키 암호화 알고리즘으로 암호화/복호화 프로그램을 만들 때 항상 걸리적거리는 것으로 "모드(mode)"와 "패딩(padding)"이라는 것이 있다. 아, 하나 더 있다. 간혹 필요없는 경우도 있긴 하지만 대부분의 mode에서 사용되는 "IV(초기화 벡터)" 역시 마찬가지.
이것들을 제대로 이해하려면 PKCS#5와 PKCS#7에 대해 나름 이해를 하고 있어야 한다.
>>참조: PKCS: Public Key Cryptography Standards
위 위키 문서를 보면 필요한 모든 내용을 알 수 있으니 굳이 더 이상 이야기할 필요는 없겠다. 끝.
...
이렇게 끝내면 거창한 서론에 비해 너무 무성의한 결론인가?
그럼 조금만 더 친절하게... ^^;
1. 패딩(Padding)
먼저,
PKCS#5와 PKCS#7은 패딩(padding)에 관련된 표준이라는 사실을 알아두고 시작하는 것이 좋겠다.
("패딩"은 데이터를 특정 크기로 맞추기 위해 그 크기보다 부족한 부분을 뭔가로 채워넣는 작업을 가리키는 일반 용어다.)
PKCS#5는 "Password-based Encryption Standard"라고 명명되어 있다. 패스워드 기반 암호화 표준. 사실은 이 말 속에 거의 모든 의미가 다 들어있다. 현대 공인인증 방식은 이 PKCS#5 표준에 따라 개인 패스워드를 그 근간으로 하고 있다. 즉, 패스워드로 표현할 수 있는 키를 사용하는 암호화 표준이라는 것.
패스워드란 우리가 보통 알고 있듯 영문, 숫자, 특수문자를 포함해서 키보드 상에서 [input type="password"] 형식으로 쓸 수 있는 모든 문자를 말한다. 넓은 의미로는 1 바이트로 표현 가능한 모든 문자, 즉 ASCII 코드로는 0~255 (이진수로 00000000부터 11111111까지)에 해당된다. (그러나 앞 부분의 컨트롤 문자와 뒷부분의 확장 문자 코드를 빼면 32~126 사이의 문자 코드만 해당된다.) 이걸 이진수로 표현하면 최대 8자리의 숫자로 표현되기 때문에 8진 문자열(Octet string) 이라고도 표현한다.
즉,
"1 바이트 = 1 octet"
이 되는 것이다. 이 8진 문자열을 사용하는 것에 대한 표준이 바로 PKCS#5이다.
>>참조: PKCS#5 - Password-based Encryption Standard (rfc 2898 문서)
위 참조 문서를 보면 엄청 복잡하게 설명이 많~~이 되어있다. 그러나 우리에게 필요한 것은 PKCS#5의 역사나 유래나 상세 알고리즘 구조 같은 것이 아니다. 실제로 어떻게 써먹을 수 있는지가 중요할 뿐. 그러니 전체를 다 알 필요는 없다.
위 참조 문서의 6.1.1 부분에 그 핵심 내용이 들어있다.
바로, 패딩(padding)이다. 8바이트 기준 패딩. 이것이 PKCS#5의 핵심이다. 즉, 평문의 길이가 8바이트의 배수를 기준으로 모자라는 수 만큼의 숫자를 채워서 8바이트의 배수로 길이를 맞추는 작업에 대한 얘기다.
여기서 착각하는 사람들이 간혹 있는데, 이 패딩은 무조건, 반드시, 항상 발생해야 한다는 것을 잊어버리고 8바이트보다 작은 경우에만 적용하는 실수를 하는 경우가 있다. 그러면 안된다. 8바이트의 배수인 경우에도 패딩은 무조건 해야 한다. 위 문서의 6.1.1 부분에도 명시되어 있지만 한글로 더 잘 설명된 내용이 있어 링크 하나 더 걸어본다.
> 참고: http://manual-archive.blogspot.kr/2012/03/pkcs-padding-method_19.html
같은 내용이지만 하나 더 예제까지 아예 포함된 사이트 링크를 하나 더 투척한다.
더 이상은 이 문제로 혼동을 일으키지 않기를 바란다.
다음,
이 PKCS#5는 DES, TripleDES 등 8바이트 블럭 암호화 기반 기존 알고리즘들에 잘 적용되었던 표준이다. 그런데 이후 128비트(16바이트) 이상의 블럭 암호화 알고리즘들이 속속 발표되면서 이 패딩 방식에 대한 표준도 확장이 필요하게 되었다. 그래서 나온 것이 PKCS#7 이다.
>> 참조: PKCS#7 - Cryptographic Message Syntax Standard (rfc 2315)
역시 위 문서를 보면 장황하게 이러저러한 설명들이 엄청 많이 되어 있는데,
핵심 내용은 10.3 부분에 있다.
즉, 암호화 블럭 크기가 k바이트인 경우 k바이트보다 작거나 같은 경우 패딩을 적용하라는 것이다. AES의 경우 16바이트 암호화 블럭이 사용되는 알고리즘이므로 16바이트 패딩이 적용된다.
2. 모드(Mode) / IV(초기화 벡터; Initialization Vector)
다음으로 모드(mode).
모드는 간단히 얘기하자면, 블럭 암호화 순서 및 규칙에 대한 표준이다.
모드에 대한 설명은 구구절절 할 필요도 없고, 사실 할 능력도 없다. 다음 링크에 중요한 내용이 다 나와 있으니 참조하면 된다.
조금 복잡하고 어려워보이긴 해도 알고자 하는 노력에 더해 시간만 조금 들이면 그리 어렵지 않게 정리할 수 있을 것이다.
>> 참조: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
위 링크에 자세히 나와 있긴 하지만,
일반적으로 가장 많이 쓰이는 CBC(Cipher-Block Chaining) 모드에 대해 간단히 반복 설명하자면,
최초 평문 1블럭과 IV(초기화 벡터)를 XOR 연산한 다음 암호화하고,
다음 평문 1블럭은 앞에서 암호화된 결과 블럭과 XOR 연산하여 다시 암호화한다.
이 과정을 끝까지 반복하는 것이 CBC 모드이다.
(평문 마지막 블럭은 패딩된 블럭이다.)
IV를 사용하지 않고, 즉 XOR 연산 없이 각 블럭을 암호화만 하는 모드인 ECB 모드에 비해 훨씬 더 강력한 암호화 기법이 되겠다.
끝.
'Tech: > 일반·기타' 카테고리의 다른 글
아트릭스 CM9, CM10.1 KT 문자 수신 오류 픽스 (2) | 2013.06.07 |
---|---|
"읽기 전용" 디스크 복구: DISKPART (0) | 2013.05.30 |
안드로이드에서 070 전화 걸고 받기 (0) | 2013.03.20 |
안드로이드 스마트폰을 서버로 활용 (0) | 2013.02.25 |
안드로이드 ICS, JB에서 삼성 TTS 사용하기 (0) | 2013.02.20 |