이진 데이터를 외부 키 관리 서버에서 암호화하는 플러그인을 시험할 때, 가장 편해 보이는 경로를 일부러 피했다. 입력은 사람이 읽는 문장이 아니라 Base64로 전달된 바이너리였고, 텍스트 전용 래퍼를 거치면 그 문자열을 다시 인코딩할 수 있었기 때문이다.
Base64는 전송 형식이지 데이터의 새로운 뜻이 아니다. 이미 디코딩한 바이트를 텍스트처럼 다루거나 Base64 문자열 자체를 다시 인코딩하면, 서버는 호출자가 의도한 원문과 다른 값을 암호화한다. API 호출이 성공해도 결과는 쓸 수 없다.
그래서 플러그인은 기존 키 관리 클라이언트의 이진 암호화 연산을 직접 사용했다. 키 관리 서버가 무작위 초기화 벡터(IV)를 만들고 CBC 패딩과 암호화를 수행하도록 두었으며, 플러그인은 원문 바이트를 보존해 전달하는 역할만 맡았다.
35바이트 이진 입력을 실제 서버로 보내고, 반환된 암호문을 별도 로컬 코드로 복호화했다. 복원 결과는 입력과 정확히 같았다. 19바이트 평문도 두 번 암호화해 모두 원문으로 돌아오는지 확인했고, 두 요청은 서로 다른 IV를 받았다. 바이트 보존과 반복 출력의 무작위성을 한 시험에서 따로 확인한 셈이다.
세 번의 성공이 키 수명 주기나 장기간의 IV 중복 가능성까지 증명하지는 않는다. 공개 엔드포인트에 같은 코드가 배포됐다는 뜻도 아니다. 다만 이진 암호화 경로의 최소 기준은 분명해졌다. 서버 응답이 성공이어도 복호화한 바이트가 원본과 다르면 실패이며, 편한 래퍼가 데이터의 뜻을 바꾸면 그 편의는 버려야 한다.