첫걸음암호를 쓰기 전에 무엇을 감추고 무엇을 확인할지 정한다

당신이 친구에게 과제 파일을 보낸다고 해 보겠습니다. 중간에서 파일을 보는 사람이 내용을 읽지 못하게 하고 싶습니다. 받는 친구는 파일이 바뀌지 않았는지, 정말 당신이 보낸 것인지도 알고 싶습니다. 서로 가까운 요구처럼 보이지만 같은 작업은 아닙니다. 내용을 감추는 기밀성, 변경을 알아내는 무결성, 정해진 상대와 연결하는 인증을 먼저 나누어야 알맞은 암호 기술을 고를 수 있습니다. 암호화만 했다는 이유로 이 세 가지가 모두 해결되었다고 생각하면 이후 설계가 흔들립니다.

컴퓨터는 글자나 그림을 바이트의 열로 다룹니다. 바이트는 8개의 비트이며, 비트 하나는 0 또는 1입니다. 암호화 전의 바이트 열을 평문, 암호화 후의 바이트 열을 암호문이라고 합니다. 암호 알고리즘은 변환 규칙이고 키는 그 규칙의 동작을 결정하는 값입니다. 같은 알고리즘도 키가 다르면 다른 결과를 만들도록 설계합니다. 받는 쪽은 정해진 복호화 절차와 적절한 키로 평문을 되찾습니다. 글자를 알아보기 어려운 형태로 바꾸는 인코딩과 달리, 암호화에는 누가 되돌릴 수 있는지를 제한하는 비밀이 있습니다.

예를 들어 Base64는 바이트를 문자로 표현하는 약속입니다. 약속을 알면 누구든 되돌리므로 비밀 보호가 아닙니다. 파일을 압축하는 것도 용량을 줄이는 일입니다. 암호화된 파일은 압축이나 인코딩을 함께 사용할 수 있지만 각 변환의 역할은 다릅니다. 또한 암호문이 짧은 문장처럼 보이지 않는다는 관찰만으로 안전한 암호라고 판정할 수 없습니다. 겉모양의 복잡함보다 공격자가 가진 정보로 비밀을 알아낼 수 있는지가 기준입니다.

안전한 설계는 알고리즘의 구조가 공개되어도 키가 없으면 풀기 어렵다는 가정 위에 섭니다. 알고리즘 자체를 숨기는 데 의존하면 프로그램 유출이나 분석 한 번으로 보호가 무너질 수 있습니다. 이 관점을 흔히 케르크호프스의 원칙이라고 부릅니다. 공개된 표준과 검증된 구현을 사용하는 이유도 여러 사람이 같은 구조를 오래 검토할 수 있기 때문입니다. 다만 표준 이름이 붙었다고 키 생성, 저장, 오류 처리까지 저절로 안전해지지는 않습니다.

키 길이가 n비트이면 가능한 비트 배열은 2ⁿ개입니다. 그렇지만 128비트 공간에서 키를 고른다고 말하면서 실제로는 생일 여덟 자리로 키를 만들면 공격자는 생일 후보만 살펴보면 됩니다. 필요한 것은 길이와 함께 예측하기 어려운 선택입니다. 보안용 난수 생성기는 운영체제가 모은 엔트로피를 바탕으로 이런 값을 제공합니다. 시각이나 사용자 이름을 이어 붙인 값, 일반 시뮬레이션용 난수를 암호 키 대신 쓰지 않습니다. 운영체제의 난수 API와 암호 라이브러리의 키 생성 기능을 사용하는 이유입니다.

공격자가 무엇을 알고 있는가

암호를 평가할 때는 공격자에게 주어진 정보를 구분합니다. 암호문만 얻는 경우, 특정 평문과 그 암호문 쌍을 이미 아는 경우, 원하는 평문을 암호화해 달라고 요청할 수 있는 경우가 다릅니다. 각각 암호문 단독 공격, 알려진 평문 공격, 선택 평문 공격이라고 합니다. 복호화 장치에 일부 암호문을 넣고 결과나 오류 차이를 관찰할 수 있다면 선택 암호문 공격을 고려해야 합니다. 이름보다 “공격자가 어떤 질문을 장치에 할 수 있는가”를 읽는 편이 이해하기 쉽습니다. 정상 서비스가 제공하는 기능 자체가 그 질문 통로가 될 수 있습니다.

참고　[122] · [123]