DES / 3DES / RC4 / Blowfish 암호화/복호화

오래된 파일, 백업, 프로토콜에 여전히 남아 있는 네 고전 암호로 암호화하거나 복호화합니다 — ECB/CBC의 DES와 3DES, 스트림의 RC4(ARCFOUR), 최대 56바이트 키의 Blowfish. FIPS 46-3, Schneier의 공개 Blowfish 벡터, RFC 6229로 검증되었습니다. 모든 것이 브라우저에서 로컬로 동작합니다 — 아무것도 업로드되지 않습니다. 현대적 작업에는 AES-GCM을 쓰세요.
이 암호들은 호환을 위해 있는 것이지 새 작업용이 아닙니다. DES는 2005년 폐지, 3DES는 2023년 폐지, RC4는 2015년부터 TLS에서 금지(RFC 7465)되었고, Blowfish의 64비트 블록은 한 키 아래 약 32 GiB 데이터에서 생일 한계에 도달합니다. 새로 만드는 것에는 AES-GCM을 쓰세요.
방향: 암호: 모드: 출력:
DES = 1977년 데이터 암호화 표준: 64비트 블록, 유효 56비트 키. 폐지되었지만 오래된 백업, PIN 블록(은행), Kerberos v4에 남아 있습니다. 키는 정확히 8바이트여야 합니다.
키 (8 bytes, hex or text)
hex는 공백, 콜론, 0x 접두사를 허용합니다. DES는 각 키 바이트의 패리티 비트를 무시합니다.
Plaintext text (the data to encrypt, UTF-8 encoded)
블록 암호는 PKCS#7으로 패딩합니다; RC4는 패딩하지 않습니다.
암호문 (한 줄: 암호, 모드, 값; 매개변수는 아래 줄에)
이 페이지가 받는 키 길이
암호키블록상태
DES정확히 8바이트(유효 56비트)64비트2005년 폐지(NIST SP 800-131A)
3DES-EDE3정확히 24바이트(유효 112비트)64비트2023년 이후 사용 불가(SP 800-131A r2)
3DES-EDE2정확히 16바이트(유효 112비트)64비트EDE3과 동일, 더 약한 레거시 옵션
RC4 / ARCFOUR1..256바이트스트림2015년부터 TLS에서 금지(RFC 7465)
Blowfish4..56바이트64비트깨지지 않았으나 64비트 블록 한계; Twofish/AES 사용
DES가 각 바이트의 1비트를 패리티로 쓰기 때문에 유효 키 크기는 원시 크기보다 작습니다: 64비트 원시 키는 키 비트 56개만 담고, 독립 키 세 개의 3DES는 112개를 담습니다(중간자 만남).
OpenSSL 상호 운용 — OpenSSL 3은 이 암호들을 레거시 프로바이더로 옮겼습니다. 거부되면 -provider legacy를 붙이세요. 이 페이지에 해당하는 명령줄:
openssl enc -des-ecb -K 133457799BBCDFF1 -in msg.bin -out msg.enc
openssl enc -des3 -K <48 hex> -iv <16 hex> -in msg.bin -out msg.enc(3DES-CBC)
openssl enc -rc4 -K 4b6579 -in msg.bin -out msg.enc  /  Blowfish-CBC는 -bf-cbc.
복호화는 -d. -K는 원시 hex 키, -k는 암호를 받습니다(피하세요 — KDF가 이 페이지의 것과 다릅니다).
자체 테스트
페이지 엔진을 공개 및 독립 생성 벡터에 대해 재구동합니다: FIPS 46-3 실례 DES 예제, OpenSSL 생성 3DES EDE2/EDE3 암호문, Schneier Blowfish 벡터, RFC 6229의 RC4 테스트 벡터와 고전 "Key/Plaintext" 예제, 모든 모드의 왕복, 부정 테스트(잘못된 키 크기, 블록 배수가 아닌 암호문은 실패해야 함). 아무것도 전송되지 않습니다.
DES, 3DES, RC4, Blowfish 처음부터 설명
한 문장으로: 이 네 암호는 1990년대의 일꾼들이었습니다 — DES와 삼중 암호화 우회책 3DES, 스트림 암호 RC4, Blowfish — 그리고 하나도 예외 없이 이제 은퇴했거나 폐기되었으며, 여전히 읽어야 하는 오래된 파일, 하드웨어, 프로토콜이 있어 살아남았을 뿐입니다.
DES: 모든 것을 시작한 1977년 표준

