X25519 암호화 & 복호화

무료 온라인 X25519 암호화 & 복호화 도구. 100% 로컬 처리 — 데이터가 기기를 벗어나지 않습니다.

National Standards
Other
출력

결과가 여기에 표시됩니다...

입력 → 암호화

Usage Guide

X25519(Curve25519 ECDH)에 대하여

X25519는 RFC 7748에서 표준화된 Curve25519 기반의 Diffie-Hellman 키 교환 함수입니다. TLS 1.3, WireGuard VPN, Signal Protocol, Noise Protocol Framework의 기본 키 교환으로 사용되는 세계에서 가장 널리 배포된 타원 곡선 키 교환 알고리즘입니다. X25519는 32바이트 키로 약 128비트 보안을 제공하며, 사이드 채널 공격에 저항하도록 설계되었고 Daniel J. Bernstein이 만들었습니다.

키 교환 — 암호화가 아닙니다: X25519는 키 합의만 수행합니다. 양측이 독립적으로 계산할 수 있는 공유 비밀을 생성하지만, 자체적으로 데이터를 암호화하거나 복호화하지 않습니다. 기밀성을 달성하려면 생성된 공유 비밀을 ChaCha20-Poly1305 나 AES-256-GCM 같은 대칭 암호의 키로 사용해야 합니다.

사용 단계

이 도구는 귀하의 개인 키와 상대방의 공개 키로부터 X25519 Diffie-Hellman 공유 비밀을 계산합니다:

•
1. 키 쌍 생성'키 쌍 생성'을 클릭하여 새 X25519 키 쌍을 만듭니다. 개인 키(64개의 16진수 문자)가 '내 개인 키' 필드에 채워집니다. 해당 공개 키는 내부에 저장됩니다 — 복사하여 다른 채널을 통해 상대방과 공유하세요.
•
2. 공개 키 교환귀하의 공개 키(64개의 16진수 문자)를 통신 상대방에게 보냅니다. 상대방의 공개 키를 받아 '상대방 공개 키(Hex)' 필드에 붙여넣습니다. 이 교환은 어떤 채널에서든 이루어질 수 있습니다 — 공개 키는 비밀이 아닙니다.
•
3. 공유 비밀 계산'암호화'를 클릭합니다. 도구가 DH(귀하의_개인_키, 상대방_공개_키)를 수행하고 64자 16진수 공유 비밀(32바이트)을 출력합니다. 상대방이 반대 방향으로 동일한 작업을 수행하면 동일한 공유 비밀을 얻습니다.
•
4. 공유 비밀로 암호화공유 비밀(또는 KDF 파생 키)을 AES-256-GCM이나 ChaCha20-Poly1305 같은 대칭 암호에 입력합니다. 프로덕션 시스템에서는 키 파생(예: HKDF) 없이 공유 비밀을 직접 암호 키로 사용해서는 안 됩니다.
브라우저 전용: 모든 키 생성 및 DH 계산은 WebCrypto API를 사용하여 브라우저에서 완전히 실행됩니다. 키가 서버로 전송되지 않습니다.

키 형식

이 도구의 X25519 키는 컴팩트한 16진수 형식을 사용합니다:

•
개인 키64개의 16진수 문자 = 32바이트. 무작위 스칼라 값. 비밀로 유지하세요. 예: a3f1e2d4c5b6a7f8e9d0c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2
•
공개 키64개의 16진수 문자 = 32바이트. Curve25519의 기저점을 개인 스칼라로 곱한 결과. 공개적으로 공유 가능. 예: 5b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8
•
공유 비밀64개의 16진수 문자 = 32바이트. DH(내_개인키, 상대방_공개키) = DH(상대방_개인키, 내_공개키)로 계산됩니다. 이 등식이 Diffie-Hellman 키 교환의 수학적 기반입니다.
•
키 상호 교환 불가X25519와 Ed25519 키는 동일해 보이지만(64개의 16진수 문자, 32바이트) 내부 표현이 다르며 상호 교환할 수 없습니다. Ed25519 개인 키를 X25519 개인 키로, 또는 그 반대로 절대 사용하지 마세요.

