-
암호화 라이브러리 간 차이 때문에 암호화 결과가 달랐던 경우프로그래밍/의문 2018. 11. 12. 22:52반응형
현상
openssl과 닌텐도 crypto 라이브러리의 aes128 cbc로 암호화한 결과가 달랐다
원인
openssl과 닌텐도 crypto와의 차이였다.
openssl은 EVP_EncryptFinal 함수에서 pkcs#7 패딩을 자동으로 삽입해줬으나,
닌텐도의 crypto 라이브러리는 패딩을 삽입해주지 않았다.
해결
닌텐도의 crypto 라이브러리로 암호문을 만들 때, 버퍼의 빈 공간에 pkcs#7 패딩을 직접 만들어주니 암호화 결과가 같았다.
참고
http://manual-archive.blogspot.com/2012/03/pkcs-padding-method_19.html
https://crypto.stackexchange.com/questions/10522/openssl-padding
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption#Padding
++
openssl의 https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption#Padding 의 글을 보니 pkcs#5가 아니라 pkcs#7이 아닌가? 하는 생각이 들었다.
좀 더 확인 후 글을 수정하던가 해야겠다.
++
검색을 해봐도 어떤 곳은 pkcs5, 어떤 곳은 pkcs7 라는 등 얘기가 달라 혼란스러웠으나. 아래와 같은 얘기를 해주신 분이 있었다
pkcs5라고 되어있는 것들은 5를 넣어도 7로 동작한다는 것이며 다른 언어에서의 예 까지 들어줬다.
이 글을 보니 왜 서로 다른 말들이 나왔는지 전반적인 배경까지도 이해가 되더라.
지금까지의 결론
openssl은 pkcs#7 을 기본 패딩으로 적용하며, 많은 라이브러리의 pkcs#5는 대게 pkcs#7로 동작한다.
반응형'프로그래밍 > 의문' 카테고리의 다른 글
CRITICAL_SECTION의 default spin count (0) 2019.04.10 C# Excel Application이 예외 발생 시 종료되지 않는 현상 (0) 2019.03.31 윈도우 openssl OPENSSL_Uplink(00007FFBDEE003D8,08): no OPENSSL_Applink 에러 (0) 2018.11.01 비주얼 스튜디오, utf8로 저장된 문자열 보기 (0) 2018.09.13 enable_shared_from_this를 사용했는데 예외가 발생한 경우 (0) 2018.09.13