정체. 데이터 암호화 표준(FIPS 46, 1977)은 64비트 블록에 56비트 키를 쓰는 16라운드 파이스텔 암호입니다(각 바이트의 1비트가 패리티 검사라 8바이트에 저장). IBM이 NSA 자문을 받아 설계했고 20년간 미국 표준이었으며, 1998년 EFF의 Deep Crack 기계가 25만 달러의 하드웨어로 56시간 만에 키를 전수 탐색하면서 정책적으로 깨졌습니다. NIST는 2005년 암호화용으로 폐지했습니다.

패리티 비트가 키 길이를 헷갈리게 하는 이유. DES 키의 8번째마다 오는 비트는 나머지 일곱 개에서 계산되므로, 8바이트 키는 독립 비트 56개만 담습니다 — 같은 암호에 "64비트 키"와 "56비트 키"가 함께 보이는 이유입니다. 3DES도 물려받습니다: 원시 24바이트 = 원시 168비트 = 유효 112비트(중간자 만남이 나머지를 지움).

아직 만나는 곳. 은행 PIN 블록(ISO 9564), 일부 Kerberos v4 영역, 오래된 백업 아카이브, 스마트 카드. 오늘 DES를 요구하는 시스템은 1990년대 하드웨어와 상호 운용 중이거나, 단순히 안전하지 않은 것입니다.

3DES: 암호화, 복호화, 암호화

트릭. 트리플 DES는 각 블록을 세 번 돌립니다: EDE3는 서로 다른 세 키를 씁니다(C = Ek3(Dk2(Ek1(P)))). 가운데 복호화 단계는 k1=k2로 설정해 단일 DES를 흉내 낼 수 있게 하려는 것입니다. EDE2는 두 키만 써서(k1=k3) 유효 112비트를 줍니다. 이미 공격받던 암호의 보안을 새 암호를 발명하지 않고 세 배로 늘린 즉석 처방이었습니다.

그래도 죽은 이유. 두 문제: 느리고(블록마다 DES 세 번, AES의 약 1/20 속도) 64비트 블록을 유지했습니다. 한 키 아래 32 GiB(232 블록의 생일 한계)부터 블록 충돌이 평문 구조를 노출할 만큼 likely해집니다 — Sweet32 공격(2016)이 TLS 3DES 세션에서 이를 실증했습니다. NIST는 2023년 이후 3DES 암호화를 금지했고(SP 800-131A r2), PCI DSS는 결제 시스템에서의 퇴역을 요구합니다.

RC4 / ARCFOUR: 초창기 웹의 스트림 암호

