Ed25519가 RSA를 대체하는 이유 — SSH 키 알고리즘 비교와 셸 이스케이프 함정
새 서버에 SSH 키를 등록할 때 ssh-keygen이 물어보는 첫 질문은 알고리즘입니다. 예전엔 별생각 없이 RSA 2048비트를 골랐지만, GitHub를 비롯한 대부분의 서비스가 이제 Ed25519를 기본값으로 권장합니다. 키 길이만 보면 RSA 2048비트가 훨씬 커 보이는데 왜 더 짧은 Ed25519가 "더 안전하다"고 하는 걸까요. 그리고 명령어를 만들 때 코멘트에 특수문자를 넣으면 왜 문제가 생기는지, SSH 키 생성기의 실제 동작을 근거로 짚어봅니다.
1. 두 알고리즘은 완전히 다른 수학 문제에 기반한다
RSA의 안전성은 큰 정수를 소인수분해하기 어렵다는 문제에서 나옵니다. 키가 크면 클수록(2048비트, 4096비트) 소인수분해에 필요한 계산량이 지수적으로 늘어나는 방식으로 안전성을 확보합니다. 반면 Ed25519는 타원곡선 이산로그 문제에 기반한 전자서명 알고리즘(EdDSA의 한 구현)입니다. 타원곡선 암호는 같은 비트 수의 키라도 정수분해 기반 암호보다 훨씬 풀기 어려운 문제 위에 서 있기 때문에, 상대적으로 훨씬 짧은 키로도 동등하거나 더 높은 안전성 수준을 낼 수 있습니다. "키가 짧다 = 약하다"는 직관은 서로 다른 수학 문제를 같은 잣대로 비교할 때 생기는 오해입니다.
2. 그래서 256비트가 2048비트보다 강한 이유
암호학에서 "안전성 수준"은 공격자가 키를 깨는 데 필요한 연산 횟수를 2의 거듭제곱으로 나타낸 값입니다. NIST 권고 기준으로 대략적인 대응 관계는 다음과 같습니다.
| 알고리즘 · 키 길이 | 추정 안전성 수준 | 기반 문제 |
|---|---|---|
| RSA 2048비트 | 약 112비트 | 정수 소인수분해 |
| RSA 3072비트 | 약 128비트 | 정수 소인수분해 |
| RSA 4096비트 | 약 140~150비트 | 정수 소인수분해 |
| Ed25519 (256비트) | 약 128비트 | 타원곡선 이산로그 |
즉 Ed25519 256비트는 RSA 3072비트와 비슷한 안전성 수준을 8분의 1도 안 되는 키 크기로 달성합니다. RSA 2048비트보다도 안전성이 높으면서 키·서명은 훨씬 짧아, 저장 공간뿐 아니라 키 생성·서명·검증 연산 속도까지 함께 빨라지는 구조입니다. RSA는 키를 키워서 안전성을 유지해야 하지만(양자컴퓨터 위협 이전 기준으로도 이미 RSA 1024비트는 사실상 폐기됨), 타원곡선은 작은 키로도 같은 목표를 달성하는 효율적인 수학적 구조를 쓰기 때문입니다.
3. 속도 차이가 실제로 체감되는 지점
RSA는 키 생성 과정에서 큰 소수 두 개를 찾아야 하는데, 이 소수 판별 자체가 무거운 연산입니다. 4096비트 RSA 키를 SSH 키 생성기로 명령어를 만들어 직접 실행해보면 몇 초에서 길게는 수십 초까지 걸릴 수 있는 반면, Ed25519는 거의 즉시 끝납니다. 서명 검증도 마찬가지로 Ed25519가 더 빠른데, 이 차이는 키를 한 번만 만드는 개인 사용자에겐 크게 중요하지 않지만, SSH 접속마다 서명이 오가는 서버 환경이나 CI/CD 파이프라인처럼 연결이 빈번한 상황에서는 누적된 지연으로 체감됩니다.
4. 명령어를 셸에 붙여넣을 때 생기는 함정
키 알고리즘과 별개로, ssh-keygen 명령어를 만들 때 실수하기 쉬운 지점이 코멘트(-C)나 파일 경로(-f)에 셸이 특별하게 해석하는 문자를 그대로 넣는 경우입니다. 예를 들어 코멘트에 큰따옴표가 포함된 John "Desktop" Kim을 이스케이프 없이 -C "John "Desktop" Kim"처럼 그대로 넣으면, 셸은 따옴표가 짝이 맞지 않는다고 판단해 구문 오류를 내거나 의도치 않은 부분에서 명령어가 끊깁니다. $ 역시 변수 참조로 해석되어 원하지 않는 값이 치환될 수 있고, 백틱은 그 안의 내용을 별도 명령어로 실행해버립니다.
escShellDouble() 함수는 백슬래시 → $ → 큰따옴표 → 백틱 순서로 replace() 체인을 걸어 입력값을 자동 이스케이프합니다. 코멘트에 John "Desktop" Kim을 입력하면 생성되는 명령어는 -C "John \"Desktop\" Kim" 형태가 되어, 그대로 터미널에 붙여넣어도 셸이 하나의 문자열로 정확히 인식합니다.
5. 언제 여전히 RSA를 써야 하나
Ed25519가 대부분의 상황에서 더 나은 선택이지만, 아주 오래된 레거시 서버나 일부 네트워크 장비(구형 라우터·스위치의 관리 콘솔 등)는 EdDSA를 아예 지원하지 않고 RSA만 받아들이는 경우가 있습니다. 이런 호환성 제약이 확실할 때만 RSA를, 그것도 최소 3072비트 이상을 권장하는 것이 합리적입니다. 참고로 이 도구는 RSA 2048비트·4096비트와 Ed25519 세 가지만 지원하며 ECDSA는 별도로 제공하지 않는데, 이는 EdDSA가 ECDSA보다 구현 실수(난수 재사용 등)에 더 안전하게 설계되어 실무에서 권장 순위가 더 높기 때문입니다.
자주 묻는 질문
Q. Ed25519 키를 이미 쓰던 RSA 키와 함께 쓸 수 있나요?
네. ~/.ssh/에 여러 키를 동시에 둘 수 있으며, 서버·서비스마다 다른 키를 등록해도 됩니다. 파일명을 다르게 지정(예: id_ed25519_github)하면 기존 키를 덮어쓰지 않습니다.
Q. 키 길이를 키우면 무조건 더 안전한가요?
같은 알고리즘 안에서는 대체로 그렇지만, 알고리즘이 다르면 단순 비교가 무의미합니다. RSA 4096비트가 Ed25519 256비트보다 숫자상 훨씬 크지만 안전성 수준은 비슷하거나 오히려 Ed25519 쪽이 높게 평가되는 경우도 있습니다.
Q. 패스프레이즈에도 특수문자를 넣어도 되나요?
패스프레이즈는 ssh-keygen 실행 중 별도 프롬프트로 입력하기 때문에 명령어 문자열에 포함되지 않아 셸 이스케이프 문제와 무관합니다. 오히려 특수문자를 섞은 긴 패스프레이즈가 보안상 권장됩니다.
Q. 코멘트를 비워도 되나요?
네. 코멘트는 공개키 파일 끝에 식별용으로 붙는 문자열일 뿐 키 자체의 보안과는 무관하므로 생략해도 키 생성에 문제가 없습니다.