X25519 vs EdDSA(Ed25519)

X25519와 Ed25519는 모두 Curve25519를 기반으로 하지만 완전히 다른 암호화 목적에 사용됩니다:

•
목적X25519: 키 교환(Diffie-Hellman). Ed25519: 디지털 서명(인증). 서로를 대체할 수 없습니다.
•
수학적 형식X25519는 효율적인 스칼라 곱셈을 위해 Curve25519의 Montgomery 형식을 사용합니다. Ed25519는 twisted Edwards 형식을 사용합니다. 쌍유리 동치이지만 키 인코딩은 다릅니다.
•
키 상호 교환 불가동일한 바이트 길이에도 불구하고 키는 상호 교환할 수 없습니다. X25519 DH에 Ed25519 키 쌍을 사용하는 것은 보안을 손상시킬 수 있는 암호화적 오용입니다.
•
결합 사용실제로 Signal 같은 프로토콜은 둘 다 함께 사용합니다: X25519는 키 합의(세션 키 설정)에, Ed25519는 인증(MITM 공격 방지를 위한 키 교환 서명)에 사용됩니다.
관련 도구: 디지털 서명에는 EdDSA(Ed25519) 도구를 사용하세요. 공유 비밀로 대칭 암호화에는 ChaCha20-Poly1305 또는 AES-256-GCM 을 사용하세요.

FAQ

Q: X25519와 ECDH의 차이점은 무엇인가요?

A: X25519 는 ECDH입니다 — 구체적으로 RFC 7748에서 정의된 Curve25519 위에서 인스턴스화된 타원 곡선 Diffie-Hellman입니다. NIST 곡선(P-256, P-384) 위의 ECDH와 비교하여 X25519는 더 빠르고, 구현이 더 간단하고 안전하며(코팩터 문제 없음, 일반적인 입력에 대한 점 검증 불필요), 구현 공격에 대한 저항성을 갖추도록 처음부터 설계되었습니다. 사람들이 "Curve25519를 사용한 ECDH"라고 말할 때 X25519를 의미합니다.

Q: X25519와 Ed25519 키를 서로 바꿔서 사용할 수 있나요?

A: 아니요. X25519와 Ed25519는 모두 Curve25519를 기반으로 하지만 다른 수학적 표현(Montgomery 형식 vs. twisted Edwards 형식)과 다른 키 인코딩을 사용합니다. X25519 개인 키는 원시 32바이트 스칼라이고, Ed25519 개인 키는 사용 전에 해시(SHA-512)되는 32바이트 시드입니다. 두 키 유형 간의 변환 공식이 존재하지만, 명시적 변환 없이 서로 바꿔 사용하는 것은 암호학적으로 잘못되었으며 정보 유출이나 잘못된 결과를 초래할 수 있습니다. 각 목적에 맞는 별도의 키 쌍을 항상 생성하세요.

Q: 공유 비밀로 데이터를 어떻게 암호화하나요?

A: 32바이트 X25519 공유 비밀은 암호 키로 사용하기 전에 키 파생 함수(KDF)를 통과시켜야 합니다. 실제로 HKDF-SHA256이 가장 일반적인 선택입니다(TLS 1.3, Signal에서 사용). 원시 공유 비밀을 입력 키 자료로 전달하고, 프로토콜별 솔트와 info 문자열을 포함하고, AES-256-GCM 또는 ChaCha20-Poly1305 용으로 32바이트를 파생합니다. 간단한 사용 사례에서는 공유 비밀을 32바이트 AES-256 키로 직접 사용할 수 있지만, 프로덕션에서는 HKDF를 강력히 권장합니다.

Q: X25519는 순방향 비밀성(Forward Secrecy)을 제공하나요?

