Nexus-Q는 여섯 계열로 암호화 기능을 제한한다

Nexus-Q는 핵심에서 쓸 수 있는 암호 기능을 여섯 계열로 제한합니다. 양자내성 암호(post-quantum cryptography)를 포함한 Rust 오픈소스 프로젝트입니다. 기본 RSA나 자체 제작 메시지 인증 코드(message authentication code, MAC)도 허용하지 않습니다. 저는 여섯 계열이라는 숫자보다 범위 밖 방식을 명시적으로 막은 데 눈이 갔습니다. 기본 RSA와 자체 제작 MAC까지 허용하지 않으니, 선택의 경계를 프로젝트 규칙으로 못 박았다는 점이 오래 남습니다.

Clor는 저장된 에이전트 자격 증명을 AES-256-GCM으로 암호화하고, 비밀값마다 별도 키를 파생합니다. Nexus-Q도 AES-256-GCM을 허용 목록에 두므로, 암호 선택의 범위는 실제 자격 증명 보관 방식과 이어집니다.

반가운 점은 여섯 계열을 선언하는 데 그치지 않고, 현재 구현된 알고리즘까지 이름을 공개한다는 것입니다. 해싱(hashing)에는 SHA-2와 SHA-3를 씁니다. 인증 암호화(authenticated encryption)에는 AES-256-GCM과 ChaCha20-Poly1305를 둡니다. 계획한 알고리즘은 구현하고 테스트하기 전까지 사용 가능한 기능으로 소개하지 않습니다.

여섯 계열로 좁혔다고 보안성이 저절로 입증되는 것은 아닙니다. 계획 중인 알고리즘은 구현하고 테스트하기 전까지 사용 가능한 기능으로 소개되지 않습니다. 상대 시스템이 기본 RSA만 받으면 Nexus-Q의 핵심과 연결할 수 없습니다. 그래서 암호 선택은 라이브러리의 범위와 상대 시스템의 요구를 함께 맞추는 일이 됩니다.

Nexus-Q 문서에서 실제 구현된 알고리즘이 필요한 기능과 일치하는지 확인하고, 상대 시스템의 요구 조건과도 대조해 보십시오. 테스트 환경에서 한쪽이 암호화(encryption)한 데이터를 다른 쪽에서 복호화(decryption)할 수 있는지 시험해 보십시오. 실패한다면 먼저 알고리즘 호환성부터 확인할 수 있습니다.

마지막으로 두 시스템 사이의 암호 알고리즘 호환성을 직접 확인하신 것은 언제입니까?