Concryptor

Rust로 작성된 멀티스레드 AEAD 암호화 엔진입니다. 삼중 버퍼 io_uring 파이프라인, Rayon을 통한 병렬 청크 처리, ring을 통한 어셈블리 최적화 암호를 사용하여 기가바이트/초 처리량으로 파일을 암호화 및 복호화합니다.

⚠️ 면책 조항: 실험적 소프트웨어 ⚠️

이 프로젝트는 매우 초기 단계이며 현재 프로덕션 또는 중요 업무용으로 권장되지 않습니다. 암호화 프리미티브(AES-256-GCM, ring을 통한 ChaCha20-Poly1305)와 형식 설계는 건전하지만, 코드베이스는 공식적인 보안 감사나 광범위한 실제 테스트를 거치지 않았습니다. 사용자는 자신의 책임 하에 사용하십시오. 중요한 데이터를 보호하려면 이 프로젝트가 성숙해질 때까지 GnuPG, age, OpenSSL과 같은 검증된 도구를 사용하는 것이 좋습니다.

특징

• 이중 암호 지원: ring을 통한 AES-256-GCM (하드웨어 AES-NI) 및 ChaCha20-Poly1305 (어셈블리 최적화)
• 병렬 암호화: Rayon 기반의 멀티스레드 청크 처리가 모든 CPU 코어에서 실행됨
• 삼중 버퍼 io_uring 파이프라인: 세 개의 회전 버퍼 풀을 사용하여 커널 I/O와 CPU 측 암호화를 오버랩 — 한 배치의 쓰기가 진행 중인 동안, 다음 배치는 Rayon에 의해 암호화되고, 세 번째 배치의 읽기는 진행 중입니다. 청크당 시스템 콜 오버헤드가 없으며, mmap 제한(SIGBUS 없음, 가상 주소 공간 소진 없음)이 없습니다.
• Argon2id 키 유도: 업계 표준 패스워드-투-키 스트레칭 (기본값 256 MiB 메모리, 3회 반복, --memory로 설정 가능)
• 자체 기술 KDF 매개변수: 메모리 비용, 반복 횟수, 병렬 처리가 암호화된 파일 헤더에 저장되므로 복호화 시 암호화 시 선택한 매개변수를 정확히 사용합니다. 레거시 파일(모두 0인 센티넬)은 이전 64 MiB 기본값으로 투명하게 처리됩니다.
• 청크 인덱스 논스: TLS 1.3 스타일 XOR 논스 유도로 청크 재정렬 공격을 방지합니다.
• 헤더 인증 AAD: 전체 4 KiB 정렬 헤더가 모든 청크의 AAD에 포함되어, 모든 헤더 필드(코어, KDF 매개변수, 예약 바이트)를 인증하고 잘림, 헤더 필드 조작, 예약 바이트 밀수 공격을 방지합니다.
• STREAM 스타일 최종 청크: AAD의 최종 청크 플래그가 잘림 및 추가 공격을 방지합니다 (STREAM 구조에서 영감).
• 파일당 새로운 무작위성: 모든 암호화에 대해 암호학적으로 무작위적인 16바이트 솔트와 12바이트 기본 논스가 생성되어 헤더에 저장됩니다.
• 제자리 암호화: ring을 통한 seal_in_place_separate_tag / open_in_place로 핫 루프에서 할당을 최소화합니다.
• 패스워드 초기화: 키와 패스워드는 사용 후 메모리에서 안전하게 지워집니다.
• O_DIRECT + 섹터 정렬 형식: 4 KiB 정렬 헤더와 청크 슬롯은 O_DIRECT I/O를 가능하게 하여 NVMe에서 커널 페이지 캐시를 우회하고 DMA 속도의 읽기/쓰기를 제공합니다. 버퍼 풀은 4096바이트 정렬로 std::alloc을 사용합니다.
• 디렉터리 암호화: 전체 디렉터리를 단일 암호화된 아카이브로 암호화합니다. Tar 기반 패킹은 파일 이름, 권한, 타임스탬프 및 디렉터리 구조를 암호문 내에 보존합니다. 추출 시 경로 순회 및 심볼릭 링크 이스케이프 공격을 검증합니다.
• 자체 기술 파일 형식: 헤더는 암호, 청크 크기, 원본 파일 크기, 솔트, 기본 논스 및 Argon2id KDF 매개변수를 저장합니다.

성능

cargo bench (Criterion, 측정당 10개 샘플)로 벤치마크됨. 키 유도는 제외됨 — 수치는 순수 암호 처리량만 반영합니다.

하드웨어:

• CPU: AMD Ryzen 5 5600X (6코어/12스레드 @ 3.7 GHz 기본)
• RAM: 2x 8 GiB DDR4-2666 (듀얼 채널, 총 16 GiB)
• OS: Linux