A: 예 — 임시 키 쌍과 함께 사용할 때. 순방향 비밀성(Perfect Forward Secrecy, PFS)은 장기 키가 손상되어도 과거 세션 키가 노출되지 않음을 의미합니다. TLS 1.3에서 양측은 각 핸드셰이크마다 새로운 X25519 키 쌍을 생성합니다(임시 DH). 공격자가 나중에 서버의 장기 개인 키를 얻더라도, 핸드셰이크 후 임시 X25519 키가 폐기되었기 때문에 이전에 기록된 트래픽을 복호화할 수 없습니다. 정적(재사용) X25519 키는 순방향 비밀성을 제공하지 않습니다.

Q: X25519는 양자 공격에 저항성이 있나요?

A: 아니요 — 충분히 강력한 양자 컴퓨터에 대해서는 저항성이 없습니다. Shor 알고리즘을 실행하는 양자 컴퓨터는 다항 시간에 타원 곡선 이산 로그 문제를 풀어 X25519를 깰 수 있습니다. 이는 모든 타원 곡선 및 유한 필드 Diffie-Hellman 방식에 동일하게 적용됩니다. 그러나 필요한 양자 컴퓨터(수천 개의 오류 수정 논리 큐비트)는 아직 존재하지 않습니다. 포스트 양자 키 교환을 위해 NIST는 ML-KEM(이전 CRYSTALS-Kyber)을 표준화했습니다. Chrome과 Firefox의 TLS 1.3은 이미 하이브리드 X25519+ML-KEM 키 교환을 배포하고 있습니다.

Use Cases

권장: TLS 1.3 키 교환

X25519는 TLS 1.3(RFC 8446)에서 선호하는 키 교환 알고리즘으로 모든 주요 브라우저와 서버에서 지원됩니다. TLS 1.3에서 클라이언트와 서버는 각각 임시 X25519 키 쌍을 생성하고, ClientHello/ServerHello에서 공개 키를 교환하며, HKDF를 사용해 핸드셰이크 키를 파생합니다. 이로써 단일 왕복으로 완료되며 순방향 비밀성을 제공합니다. X25519는 TLS 1.3의 필수 암호 스위트에서 RSA 키 교환과 이전 ECDH 변형을 대체했습니다.

Recommended Configuration:
  • ✅ 모든 서버에서 TLS 1.3 활성화 — X25519가 자동으로 포함됨
  • ✅ X25519는 모든 TLS 1.3 핸드셰이크에서 순방향 비밀성 제공
  • ✅ OpenSSL, BoringSSL, NSS 및 모든 주요 TLS 라이브러리에서 기본 지원
  • ❌ TLS 1.2 RSA 키 교환 사용 금지 — 순방향 비밀성 없음
권장: WireGuard VPN

WireGuard는 X25519를 유일한 키 교환 메커니즘으로 사용합니다. 각 WireGuard 피어는 정적 X25519 키 쌍(인증용)을 가지고 각 핸드셰이크마다 임시 X25519 키 쌍을 생성합니다(순방향 비밀성용). 프로토콜은 사전 공유 키 혼합에도 X25519를 사용하며 Noise Protocol Framework를 채택합니다. WireGuard의 미니멀리스트 설계 — 하나의 키 교환 알고리즘, 하나의 대칭 암호(ChaCha20-Poly1305), 하나의 해시(BLAKE2s) — 로 인해 감사하기 쉽고 빠릅니다.

Recommended Configuration:
  • ✅ X25519는 WireGuard의 유일한 키 교환 — 설정 불필요
  • ✅ 정적 키 쌍 생성: wg genkey | tee private.key | wg pubkey > public.key
  • ✅ WireGuard는 임시 키 쌍을 통해 자동 순방향 비밀성 제공
  • 💡 WireGuard 조합: X25519(키 교환) + ChaCha20-Poly1305(암호화) + BLAKE2s(해싱)
권장: 엔드투엔드 암호화 메시징(Signal, WhatsApp)

Signal Protocol(Signal, WhatsApp 등에서 사용)은 Double Ratchet 알고리즘과 X3DH(Extended Triple Diffie-Hellman) 키 합의에서 X25519를 광범위하게 사용합니다. X3DH는 여러 X25519 DH 작업을 사용하여 오프라인일 수 있는 당사자 간에 초기 공유 키를 설정합니다. Double Ratchet은 이후 X25519 래칫에서 지속적으로 새 키를 파생하여 순방향 비밀성과 침해 후 복구를 모두 제공합니다. 이는 안전한 메시징의 황금 표준으로 간주됩니다.

