Crypto Project : 1-6. crypto library makefile과 테스트

시작하며

---

  원래 이전 글에서 라이브러리의 구현에 대한 모든 설명이 끝났기 때문에, 이를 활용한 소켓 프로그램을 바로 작성하려고 했었다. 그런데 그전에 애초에 샘플코드까지 제작했는데 이를 이용해서 어떤 식으로 암호화가 진행되는지 결과라도 보여주는 것이 좋을 것 같다 간단하게 글을 쓰려고 한다. 또 makefile을 어떻게 활용하고 어떻게 쓰는지도 보여주는게 좋을 것 같아 간단하게 설명을 적어보려 한다. 

 

1. libICrypto.so

---

  위 캡쳐는 i_crypto_library/src 에 들어있는 makefile이다. 이 파일은 같은 디렉토리에 위치하는 i_crypto.c로 libICrypto.so 공유라이브러리를 만든다. 이 때, include에 있는 i_crypto.h 헤더파일을 연결하여 오브젝트 파일을 생성한다. openssl을 사용하기 위해 -lssl, -lcrypto를 작성하여 최종적으로 lib디렉토리에 libICrypto.so를 생성한다. 명령어를 보면, make 명령어를 수행하면 자동으로 소스를 빌드해 라이브러리를 생성한다. make clean 명령어를 수행하면, src 디렉토리에 생성되는 i_crypto.o 오브젝트 파일을 자동을 삭제해준다. 만약 소스코드를 수정하여 다시 빌드해야 할 경우, 단순히 make명령어만 치면 빌드 및 라이브러리 생성을 자동으로 해준다. 리눅스는 빌드할 때마다 쳐야 할 명령어가 많고, 이를 코드를 작성할 때 수시로 입력하기 번거롭기 때문에 이런 식으로 makefile을 작성하면 코드 빌드 및 테스트를 효율적으로 할 수 있다. 

 

2. 샘플 코드

