어떤 키 또는 해시 도구가 필요한가
| 할 일 | 도구 |
|---|---|
| 인증서 읽기: 이름, 만료일, 지문 | 인증서 디코더 |
| CA에 보내기 전에 CSR 확인 | CSR 디코더 |
| 텍스트 PEM과 바이너리 DER 사이 변환 | PEM을 DER로, DER를 PEM으로 |
| SSH 공개 키의 지문 확인 또는 변환 | SSH 키 지문 |
| 텍스트나 파일의 SHA-256을 hex와 Base64로 | SHA-256을 Base64로 |
| Content-MD5와 레거시 체크섬 | MD5를 Base64로 |
| 웹훅이나 API 요청 서명 | HMAC 생성기 |
스크립트나 스타일시트용 integrity="sha384-…" | SRI 해시 생성기 |
| 원하는 길이의 랜덤 Base64 문자열 | 랜덤 Base64 생성기 |
Laravel APP_KEY, AES 키, JWT와 HMAC 시크릿 | Base64 키 생성기 |
| 콘텐츠 보안 정책용 nonce | CSP nonce 생성기 |
| 비밀번호로 텍스트 암호화 또는 복호화 | AES 암호화, AES 복호화 |
Base64와 암호학이 만나는 곳
PEM은 -----BEGIN …----- 줄 사이에 DER로 인코딩된 ASN.1을 Base64로 담은 것입니다. 인증서, CSR, 공개 키와 개인 키가 모두 이 형식을 씁니다. Base64 DER는 대부분의 인증서와 RSA 키에서 MII, EC P-256 공개 키에서 MFkw, Ed25519 공개 키에서 MCowBQYDK2Vw로 시작하므로 디코딩하기 전에 유형이 보이는 경우가 많습니다.
SSH 키는 구조가 다릅니다. ssh-ed25519 줄의 AAAAC3NzaC1lZDI1NTE5… 부분은 키 블롭의 Base64이고, 익숙한 SHA256:… 지문은 그 블롭 해시를 패딩 없이 Base64로 쓴 것입니다.
해시는 원시 바이트입니다. 텍스트 hello의 SHA-256은 32바이트로, hex 64자로는 2cf24dba…9824, Base64 44자로는 LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=입니다. 웹훅 서명, SRI 속성, S3 Content-MD5 헤더는 Base64 형식을 기대하며, 이것을 hex 다이제스트와 비교하는 것이 “signature mismatch” 오류의 흔한 원인입니다.
설정 파일의 랜덤 시크릿은 대개 랜덤 32바이트를 Base64로 쓴 것으로, openssl rand -base64 32가 그 예입니다. 키 생성기는 자주 쓰는 프레임워크용 프리셋과 함께 같은 형식을 만들어 줍니다.
이 도구들이 하지 않는 일
- 인증서 체인을 검증하거나 폐기 여부를 확인하지 않습니다. 페이지는 의도적으로 다른 서버에 연결하지 않습니다.
- 개인 키 자료를 표시하지 않습니다. 인증서 도구는 개인 키의 유형과 크기만 보여 주고, SSH 도구는 개인 키 파일에서 공개 부분만 읽습니다.
- MD5와 SHA-1은 기존 시스템과의 호환성을 위해 제공합니다. 새로운 보안 설계에는 쓰지 마세요.
JWT 서명과 검증은 웹 및 토큰 도구를 참고하세요. 이런 Base64가 그 자체로는 비밀이 아닌 이유는 인코딩과 암호화의 차이에서 설명합니다.
자주 묻는 질문
해시와 키를 Base64로 쓰는 경우가 많은 이유는 무엇인가요?
hex보다 짧기 때문입니다. SHA-256 해시는 hex로 64자지만 Base64로는 44자이고, 32바이트 키도 64자 대신 Base64 44자면 됩니다. SRI 속성, SSH 지문, HMAC 서명, 대부분의 .env 시크릿이 그래서 Base64를 씁니다.
Base64는 암호화의 한 종류인가요?
아니요. Base64는 누구나 되돌릴 수 있습니다. PEM 개인 키는 키 바이트를 Base64로 바꾼 것일 뿐이므로 파일 자체를 보호해야 합니다. AES 도구처럼 실제 암호화는 되돌리려면 키나 비밀번호가 필요합니다.
랜덤 키는 안전한가요?
브라우저의 crypto.getRandomValues에서 나오며, WebCrypto가 키를 만들 때 쓰는 것과 같은 암호학적으로 안전한 소스입니다. 아무것도 저장하거나 전송하지 않으므로 각 값은 복사하기 전까지 화면에만 존재합니다.