Recommended Configuration:
  • ✅ X25519는 Signal Protocol 키 합의의 기반
  • ✅ X3DH는 비동기 키 설정 가능(한 쪽이 오프라인이어도 됨)
  • ✅ Double Ratchet + X25519는 순방향 비밀성과 사후 보안 제공
  • 💡 WhatsApp, Wire, Facebook Messenger 비밀 채팅 모두 Signal Protocol 사용
권장: 하이브리드 암호화(키 캡슐화)

하이브리드 암호화는 X25519를 사용하여 공유 비밀을 설정한 다음 대칭 암호로 실제 데이터를 암호화합니다. 이 패턴(ECIES 또는 HPKE — Hybrid Public Key Encryption, RFC 9180)으로 수신자의 X25519 공개 키를 가진 누구나 사전 공유 비밀 없이 암호화된 데이터를 보낼 수 있습니다. 송신자는 임시 X25519 키 쌍을 생성하고, 수신자의 공개 키로 공유 비밀을 계산하고, HKDF를 통해 대칭 키를 파생하고, 데이터를 ChaCha20-Poly1305 로 암호화하고, 임시 공개 키를 암호문과 함께 보냅니다.

Recommended Configuration:
  • ✅ X25519를 사용한 표준화된 하이브리드 암호화에 HPKE(RFC 9180) 사용
  • ✅ 임시 송신자 키 쌍이 각 메시지의 순방향 비밀성 보장
  • ✅ 조합: X25519(키 교환) + HKDF(키 파생) + AES-256-GCM(암호화)
  • 💡 이 패턴은 age(파일 암호화 도구)와 Tink 라이브러리에서 사용
비권장: 기밀성을 위해 X25519 단독 사용

X25519는 공유 비밀만 생성합니다 — 데이터를 암호화하지 않습니다. 공유 비밀 자체는 암호문이 아니며, 동일한 DH 계산(올바른 키로)을 수행하는 모든 당사자가 이를 얻을 수 있습니다. 대칭 암호를 적용하지 않으면 데이터는 평문으로 남습니다. 이는 알고리즘의 근본적인 오용입니다. X25519는 항상 AES-256-GCM 또는 ChaCha20-Poly1305 와 결합하여 데이터를 실제로 보호하세요.

Recommended Configuration:
  • ❌ X25519 공유 비밀을 암호문으로 취급하지 말 것 — 이것은 키이지 암호화된 데이터가 아님
  • ❌ 키 파생을 건너뛰지 말 것 — 암호 키로 사용하기 전에 HKDF로 공유 비밀 처리
  • ✅ X25519 + HKDF + AES-256-GCM이 올바른 하이브리드 암호화 패턴
  • 💡 X25519는 키 배포 문제를 해결하고 대칭 암호는 데이터 기밀성을 해결

모범 사례 요약

  • X25519는 키 교환 알고리즘입니다 — 공유 비밀을 생성하며 암호문이 아닙니다. 실제 데이터를 암호화하려면 항상 AES-256-GCM 또는 ChaCha20-Poly1305와 결합하세요.
  • 프로덕션 시스템에서 X25519 공유 비밀을 대칭 암호 키로 사용하기 전에 HKDF-SHA256으로 처리하세요.
  • 순방향 비밀성을 달성하기 위해 임시 X25519 키 쌍(세션당 새 쌍 생성)을 사용하세요.
  • X25519 키를 Ed25519 서명 키로 사용하거나 그 반대로 사용하지 마세요 — 둘 다 32바이트이지만 내부 표현이 다릅니다.
  • X25519는 TLS 1.3, WireGuard, Signal Protocol의 표준입니다 — 새 구현에서 NIST 곡선의 이전 ECDH보다 선호하세요.

토론 및 피드백

0개의 댓글
나