I/O 참고: Criterion은 /tmp에 임시 파일을 쓰며, 이 시스템에서는 tmpfs (RAM 기반)입니다. O_DIRECT를 사용하면 커널이 tmpfs에서 실제 비동기 DMA를 사용할 수 없으므로, 이 수치는 DMA 우회 이점 없이 암호 처리량 + io_uring 오버헤드를 반영합니다. 실제 Gen4 NVMe 드라이브에서 O_DIRECT는 페이지 캐시 이중 버퍼링을 제거하고 정렬된 버퍼 풀로 직접 DMA를 가능하게 하여 훨씬 더 높은 처리량을 제공해야 합니다.

청크 크기 스윕 (AES-256-GCM, 64 MiB 파일):

성능 특성

엔진은 암호 연산에 ring (어셈블리 최적화 AES-NI / NEON / ARMv8-CE)을 사용하고 I/O에 삼중 버퍼 io_uring 파이프라인을 사용합니다. 세 개의 미리 할당된 버퍼 풀이 파이프라인을 통해 회전합니다. 풀 A의 쓰기가 커널에서 완료되는 동안, 풀 B는 CPU에서 Rayon에 의해 암호화되고, 풀 C의 읽기는 커널에 제출됩니다. 이는 I/O 지연 시간을 암호화 계산과 오버랩합니다.

작은 파일에서 AES-256-GCM이 ChaCha20-Poly1305보다 빠른 이유: ring의 AES-GCM 백엔드는 x86-64에서 사용 가능한 AES-NI + CLMUL 하드웨어 명령어를 활용하여 ChaCha20 (소프트웨어 암호)보다 하드웨어 이점을 가집니다. 더 큰 크기에서는 두 암호가 약 1.0 GiB/s로 수렴하여, 병목이 암호 처리량에서 I/O 제출 오버헤드로 이동함을 나타냅니다.

왜 최대 처리량이 256 MiB가 아닌 1-16 MiB에 있는가: 작은 파일(1-16 MiB)은 청크 수가 적어 Rayon 병렬 처리가 효율적이고 작업 세트가 캐시에 맞습니다. 64-256 MiB에서는 io_uring 파이프라인이 완전히 활성화되지만(세 배치가 진행 중), SQE 제출 및 CQE 완료 오버헤드는 청크 수에 따라 증가합니다. 삼중 버퍼 설계는 I/O와 암호화를 오버랩하여 이 비용을 부분적으로 숨깁니다.

왜 ~1.0 GiB/s이고 10+ GiB/s가 아닌가: 최신 AES-NI는 코어당 2-4 GiB/s를 푸시할 수 있습니다. 12개 스레드에서 원시 암호 처리량은 10 GiB/s를 초과할 수 있습니다. 세 가지 요인이 차이를 설명합니다:

1. io_uring SQE당 오버헤드: 각 청크는 읽기 SQE와 쓰기 SQE가 필요합니다. 256 MiB 파일의 경우 256개 청크에 대해 512개의 SQE가 제출되고 512개의 CQE가 수집됩니다. io_uring은 pread/pwrite의 시스템 콜당 커널 전환 비용을 피하지만, 여전히 SQE당 링 버퍼 및 메모리 장벽 오버헤드가 있습니다.
2. 파이프라인 깊이: PIPELINE_DEPTH=3에서는 한 번에 세 개의 배치만 파이프라인을 통해 회전합니다. 진정한 정상 상태 오버랩을 위해서는 최소한 세 개의 배치가 필요합니다. 한두 개의 배치에 맞는 파일은 파이프라인 효과를 보지 못합니다.
3. 캐시 계층 효과: 5600X는 코어당 512 KiB L2와 32 MiB 공유 L3를 가지고 있습니다. 기본 4 MiB 청크는 L2를 초과하며, 약 21개 청크의 배치(84 MiB 활성 작업 세트)는 L3를 크게 초과합니다. 더 작은 청크 크기(64-256 KiB)는 청크 스윕에서 더 나은 처리량을 보이는데, 이는 더 많은 작업 세트가 캐시에 남아 있기 때문입니다.

버퍼 수명 주기 및 안전성: 버퍼 풀은 io_uring 링이 생성되기 전에 std::alloc::alloc_zeroed와 Layout::from_size_align(size, 4096)을 사용하여 한 번 할당되며, 모든 파이프라인 반복에서 재할당 없이 재사용됩니다. 각 암호화된 청크는 O_DIRECT 쓰기 전에 섹터 정렬로 0으로 패딩됩니다. 링은 버퍼 풀보다 먼저 명시적으로 해제되므로 커널이 해제된 메모리를 참조하지 않습니다 (UAF 없음).

설치

git clone https://github.com/frogsnot/concryptor.git
cd concryptor
cargo build --release