동작 방식. RC4(Ron's Code 4, 1987년 설계, 1994년 유출)는 스트림 암호입니다: 키가 256바이트 치환을 스케줄링하고(KSA), 그 치환이 메시지와 XOR되는 유사난수 바이트 스트림을 뿜습니다(PRGA). 패딩 없음, 블록 크기 없음, 임의 길이, 소프트웨어에서 사소하게 빠름 — 1990년대 SSL/TLS와 WEP을 지배한 이유입니다. "ARCFOUR"는 대부분 오픈소스 프로젝트가 쓰는 상표 없는 이름입니다.

깨진 방식. Fluhrer-Mantin-Shamir(2001)이 키스트림 첫 바이트들이 치우쳐 있음을 보였습니다 — 패킷마다의 키 구성이 그 바이트를 공격자에게 먹여 WEP에 치명적이었습니다. 이후 치우침 공격(2013, AlFardan 등)은 수백만 연결으로 RC4 보호 TLS 세션에서 평문을 회복했습니다. RFC 7465(2015)는 TLS의 RC4를 전면 금지합니다.

고전 벡터. 키 "Key"(3바이트), 메시지 "Plaintext"는 암호문 bbf316e8d940af0ad3을 줍니다 — RC4 샘플을 돌려 비교해 보세요. 자체 테스트는 40비트 키 01 02 03 04 05의 RFC 6229 키스트림도 검사합니다: b2396305f03dc027ccc3524a0a1118a8.

Blowfish: 깨지지 않았지만 블록 한계

정체. Bruce Schneier의 1993년 파이스텔 암호: 64비트 블록, 32~448비트(4..56바이트) 키, 16라운드, 그리고 하위 키를 만들기 위해 Blowfish 자신을 521번 돌리는 유명한 키 스케줄 — 키 설정이 느린 대신 전수 탐색 시도도 비쌉니다. 전 라운드 Blowfish를 깨는 실용적 암호 해석은 없습니다.

그럼에도 이 페이지에 있는 이유. 문제는 알고리즘이 아니라 64비트 블록입니다: 한 키 아래 약 32 GiB를 넘으면 생일 충돌이 데이터를 노출합니다(3DES와 같은 한계, Sweet32 방식). Schneier 본인도 새로 만드는 것에는 후계자 Twofish(AES 최종 후보)나 AES를 권장합니다. Blowfish는 bcrypt 안에 살아남습니다 — 그 암호 해시의 키 스케줄이 바로 Blowfish입니다 — 해싱은 기가바이트가 아니라 작은 입력을 쓰니 괜찮습니다.

고전 벡터. 모두 0인 키와 평문은 4ef997456198dd78로 암호화됩니다(샘플 출력의 첫 블록). 키 "abcdefghijklmnopqrstuvwxyz"로 "BLOWFISH"는 324ed0fef413a203을 줍니다. 둘 다 Schneier의 공개 벡터 파일에서 온 것이며 자체 테스트가 검사합니다.

흔한 실수
  • 새 데이터에 이것들 쓰기. 이 페이지의 모든 암호가 폐기되었습니다(Blowfish는 블록 크기 한계). 올바른 현대적 선택은 AES-GCM입니다 — AES 암호화/복호화를 보세요.
  • 암호로 DES 키 만들기. 8글자 암호는 무작위 56비트가 아닙니다. 글자당 몇 비트 엔트로피일 뿐입니다. 옛 시스템이 정확히 그렇게 했고, "DES 암호화" 아카이브가 몇 분 만에 사전 공격에 무너지는 가장 흔한 이유입니다.
  • CBC에서 IV 재사용. 같은 키의 메시지들에서 첫 블록의 평문 동일성이 새어 나갑니다. 무작위 IV 버튼은 이유가 있어 존재합니다.
  • RC4 키스트림 재사용. RC4는 같은 키에 같은 키스트림을 XOR합니다: 한 키로 두 메시지를 암호화하면 원타임패드 두 번 쓰기입니다 — 암호문끼리 XOR하면 두 평문이 드러납니다. WEP의 치명적 결함이 정확히 키스트림 재사용 구성이었습니다.
  • "복호화되니 맞겠지"라고 가정하기. 여기의 ECB/CBC는 복호화 시 패딩만 검증합니다 — 잘못된 키는 대개 쓰레기가 되지만 그것이 언패드될 수도 있습니다. 레거시 모드에는 무결성 검사가 없습니다. 필요하면 이것들이 아니라 AES-GCM이 필요합니다.
  • 3DES를 "168비트"로 세기. 원시 키는 168비트지만 유효 강도는 112입니다 — 중간자 만남이 삼중 암호화를 이중 반 조금으로 줄입니다. 3DES의 조상 구성들에서처럼요.
FAQ

깨진 암호 도구를 왜 유지하나요? 호환성 때문입니다. 암호화된 백업, 오래된 형식으로 내보낸 파일, 캡처한 프로토콜 트레이스, CTF 문제, 업그레이드할 수 없는 하드웨어가 아직도 이 암호들을 말합니다. 오래된 데이터를 읽는 것은 정당합니다. 새 데이터를 이것들로 쓰는 것은 아닙니다.

제 DES 키가 홀수 패리티/비 ASCII 바이트를 가졌어요. DES는 각 키 바이트의 패리티 비트를 무시하므로 유효 키는 무엇이든 나머지 56비트입니다. 이 페이지는 임의의 8바이트를 받고 짝수 패리티를 강제하지 않습니다.

복호화된 텍스트가 가끔 쓰레기처럼 보이는 이유는? 키, 모드, IV가 잘못되었거나 데이터가 가정과 다른 방식으로 암호화된 것입니다. 인증 태그가 없어 깔끔한 "잘못된 키" 오류는 없습니다 — 패딩 검사가 유일한 힌트이고 요행으로 통과할 수 있습니다(1/256 확률).

Blowfish는 제 파일에 안전한가요? 작은 파일이라면 암호학적으로 네(실용적 파괴 없음). 한 키 아래 기가바이트급이라면 아니요 — 64비트 블록 생일 한계는 키 강도가 아니라 데이터 양의 문제입니다. Twofish나 AES가 문제를 피합니다.

어디서 본 72바이트 Blowfish 키는요? 일부 구현은 72바이트까지 받지만 Schneier의 참조 구현은 56을 쓰고, 그 너머의 바이트는 표준 스케줄에서 추가 확산을 주지 않습니다. 이 페이지는 참조를 따릅니다: 4..56바이트.