암호화와 비밀번호 보호: Protect와 Unlock이 실제로 하는 일

사람들은 “PDF에 비밀번호 걸기”와 “PDF 암호화”를 서로 다른 제품인 것처럼 말합니다. PDF 형식에서 둘은 같은 계열의 메커니즘입니다. 파일이 /Encrypt 딕셔너리를 들고 있고, 뷰어는 페이지 내용을 평문으로 내주기 전에 비밀번호(또는 그에 준하는 자격 증명)를 요구합니다.

“비밀번호 보호”의 실제 의미

보호된 PDF는 한 앱의 UI 잠금에 그치지 않습니다. 표준을 따르는 리더는 올바른 열기 비밀번호가 들어오기 전까지 문서 열기를 거부합니다. 즉 파일 내용에 대한 암호화이고, 복호화에 비밀번호가 필요하도록 키가 잡혀 있습니다.

비밀번호 설정(POST /api/v1/security/add-password)는 직접 고른 비밀번호를 받아, 열 때 그 비밀번호를 묻는 암호화 파일을 반환합니다. 포털 폼은 비밀번호 필드 하나를 요구합니다. 서버는 qpdf(--encrypt)로 암호화하면서 그 값을 사용자(열기) 비밀번호로 씁니다. API에 별도의 소유자 비밀번호를 주지 않으면 같은 문자열이 소유자 역할에도 쓰입니다. 기본 키 길이는 256비트입니다. 처리가 끝나면 도구는 비밀번호를 저장하지 않습니다. 잃어버리면 결과 파일은 잠긴 채로 남습니다.

사용자 비밀번호와 소유자 비밀번호

PDF 암호화는 역사적으로 두 역할을 구분합니다.

• 사용자(열기) 비밀번호: 문서를 열고 보려면 반드시 필요합니다.
• 소유자(권한) 비밀번호: 인쇄나 수정 제한을 걸면서도 사용자 비밀번호로 파일을 열게 해 주는 데 흔히 씁니다(파일을 어떻게 만들었는지에 따라 빈 열기 비밀번호를 쓰기도 합니다).

이것들은 형식의 개념이지 마케팅 라벨이 아닙니다. 일상적인 “이 PDF 잠그기” 워크플로는 대개 열기 비밀번호만 겁니다. 열기를 막지 않으면서 인쇄나 편집을 제한하는 것은 소유자 역할을 쓰는 권한 이야기이고, “파일이 안 열린다”와 혼동하기 쉽습니다.

PDF123에서 Protect 폼은 비밀번호 하나를 받고, 그것을 파일을 보는 데 필요한 열기 비밀번호로 취급합니다. Unlock은 복호화에 그 같은 비밀번호를 알아야 합니다. 고급 API 호출자는 add-password에 ownerPassword, keyLength, canPrint, canModify를 넘길 수 있습니다. 브라우저 폼은 그 손잡이들을 노출하지 않습니다.

Unlock이 하는 일과 하지 않는 일

비밀번호 해제(POST /api/v1/security/remove-password)는 올바른 현재 비밀번호를 주면 기존 비밀번호 암호화를 벗겨 냅니다. 페이지와 글꼴, 배치는 그대로이고 암호화 요구만 사라집니다.

잊어버린 비밀번호를 복구하거나 추측하거나 크래킹하지 않습니다. 비밀번호를 이미 알지 못한다면 Unlock이 만들어 내지 않습니다. Repair도 암호화를 제거하지 않습니다. 문서 정보가 Encrypted: true를 보고하면 먼저 잠금을 풀고 그다음 편집하세요.

언제 무엇을 쓰는가

Protect와 Unlock 모두 카탈로그 경로에서 계정 없이 서버에서 실행됩니다. 암호화는 파일을 줄이지 않습니다. PDF 압축는 별개의 스트림 재압축 작업이며, 잠금이 풀린(또는 한 번도 암호화되지 않은) PDF가 필요합니다. OCR과 표 추출, 대부분의 편집 op도 마찬가지로 평문 접근이 먼저 필요합니다. 아는 비밀번호로 Unlock한 뒤 다른 도구를 돌리세요.

비밀번호는 PDF 밖에 보관하세요(비밀번호 관리자, 시크릿 저장소). 열기 비밀번호를 첨부 파일과 같은 메일에 넣으면 보호가 무력해집니다. 같은 작업을 HTTP로 하려면 개발자를 보세요.