바이너리는 target/release/concryptor에 있습니다.

사용법

암호화

# AES-256-GCM (기본), 출력 myfile.dat.enc
concryptor encrypt myfile.dat

# ChaCha20-Poly1305, 사용자 정의 출력 경로
concryptor encrypt myfile.dat --cipher chacha -o encrypted.enc

# 사용자 정의 청크 크기 (MiB 단위)
concryptor encrypt largefile.iso --chunk-size 8

# 더 강력한 KDF (512 MiB 메모리 비용)
concryptor encrypt secrets.tar --memory 512

# 비대화형 (암호 프롬프트 건너뛰기)
concryptor encrypt myfile.dat -p "password"

보안 참고: --password / -p는 패스워드를 CLI 인수로 전달하며, 이는 ps 출력 및 셸 기록에 표시됩니다. 대화형 사용 시 이를 생략하면 안전한 숨겨진 프롬프트를 얻을 수 있습니다. 스크립팅의 경우, 기록을 나중에 지우거나 파일 디스크립터에서 읽는 래퍼를 사용하는 것이 좋습니다.

디렉터리 암호화

# 디렉터리 암호화 (자동 감지, mydir.tar.enc 생성)
concryptor encrypt mydir/

# 사용자 정의 암호 및 출력
concryptor encrypt mydir/ --cipher chacha -o secrets.enc

디렉터리 암호화는 임시 tar 아카이브(.concryptor-*.tar, 0600 권한, CSPRNG 이름)를 생성하고, 이를 암호화한 후 임시 파일을 자동으로 삭제합니다. 파일 이름, 디렉터리 구조, 권한, 타임스탬프는 모두 암호화된 페이로드 내에 있습니다.

복호화

# .enc 확장자 자동 제거
concryptor decrypt myfile.dat.enc

# 사용자 정의 출력 경로
concryptor decrypt encrypted.enc -o restored.dat

# 비대화형
concryptor decrypt myfile.dat.enc -p "password"

디렉터리 복호화 및 추출

# 복호화 및 추출을 한 번에 (.tar.enc 자동 제거 -> 디렉터리 이름)
concryptor decrypt mydir.tar.enc --extract

# 짧은 플래그, 사용자 정의 출력 디렉터리
concryptor decrypt mydir.tar.enc -x -o restored_dir/

--extract 없이 디렉터리 아카이브를 복호화하면 중간 .tar 파일이 생성되며, 이를 검사하거나 수동으로 추출할 수 있습니다.

도움말

concryptor --help
concryptor encrypt --help
concryptor decrypt --help

파일 형식

모든 값은 리틀 엔디언입니다. 헤더는 전체 4 KiB 섹터를 차지하며, 각 암호화된 청크 슬롯은 다음 4 KiB 경계까지 패딩됩니다. 이렇게 하면 모든 오프셋과 I/O 크기가 O_DIRECT에 대해 섹터 정렬됩니다.

오프셋  크기   필드
------  -----  ---------------------
0       10     매직 바이트 "CONCRYPTOR"
10       1     형식 버전 (4)
11       1     암호 유형 (0 = AES-256-GCM, 1 = ChaCha20-Poly1305)
12       4     청크 크기 (바이트, LE)
16       8     원본 파일 크기 (바이트, LE)
24      16     Argon2 솔트 (암호학적으로 무작위, 파일당 고유)
40      12     기본 논스 (암호학적으로 무작위, 파일당 고유)
52       4     Argon2 m_cost (KiB 단위, LE, 0 = 레거시 64 MiB)
56       4     Argon2 t_cost / 반복 횟수 (LE, 0 = 레거시 3)
60       4     Argon2 p_cost / 병렬 처리 (LE, 0 = 레거시 4)
64    4032     예약됨 (4096 바이트로 0 패딩)
4096    ...    [청크 0: 암호문 + 16바이트 태그 + 섹터 경계까지 0 패딩]
               [청크 1: 암호문 + 16바이트 태그 + 섹터 경계까지 0 패딩]
               ...

4 MiB 청크의 경우: 각 디스크 슬롯은 ceil((4194304 + 16) / 4096) * 4096 = 4198400 바이트입니다 (청크당 4080 바이트 패딩). 헤더의 예약된 4032 바이트는 향후 기능(비대칭 키 슬롯, 메타데이터 등)에 사용할 수 있습니다.

솔트와 기본 논스는 매 암호화마다 rand::rng() (OS CSPRNG 지원)에서 새로 생성됩니다. 다른 파일에 대해 패스워드를 재사용하는 것은 안전합니다. 다른 솔트는 다른 Argon2id 키를 생성하고, 다른 기본 논스는 다른 청크당 논스를 생성하기 때문입니다.

보안 설계