---

  위 사진은 i_crypto_library/sample에 있는 makefile이다. sample 디렉토리에는 이 크립토 라이브러리에 있는 함수들을 어떻게 쓰는지, 그리고 함수를 실행하면 어떤 식으로 결과가 나오는지를 라이브러리 사용자가 보다 쉽게 알 수 있도록 작성한 샘플 코드가 들어있다. 이 샘플코드는 make 명령어를 치면 최종적으로 실행파일을 만든다. make clean은 오브젝트 파일과 실행 파일을 모두 자동으로 삭제한다. make test 명령어는 만들어진 실행파일을 실행하는 역할을 한다. 사용자는 make명령어로 실행파일을 자동으로 만든 후 make test로 결과를 확인하고, 결과를 모두 확인했으면 make clean으로 실행 파일과 오브젝트 파일을 지우면된다. 즉 개발한 사람 뿐만 아니라 사용자에 대한 배려로, 사용자는 이 라이브러리의 샘플 코드를 실행해보기 위해 여러 귀찮은 일들을 감행하지 않고, 개발자가 제공하는 makefile로 손쉽게 결과를 확인할 수 있는 것이다. 다음 아래는 이 라이브러리를 이용한 샘플 코드의 결과이다.(make후 make test를 실행했을 때)

  먼저 origin sample 부분은 기존 openssl에서 제공하는 cbc함수의 암복호화 결과를 보여주는 부분이다(샘플은 ctr은 생략하고, cbc결과만 출력). 실제 사용하는 암호알고리즘과 키가 같다면, 내가 작성한 cbc 암호화와 openssl 기존 cbc암호화의 결과는 동일해야 한다. 그렇기 때문에 먼저 기존 openssl에서 제공하는 함수의 결과를 먼저 보여준다. origin sample을 보면, "test text samplesample text test a" 라는 33바이트 데이터를 암호화하고 복호화한다. 그 후 i_enc결과가 나오는데, 암호화 결과를 보면 상위 32바이트는 동일하게 암호화 값이 나오지만 마지막 16바이트는 다른 것을 볼 수 있다. 이는 내가 작성한 코드는 pkcs7방식 패딩이지만 openssl은 남은 자리에 0x00을 채우는 제로 패딩 방식으로, 패딩 방식이 달라 32바이트까지 동일하고 패딩이 붙는 마지막 16바이트가 암호화 결과가 달라진 것이다. 암호화가 잘된것은 패딩이 붙기전까지의 데이터가 기존 openssl 암호화화 동일한 것을 비교하여 알 수 있다. 이후 i_dec를 호출하면 원래의 데이터가 출력되는 것을 볼 수 있다. origin sample은 복호화했을 경우 패딩제거를 하지 않아 뒤에 15바이트 0x00이 그대로 출력되지만(출력으로는.....으로 출력되는 부분) 내가 만든 dec는 패딩처리가 되므로 뒤에 패딩 데이터를 출력하지 않고 원본 데이터를 원래의 크기에 맞게 출력하는 것을 알 수 있다. 

 

  위에는 단순한 enc, dec가 아닌 init, update, final함수에 대한 샘플코드이다. 데이터를 몇바이트씩 업데이트 하는지 중요하기 때문에 init_update_final_sample 코드는 직접 코드를 보며 설명하겠다. 위와 똑같은 33바이트 데이터를 사용하는데, 처음에는 3바이트만을 업데이트한다. 3바이트만 업데이트했다면, 암호화가 진행되지 않고 ctx구조체의 buffer에 3바이트 데이터를 그대로 저장하고 있다.(이 원리에 대해 이해가 안가면 이전 글 중에 init, update, final 부분을 보고 오시면 됩니다.) 즉 업데이트는 16바이트 이상이 되어야 암호화를 진행하므로 암호화가 되지 않는다. 이 후 업데이트에는 13바이트를 업데이트하여, 최종적으로 앞 3바이트, 후 13바이트가 합쳐져 16바이트가 되어 패딩을 하므로 암호화된 결과가 출력함수에 출력될것이다. 마지막 업데이트에는 17바이트를 업데이트한다. 그러면 16바이트는 암호화되고 마지막 1바이트는 암호화되지 않고 버퍼에 남게된다. 이제 모든 데이터를 업데이트했으므로 최종적으로 final 함수를 호출하면, 버퍼에 있는 1바이트에 15바이트 패딩을 더해 최종적으로 암호화를 마무리한다. 위 update함수 파라미터에 몇바이트씩 데이터를 업데이트 하는지 보면서 설명을 읽으면 쉽게 이해될 것이다. dec 업데이트 파이널도 똑같이 매개변수 사이즈가 얼마만큼 들어가는지 확인하면 원리는 똑같다. 결과를 보자. 

중간에 init, update, final 샘플코드에 대한 결과가 나온다. 처음 enc update는 3바이트만 업데이트 했으므로 암호화가 되지 않아 암호문이 출력되지 않는다. 그다음 업데이트로 13바이트를 업데이트 했으므로 3바이트와 더해 16바이트가 완성돼 암호화가 진행돼 16바이트 암호문을 출력, 그다음 업데이트는 17바이트를 업데이트 했으므로, 16바이트는 암호화, 남은 1바이트는 암호화되지 않으므로, 총 32바이트 암호문만 출력된다. 마지막 파이널을 하면 남은 1바이트에 패딩 15바이트를 더해 암호화가 진행되므로 최종적으로 48바이트 암호문이 완성된다. dec에 대한 업데이트도 이런식으로 흘러간다.

 

마치며

---

  샘플코드로 라이브러리를 사용했을 때 결과를 확인해보았다. 실제 i_crypto_sample.c 코드를 보면 라이브러리의 인터페이스들을 어떻게 사용하는지 쉽게 알아볼 수 있을 것이다. 앞선 글에서 설명한 doxygen문서와 같이 보면 누구나 충분히 함수를 사용할 수 있다. 여기에 더해 makefile이 얼마나 중요한지 필요성, 그리고 어떤식으로 작성해야 하느지 팁들을 얻어갔으면 좋겠다. 이제 정말 라이브러리에 대한 설명이 끝났고, 다음 글에서 이 라이브러리를 이용한 소켓프로그램에 대해 소개하겠다.

 

github : https://github.com/0xGh-st/I_CRYPTO.git

GitHub - 0xGh-st/I_CRYPTO