CentOS·RockyOS·Windows 기본 암호화 알고리즘과 현재 기준 안전 목록

CentOS·RockyOS·Windows 기본 암호화 알고리즘 소개 (현재 기준 목록 포함)

운영체제에서 “기본 암호화 알고리즘”이라고 할 때는 한 가지가 아니라, ① 비밀번호 저장(해시), ② 통신(TLS/SSH), ③ 디스크 암호화, ④ 인증 프로토콜처럼 영역별로 나뉘어 동작합니다.

먼저 정리(중요)
비밀번호는 “암호화(encryption)”가 아니라 보통 해시(hash)로 저장합니다.
통신(TLS/SSH)과 디스크는 대칭키 암호(AES/ChaCha20)가 중심입니다.
실제 사용 시에는 “OS 기본값”보다 조직 정책(보안 정책/호환성 요구)이 최종 결정을 좌우합니다.

OS별 기본 사용 경향 한눈에 보기

구분	비밀번호 저장(로컬 계정)	통신(TLS/SSH) 기본 경향	인증(도메인/SSO 등)
CentOS (예: 7 계열)	일반적으로 SHA-512 crypt 계열이 널리 사용/권장되는 구성 (구성에 따라 PAM/login.defs로 결정)	OpenSSL/OpenSSH 기반 레거시 호환을 위해 약한 구성도 남아있을 수 있어 점검 필요	로컬은 PAM, 기업 환경은 AD/LDAP/IPA 연동이 일반적
RockyOS (예: 8/9 계열)	RHEL 계열 정책을 따르며, 로컬 해시는 SHA-512 crypt 또는 yescrypt를 조직 기준으로 선택하는 흐름	시스템 전역 암호 정책(crypto policy)로 TLS/SSH의 약한 알고리즘을 기본 거부하는 구조	SSSD/AD 연동, Kerberos 기반 구성이 흔함
Windows (Server/11)	로컬/AD 계정의 “NT 해시”는 전통적으로 MD4 기반 구조(저장 형식) ※ 저장 형식과 “네트워크 인증 방식”은 다름	Schannel(TLS) 기반 최신 구성은 TLS 1.2/1.3 + 강한 스위트 사용이 일반적	기본 권장: Kerberos(AES 등) 레거시: NTLM/NTLMv2는 축소/제한 흐름

실무 기준으로 보면
“OS 이름별 알고리즘”을 외우는 것보다, 운영 환경에서는 아래 3가지를 분리해서 점검하는 게 더 정확합니다.
1) 로컬 비밀번호 해시(계정 DB) 2) 통신(TLS/SSH) 3) 도메인 인증(Kerberos/NTLM)

1) Linux 계열 (CentOS, RockyOS) 기본 암호화 구성 포인트

로컬 비밀번호 해시( /etc/shadow )

Linux의 로컬 계정 비밀번호는 보통 /etc/shadow에 “해시”로 저장되며, 어떤 해시를 쓰는지는 배포판/버전과 PAM 설정(또는 도구 설정)에 따라 달라집니다.

• SHA-512 crypt: CentOS 7 같은 구형 계열에서 흔한 구성(설정으로 강제하는 사례가 많음)
• yescrypt: 최신 배포판에서 기본/권장으로 확산된 비용 기반 해시
• bcrypt: 일부 환경에서 선택(비용 기반), 시스템/도구 호환성 확인 필요

참고로 ENCRYPT_METHOD 같은 설정은 도구(shadow-utils)와 PAM 구성에 영향을 받습니다. (배포판마다 “어디가 최종 결정권”인지가 다를 수 있어, 운영 표준에서는 PAM/authselect 기준으로 맞추는 편이 안전합니다.)

TLS/SSH: “전역 암호 정책(crypto policy)”

RHEL 8/9 계열(RockyOS 포함)은 시스템 전역 암호 정책으로 TLS/SSH 같은 핵심 통신 스택이 약한 알고리즘을 기본적으로 거부하도록 관리하는 방식이 널리 쓰입니다.

• DEFAULT: 일반 운영에 무난한 기본값
• LEGACY: 구형 장비/서버 호환을 위해 일부 약한 구성을 허용
• FUTURE: 더 강한 기준(호환성 비용 증가)
• FIPS: 규정 준수 환경

“구성 파일을 바꿨는데 반영이 안 된다”는 이 정책 계층 때문인 경우가 많습니다.

디스크 암호화(LUKS)

