사용법
키 길이(2048·3072·4096 비트)와 개인키 형식(PKCS#1 — OpenSSH의 역사적 기본, 또는 PKCS#8 — 현대 상호 운용 기본)을 고르고 Generate를 클릭하면 공개키·개인키·SHA-256 핑거프린트가 표시됩니다. 개인키는 "공개" 토글 뒤에 숨겨져 화면 공유 중에 동료가 어깨너머로 봐도 가져갈 수 없습니다. 두 키 모두 PEM 인코드이며 `-----BEGIN ... KEY-----` 블록 형식은 TLS 도구·SSH 클라이언트·JWT 라이브러리가 모두 받습니다.
비운영 상황에 사용하세요. JWT를 HS256에서 RS256으로 이행하는 테스트, 테스트용 웹훅 서명, 일회용 VM용 SSH 키, RSA로 암호화된 페이로드 왕복 학습 같은 경우입니다. 운영 키는 실제로 사용할 머신에서 생성하는 것이 원칙입니다. 단발이라면 `openssl genrsa -out key.pem 4096`, SSH라면 `ssh-keygen -t rsa -b 4096`, 가치 높은 키에는 하드웨어 HSM·KMS를 쓰세요. 이 도구의 브라우저 측은 `node-forge`로 RSA 키 생성을 로컬에서 실행하며 개인키가 서버에 닿지 않습니다. 다만 웹 페이지 안에서 동작하는 CSPRNG는 하드닝된 머신의 OpenSSL보다 감사가 어렵다는 점을 유념하세요.
자주 묻는 질문
키 길이는 얼마나 되어야 하나요?
NIST SP 800-57 Part 1 Rev 5(2020년)는 목표 유효 기간을 제시합니다. **2048비트**는 2030년까지의 보호에 허용(대칭 키 112비트 상당), **3072비트**는 2030년 이후도 사용 가능(128비트 상당), **4096비트**는 가치 높은 키나 장수명 키용(152비트 상당)입니다. JWT 서명이나 단명 TLS에는 2048로 충분합니다. 10년 단위로 들고 다니는 SSH 키나 CA 루트에는 3072나 4096을 고르세요. 대가는 검증 속도입니다 — 4096비트 서명 검증은 2048비트보다 약 4배 느리며 API 호출마다 JWT를 검증하는 자리에서는 누적됩니다.
RSA·ECDSA·Ed25519 — 어느 것을 골라야 하나요?
양 끝을 자신이 통제하는 신규 코드라면 **Ed25519**가 기본입니다. 키가 작고(32바이트), 서명·검증이 빠르며, ECDSA를 깨뜨려 온 구현상의 함정(논스 재사용 등)에도 견고합니다. **ECDSA P-256**은 NIST·FIPS 준수가 요구되고 Ed25519가 승인되지 않은 경우의 두 번째 선택지입니다. **RSA**는 레거시 호환에서 이깁니다 — 옛 TLS 클라이언트, 하드웨어 토큰, 옛 OAuth 제공자가 게시한 JWT JWK, 거의 모든 TLS 인증서 체인 — 더불어 "누구나 다룰 줄 안다"는 운용 단순성도 있습니다. 상호 운용성이 결정 요인이면 RSA, 선택의 자유가 있으면 Ed25519를 고르세요.
같은 키를 서명과 암호화 양쪽에 쓸 수 있나요?
기계적으로는 가능합니다. RSA가 둘 다 지원합니다. 그러나 암호학·운영적으로는 그만두어야 합니다. 베스트 프랙티스(NIST SP 800-57 Part 1 §5.6.3)는 목적별로 별도 키를 두는 것입니다. 같은 키로 서명과 암호화를 겸하면 공격 면이 넓어집니다 — 서명 프로토콜의 취약점이 복호화 키의 정보를 누설할 수 있고 그 역도 가능합니다. JWT JWK가 `use` 필드(`sig` 또는 `enc`)를 명시적으로 두는 이유가 이것입니다. 신규 키에서는 둘을 생성해 라벨을 붙이세요.
브라우저에서 생성한 키를 실운영에 써도 안전한가요?
저위험 상황에 사용하세요. 테스트용 JWT 서명, 일회용 VM의 SSH 키, CI 테스트용 임시 CA 같은 경우입니다. `node-forge`(또는 브라우저의 WebCrypto)가 사용하는 CSPRNG는 명세가 요구하는 `crypto.getRandomValues`로 암호학적으로 건전합니다. 위험은 수학이 아니라 주변 환경에 있습니다. 침해된 브라우저 확장, 변조된 스크립트를 끼워 넣는 네트워크 MITM, 화면 녹화된 세션 등으로 개인키가 유출될 수 있으며 에어 갭이나 하드닝된 머신의 `openssl genrsa`에서는 이런 일이 일어나지 않습니다. 정말 가치 있는 것은 대상 머신에서 생성하고 개인 바이트가 밖으로 나가지 않게 하세요.
SSH 키가 필요합니다 — 출력을 그대로 `authorized_keys`에 붙여 넣어도 되나요?
직접 붙여 넣을 수는 없습니다. `authorized_keys`는 OpenSSH 형식(`ssh-rsa AAAAB3NzaC1yc2E... user@host`)을 기대하지 PEM이 아닙니다. 변환하려면 공개 키 PEM을 `key.pem`에 저장한 뒤 `ssh-keygen -y -f key.pem > key.pub`로 개인 키에서 OpenSSH 형식을 유도하거나, `ssh-keygen -i -m PKCS8 -f key.pem`으로 PEM 공개 키에서 변환합니다. 진짜 SSH 용도라면 처음부터 `ssh-keygen -t rsa -b 4096`로 생성하는 것이 간단합니다. PEM 개인 키와 OpenSSH 공개 키를 한 번에 얻을 수 있습니다.
개인 키에 패스프레이즈를 붙여야 하나요?
노트북에 두는 로컬 키에는 패스프레이즈를 붙이세요. PEM 바이트가 암호화되어 디스크 도난이나 파일 시스템 백업 유출에서 키가 직접 넘어가는 것을 막습니다. 반면 부팅 시 자동 프로세스가 로드하는 서버의 서비스 키에는 패스프레이즈를 붙이지 마세요. 같은 프로세스가 읽을 수 있는 자리에 패스프레이즈를 두어야 하므로 의미가 사라집니다. 본 도구는 암호화 없는 키를 생성합니다. 패스프레이즈가 필요하면 복사 후 `openssl rsa -aes256 -in plain.pem -out encrypted.pem`을 실행하세요.
관련 개념
RSA(Rivest–Shamir–Adleman, 1977년 발명, 1978년 논문 공개)는 같은 키 쌍으로 서명과 암호화를 모두 다루는 비대칭 암호 시스템입니다. 안전성은 두 큰 소수의 곱을 인수분해하는 어려움에 기댑니다. 2048비트 RSA 키는 약 1024비트 소수 2개의 곱이며 현시점에서 그 인수분해는 실행 불가입니다. 공개 키는 `(n, e)`(`e`는 거의 항상 65537), 개인 키는 `e·d ≡ 1 (mod φ(n))`을 만족하는 `d`를 보관합니다. RSA 연산의 대부분은 모듈러 거듭제곱이고, 비대칭성은 인수분해를 모르고 `(n, e)`에서 `d`를 유도하기 어려운 데서 나옵니다.
같은 RSA 개인 키에 대해 **전송 형식**이 2가지 있습니다. **PKCS#1**(`BEGIN RSA PRIVATE KEY`)은 RSA 고유의 원래 ASN.1 구조로 `modulus`·`publicExponent`·`privateExponent` 같은 필드를 가집니다. **PKCS#8**(`BEGIN PRIVATE KEY`)은 PKCS#1(또는 다른 알고리즘) 블롭을 알고리즘 비의존 엔벨로프로 감싼 것입니다. PKCS#8은 현대의 기본이며 RSA·ECDSA·Ed25519 모두 같은 키 파일 형식을 쓸 수 있고 2010년대 후반 이후 OpenSSL의 기본 출력입니다. 변환은 키를 재생성하지 않습니다. 래핑 바이트만 바뀝니다.
선택지를 형성하는 3가지 인접 프리미티브가 있습니다. **ECDSA**(타원 곡선 디지털 서명 알고리즘)는 키 길이의 일부로 동등한 보안을 얻습니다 — 256비트 ECDSA ≈ 3072비트 RSA — 만 논스 재사용으로 깨지기 쉬워 과거 몇몇 실운영을 무너뜨렸습니다. **Ed25519**(Bernstein의 twisted Edwards 곡선, RFC 8032)는 양쪽의 장점을 묶은 현대적 선택지로 키가 작고 연산이 빠르며 논스 재사용 지뢰도 없지만, 새로워서 일부 레거시 환경은 받지 않습니다. **포스트 양자** 알고리즘(KEM의 CRYSTALS-Kyber, 서명의 CRYSTALS-Dilithium)은 2024~2026년에 실운영에 진입하기 시작했습니다. 충분히 큰 양자 컴퓨터가 RSA·EC를 깰 것이기 때문입니다. RSA는 도입 실적이 방대해 당분간 주류이지만, 신규 시스템은 Ed25519를 기본으로 두고 다음 10년에 PQ 이행을 계획하세요.
