암호화시 data의 유효성을 검증하는 방법

암호화시 data의 유효성을 검증하는 방법

암호화가 필요해서 구현을 하였습니다. 그랬더니, 걱정이 생겼습니다. 암호화를 풀고나서 푼값이 원본과 같은지....
그렇다면 md5, crc, 등의 hash 값을 어떻게 넣으면 될까요? 암호를 풀고나서 원본을 점검해야 하는것이니 원본에 대한 hash가 필요하게 됩니다. 이것을 잘못 구현하면 암호화된 text를 공격할때 사용되질 수 있게 되어 보안상 문제가 발생하게 됩니다. 그래서 여러 자료를 찾아 봤는데요. wiki에 정리가 되어있습니다.

https://en.wikipedia.org/wiki/Authenticated_encryption
해당 링크에서 오른쪽 아래 보시며 그림이 있으며, 그림만 봐도 전체적인 흐름을 알 수 있습니다.

Approaches to Authenticated Encryption

Encrypt-then-MAC (EtM)

The plaintext is first encrypted, then a MAC is produced based on the resulting ciphertext. The ciphertext and its MAC are sent together. Used in, e.g., IPsec. The standard method according to ISO/IEC 19772:2009.^[5] This is the only method which can reach the highest definition of security in AE, but this can only be achieved when the MAC used is "Strongly Unforgeable"^[10] In November 2014, TLS and DTLS extension for EtM has been published as RFC 7366. Various EtM ciphersuites exist for SSHv2 as well (e.g. hmac-sha1-etm@openssh.com).

Encrypt-and-MAC (E&M)

A MAC is produced based on the plaintext, and the plaintext is encrypted without the MAC. The plaintext's MAC and the ciphertext are sent together. Used in, e.g., SSH. Even though the E&M approach has not been proved to be strongly unforgeable in itself,^[10] it is possible to apply some minor modifications to SSH to make it strongly unforgeable despite the approach.^{[citation needed]}

MAC-then-Encrypt (MtE) 

A MAC is produced based on the plaintext, then the plaintext and MAC are together encrypted to produce a ciphertext based on both. The ciphertext (containing an encrypted MAC) is sent. Used in, e.g., SSL/TLS. Even though the MtE approach has not been proven to be strongly unforgeable in itself,^[10] the SSL/TLS implementation has been proven to be strongly unforgeable by Krawczyk who showed that SSL/TLS was in fact secure because of the encoding used alongside the MtE mechanism.^{[11][dubious – discuss]} Despite the theoretical security, deeper analysis of SSL/TLS modeled the protection as MAC-then-pad-then-encrypt, i.e. the plaintext is first padded to the block size of the encryption function. Padding errors often result in the detectable errors on the recipient's side, which in turn lead to Padding Oracle attacks, such as Lucky Thirteen.

이때. MAC이라는 개념이 나오게되는데요. MAC은 message를 인증하기 위한 작은 코드라고 합니다.
https://en.wikipedia.org/wiki/Message_authentication_code
https://ko.wikipedia.org/wiki/%EB%A9%94%EC%8B%9C%EC%A7%80_%EC%9D%B8%EC%A6%9D_%EC%BD%94%EB%93%9C

결로적으로 hash를 이용해 MAC을 구하는 방법은 아래 링크를 참고하면 됩니다.
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

MAC은 암호화 할때 사용한 key와 원본 text를 입력으로해 만드는 일종의 hash funtion같은것입니다.
위 링크의 예제를 보면 입력이 key와 원본 text를 이용하면 hash값이 출력됨을 알 수 있습니다.

HMAC_MD5("key", "The quick brown fox jumps over the lazy dog")    = 0x80070713463e7749b90c2dc24911e275
HMAC_SHA1("key", "The quick brown fox jumps over the lazy dog")   = 0xde7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC_SHA256("key", "The quick brown fox jumps over the lazy dog") = 0xf7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8

HMAC에 포함된 예제 : http://swlock.blogspot.com/2017/06/aes-128-example-cbc-mode-with-hash-hmac.html