Linux 디스크 암호화는 보통 LUKS(LUKS2 포함)를 사용하며, 실무에서는 AES-XTS 구성이 가장 흔합니다. 여기서 핵심은 알고리즘 이름보다도 키 길이/파라미터/키 관리(TPM 연동, 패스프레이즈 품질, 복구키 정책)입니다.

2) Windows 기본 암호화/인증 포인트

로컬/AD 비밀번호 저장 형식 vs 네트워크 인증은 다르다

Windows는 계정 비밀번호를 그대로 저장하지 않고 “해시” 형태로 저장합니다. 다만 역사적 이유로 NT 해시가 MD4 기반이라는 점이 자주 언급되는데, 이건 “저장 형식”의 이야기이고, 실제 인증은 Kerberos/NTLM 같은 프로토콜 계층에서 별도 보안이 적용됩니다.

운영 팁
가능하면 Kerberos 중심으로(도메인/SSO) 설계하고,
NTLM은 “어쩔 수 없는 호환성” 범위로만 제한하는 흐름이 일반적입니다.

Kerberos: AES 권장(현대 표준)

AD 환경에서 Kerberos는 현대적인 선택이며, 정책으로 AES 계열 사용을 강제하는 하드닝 가이드가 꾸준히 제시됩니다. 반대로 레거시 암호(RC4 등)는 점진적으로 줄이는 방향이 권장됩니다.

현재 기준 알고리즘 목록(2026년 기준: “많이 쓰이고 표준적으로 안전한 축”)

① 비밀번호 저장(해시/키 유도)

• yescrypt (권장): 비용 기반 해시(크래킹 비용 상승)
• bcrypt (권장): 널리 검증된 비용 기반 해시
• SHA-512 crypt (조건부): 구형 표준으로 여전히 쓰이지만, 비용 기반(yescrypt/bcrypt) 대비 보수적 평가

② TLS(HTTPS 등)

• TLS 1.3 (권장), TLS 1.2 (필요 시 병행)
• AES-GCM (권장), ChaCha20-Poly1305 (권장: 모바일/저전력에서도 강점)
• 서명: ECDSA 또는 RSA 3072+ (환경에 맞게)

③ SSH

• 키 교환/호스트키: ed25519, ecdsa, (필요 시) rsa 3072+
• 대칭키/AEAD: chacha20-poly1305@openssh.com, aes256-gcm@openssh.com
• MAC: hmac-sha2-256/512 계열

④ 디스크 암호화

• AES-XTS (일반적 권장)
• 키 관리: TPM/보안부팅 연계, 복구키/회수 정책(운영 정책이 실제 보안 수준을 좌우)

현재 기준 “안전한 알고리즘”만 골라 말하면

바로 선택해도 되는 권장 조합

• 비밀번호 해시: yescrypt (가능하면) / bcrypt
• TLS: TLS 1.3 + (AES-GCM 또는 ChaCha20-Poly1305)
• SSH: ed25519 + chacha20-poly1305 또는 aes-gcm
• 디스크: LUKS2 + AES-XTS
• Windows 도메인 인증: Kerberos(AES) 우선

피하거나(가능하면) 최소화할 것

• DES/3DES, RC4 (레거시 호환 외에는 지양)
• MD5 (비밀번호 저장/무결성에 사용 지양)
• SHA-1 (서명/인증서/핵심 보안용도 지양)
• NTLMv1/LM (가능하면 사용 금지 수준)

단, “완전 금지”는 조직의 호환성 범위(구형 장비/OS/라이브러리)에 따라 단계적으로 진행하는 게 현실적입니다.

운영 체크 포인트(짧게)

• Linux(RockyOS 포함): 통신은 crypto policy의 영향을 크게 받으니, “OpenSSH 설정만 바꿨는데 왜 약한 알고리즘이 남지?” 같은 이슈를 여기서 먼저 의심합니다.
• 로컬 비밀번호 해시는 “알고리즘 이름”만큼 비용 파라미터(라운드/코스트)가 중요합니다.
• Windows: 저장 형식 논쟁보다, 현실 보안은 Kerberos 우선 + NTLM 최소화가 핵심입니다.

마무리

OS별 기본값은 “대략의 방향”을 이해하는 데 유용하지만, 실제 보안 수준은 결국 정책(crypto policy/도메인 정책)과 운영 설정에서 결정됩니다. 필요한 범위(레거시 호환 포함)를 먼저 확정하고, 그 안에서 yescrypt/AES-GCM/TLS 1.3/Kerberos(AES) 같은 표준 안전 조합을 중심으로 맞추는 게 가장 효율적입니다.