• 논스 유도: chunk_nonce = base_nonce XOR chunk_index (TLS 1.3 스타일). 청크를 바꾸면 복호화에 실패합니다. N 위치의 논스가 M 위치의 청크를 암호화하는 데 사용된 논스와 일치하지 않기 때문입니다. 참고: XOR 기반 논스 유도는 동일한 키가 여러 스트림에서 사용될 때 이론적 약점이 있습니다 (서로 다른 기본 논스가 중복되는 논스 공간을 생성할 수 있음). 이는 각 암호화가 새로운 128비트 무작위 솔트를 생성하여 파일당 고유한 Argon2id 키를 생성하므로 Concryptor에는 적용되지 않습니다. 논스 고유성은 동일한 키에서만 중요하며, 키 재사용 확률은 파일 쌍당 ~2^-128입니다.
• 헤더 인증 AAD: 모든 청크의 AEAD 호출은 AAD = full_aligned_header (4096) || chunk_index (8 LE) || is_final (1) (총 4105 바이트)를 사용합니다. 전체 4 KiB 헤더 섹터(코어 필드, KDF 매개변수, 예약 패딩)가 모든 청크의 인증 태그에 바인딩됩니다. 모든 헤더 바이트(암호 유형, 청크 크기, 원본 크기, 솔트, 논스, KDF 매개변수, 예약 패딩)를 수정하면 모든 청크가 무효화됩니다. 이는 공격자가 original_size를 편집하고 후행 청크를 제거하는 잘림 공격을 방지하고, 예약 패딩 영역에 데이터를 밀수하는 것도 방지합니다. 레거시 v3 파일은 이전 버전과의 호환성을 위해 52바이트 AAD로 복호화됩니다. v4에서 v3로의 다운그레이드는 버전 바이트 자체가 인증된 AAD 내에 있으므로 불가능합니다.
• STREAM 스타일 최종 청크 표시기: AAD의 마지막 바이트는 최종 청크의 경우 0x01, 다른 모든 청크의 경우 0x00입니다. 이는 두 가지 공격을 방지합니다:
  • 잘림: 최종 청크를 제거하고 비최종 청크를 끝으로 승격시키면 비최종 청크가 is_final = 0x00으로 암호화되었지만 복호화는 0x01을 예상하므로 실패합니다.
  • 확장: 위조된 청크를 추가하면 공격자가 키 없이 is_final = 0x01에 대한 유효한 태그를 생성할 수 없으므로 실패합니다.
• 파일당 새로운 무작위성: 모든 암호화에 대해 16바이트 솔트와 12바이트 기본 논스가 OS CSPRNG (rand::rng())에서 추출됩니다. 동일한 패스워드로 동일한 파일을 두 번 암호화하면 완전히 다른 암호문이 생성됩니다. 논스 재사용(AES-GCM에 치명적)은 구조적으로 피해집니다.

테스트

# 전체 테스트 스위트 실행 (67개 테스트)
cargo test

# 벤치마크 실행 (HTML 보고서는 target/criterion/에)
cargo bench

# 벤치마크 필터링
cargo bench -- "encrypt/AES"
cargo bench -- "chunk_sweep"

테스트 스위트는 다음을 포함합니다:

• 헤더 직렬화/역직렬화 왕복
• 키 유도 결정론 및 민감도
• 논스 고유성 및 동일성 속성
• 두 암호에 대한 파일 크기별(빈 파일, 1바이트, 경계 사례, 여러 청크) 암호화/복호화 왕복
• 잘못된 패스워드 거부
• 변조 감지(암호문 뒤집기, 태그 손상, 솔트 손상, 잘린 파일)
• 청크 재정렬 공격 감지
• 암호 유형 불일치 감지
• 잘림 공격 감지 (수정된 original_size + 제거된 청크)
• 헤더 필드 조작 감지 (수정된 chunk_size)
• 예약 헤더 바이트 변조 감지 (수정된 패딩 영역)
• 비결정적 암호화 검증
• 256개 작은 청크를 사용한 스트레스 테스트
• 디렉터리 아카이브 팩/언팩 왕복 (두 암호)
• 빈 디렉터리, 깊게 중첩된 디렉터리, 많은 파일, 바이너리 콘텐츠 왕복
• 유효한 내부 링크에 대한 심볼릭 링크 보존
• 추출 루트를 벗어나는 심볼릭 링크 거부 (절대 및 상대 경로 순회)
• Drop 시 임시 파일 자동 정리
• 암호화된 아카이브에 대한 잘못된 패스워드 거부

종속성

설치

# crates.io에서 (권장)
cargo install concryptor

# 소스에서
git clone https://github.com/FrogSnot/Concryptor
cd Concryptor
cargo build --release
# 바이너리는 target/release/concryptor에 있습니다.

라이선스

이 프로젝트는 GNU Affero General Public License v3.0에 따라 라이선스가 부여됩니다.