☰

"cryptsetup 벤치마크" 결과를 해석하는 방법은 무엇입니까?

tag-icon • tag-icon luks benchmark cryptsetup
"cryptsetup 벤치마크" 결과를 해석하는 방법은 무엇입니까?

요약:결과를 실행 cryptsetup benchmark하고 정렬할 수 있지만 해석에 대한 지침을 찾고 있습니다. 예를 들어 암호화 속도나 복호화 속도 중 어느 것을 더 중요하게 생각해야 합니까? 키 도출 속도가 우선시되어야 할까요? 내 사용 사례가 결과의 가중치/해석에 어떤 영향을 미쳐야 합니까?

문서에 대한 포인터를 제공해 주셔서 감사합니다. 온라인으로 검색했지만 명확한 내용을 보지 못했습니다. 특히 이건 아닌 것 같다.

세부 사항:

저는 2007년경 노트북에 OS를 재설치할 준비를 하고 있습니다(따라서 아마도 AES에 대한 프로세서 지원은 없을 것입니다). 이번에는 LUKS+LVM2를 사용합니다. (이것이 제가 남겨둔 상자입니다 Plain Old Partitions.) 여러 순차 루프(LUKS + LVM2 + OS 설치, 실제 디스크 벤치마크 실행, 결과 측정)를 실행할 시간이 없습니다. 물론 이는 더 경험적인 지침을 제공할 것입니다. 대신 cryptsetup benchmark"실제 스토리지 암호화 속도를 직접 예측할 수 없다"는 것을 알고 있음에도 불구하고 합리적인(또는 최적의 :-) LUKS 암호 사양 문자열을 "사전 선택"하려고 했습니다 [2].

이 상자가 실행되면 sudo cryptsetup benchmark출력은 다음과 같습니다(레이블을 조정하고 질문을 분리한 후 속도를 줄여서 정렬한 후).

# key derivation:
PBKDF2-sha1       557753 iterations per second
PBKDF2-sha256     356173 iterations per second
PBKDF2-ripemd160  336082 iterations per second
PBKDF2-sha512     256000 iterations per second
PBKDF2-whirlpool  112219 iterations per second

# encryption:
#  Algorithm | Key |  Encryption 
 serpent-xts   512b   144.7 MiB/s     
 serpent-xts   256b   144.0 MiB/s     
 twofish-xts   256b   132.1 MiB/s     
 twofish-xts   512b   132.0 MiB/s     
     aes-xts   256b   128.4 MiB/s     
     aes-cbc   128b   109.7 MiB/s     
 twofish-cbc   256b   108.2 MiB/s     
 twofish-cbc   128b   107.9 MiB/s     
     aes-xts   512b    96.7 MiB/s     
     aes-cbc   256b    86.5 MiB/s     
 serpent-cbc   256b    42.1 MiB/s     
 serpent-cbc   128b    42.1 MiB/s     

# decryption:
#  Algorithm | Key  | Decryption
 serpent-cbc   256b   160.0 MiB/s
 serpent-cbc   128b   159.5 MiB/s
 serpent-xts   512b   149.0 MiB/s
 serpent-xts   256b   148.4 MiB/s
 twofish-cbc   256b   142.1 MiB/s
 twofish-cbc   128b   141.6 MiB/s
 twofish-xts   256b   133.5 MiB/s
 twofish-xts   512b   133.4 MiB/s
     aes-cbc   128b   127.5 MiB/s
     aes-xts   256b   126.0 MiB/s
     aes-cbc   256b    96.0 MiB/s
     aes-xts   512b    95.2 MiB/s

위의 결과는

  1. 암호화: serpent-xts/512가장 빠른 것, serpent-cbc/*가장 느린 것
  2. 해독: serpent-cbc/256가장 빠르고, serpent-xts/512세 번째로 빠름
  3. 주요 내보내기: sha1훨씬 빠르다 sha256훨씬 빠르다sha512

확실하지 않습니다. 믿습니다.

  1. sha1는 곧 폐기될 예정이므로 향후 호환성을 위해 KDF가 에 비해 상당한 속도 이점을 완화(0으로 sha1) 해야 합니다 sha256.
  2. "인증된 사용자가 [워크스테이션에서 키 파생 기능을] 정상적으로 사용하려면 세션당 한 번만 계산하면 됩니다."[3] 따라서 KDF에 비해 KDF의 중요한 sha256이점을 완화해야 합니다 sha512.

구체적인 질문은 다음과 같습니다.

  1. sha256키 파생의 상당한 속도 이점( ~= 0.327)을 더 중요하게 생각해야 합니까 |356173 - 256000| / ((356173 + 256000)/2), 아니면 암호 해독 및 암호화의 적당한 속도 이점 sha512(역시 더 안전하다고 가정함)을 더 중요하게 생각해야 합니까?

보다 일반적인 질문은 다음과 같습니다.

  1. 사용 사례는 키 파생, 암호 해독 및 암호화에서 속도 중요성의 가중치에 어떤 영향을 미칩니까? 예를 들어, 헤드리스 서버는 헤드리스 워크스테이션보다 암호를 해독하는 데(또는 그렇지 않은 경우) 더 많거나 더 적은 시간이 걸립니까? 읽기에서는 암호 해독이, 쓰기에서는 암호화가 수행된다고 가정하지만 하나의 사용 사례가 읽기 및 쓰기의 상대적 발생/가중치에 어떤 영향을 미치는지 모르겠습니다.

FWIW, 내가 설정하고 있는 상자는 이제 머리를 긁적이게 하는 생산 상자의 두 번째 문자열이 될 것이므로 기본적으로 시간이 걸립니다.

  • 편집기 및 브라우저 실행
  • SSH 연결 설정
  • 비디오 및 음악 재생
  • Linux를 사용해보고 싶은 사람들을 위한 대출
  • 첫 번째 프로덕션 노트북을 물에 뿌리면 바로 사용할 준비를 하세요.

(이것이 중요한 경우 데비안을 실행합니다.) 물론 저는 일반적으로 느린 성능보다 빠른 성능을 선호하지만(신뢰성이 높을수록 신뢰성이 낮을수록) 보안에 대한 비용을 기꺼이 지불할 의향이 있습니다. 섹스에는 비용이 듭니다.

보다 일반적인 질문은 다음과 같습니다.

  1. 키 파생, 복호화 및 암호화 속도의 중요성에 대한 일반적인 순위를 매길 수 있습니까? KDF 속도는 덜 중요하다고 생각합니다[3]. 그러나 대부분의 사용 사례에서는 암호 해독 속도와 암호화 속도가 똑같이 중요합니다. (그러나 ICBW.)

  2. 기본적으로 인수 없이 실행하면 cryptsetup benchmark"일부 일반적인 구성만 측정"[2]하고 "다른 암호나 모드를 벤치마킹하려면 --cipher및 --key-size옵션을 지정하거나 --hashKDF 테스트를 수행해야 합니다."[2] .ArchWiki의 이 섹션이를 수행하는 방법에 대한 자세한 내용이 제공되지만 목록 중 하나 이상을 알지 못합니다.

4.1. 기본이 아닌 암호화에 대한 유효한 옵션 매개변수(비밀번호, 해시, 키 크기, 모드)를 지정합니다 cryptsetup benchmark. 누구든지 이것에 대한 권위 있는 문서를 알려줄 수 있습니까?

4.2. 현재 기술과 커널 지원을 고려할 때 기본이 아닌 다른 암호를 지정하고 벤치마킹해야 합니다. 제안해 주셔서 감사합니다(적절한 옵션 인수도 제공한다면 :-)

  1. LUKS 성능을 향상시키는 데 사용할 수 있는 "더 나은" 도구가 있습니까?미리튜닝 비율 cryptsetup benchmark? 그렇다면 무엇입니까? 튜닝하는 방법?

[1]:예를 들어,https://wiki.archlinux.org/index.php/Dm-crypt/Device_Encryption#Encryption_options_for_LUKS_mode,https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata

[2]:달리 info cryptsetup거나man cryptsetup

[삼]:바라보다https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata

답변1

KDF 속도도 중요하지만 생각과는 달리 느려져야 합니다.

LUKS를 사용하면 암호화된 드라이브에는 장치를 암호화하는 데 사용되는 암호화 마스터 키가 포함된 헤더가 포함됩니다. 장치를 부팅하거나 켜면 이 마스터 키는 키 슬롯에 있는 키 중 하나를 사용하여 해독됩니다( cryptsetup luksDump /dev/sdxLUKS 헤더에 포함된 정보를 살펴보세요).

LUKS 장치를 처음 포맷하면 비밀번호(또는 키 파일)를 묻는 메시지가 표시됩니다. 그런 다음 이 비밀번호는 키 슬롯 0에 추가될 키를 생성하고 암호화하는 데 사용됩니다. 귀하의 비밀번호도 해시되어 저장되므로 장치를 켤 때 LUKS가 올바른 비밀번호를 입력했는지 확인할 수 있습니다. 빠른 해싱 알고리즘을 사용하면 공격자가 더 짧은 시간에 더 많은 조합을 테스트할 수 있기 때문에 암호를 해독하기가 더 쉽기 때문에 이를 이해하는 것이 중요합니다.

따라서 가장 느리고 가장 안전한 해싱 알고리즘(sha512 또는 Whirlpool)을 선택하고 더 높은 --iter-time을 사용해야 합니다. --iter-time 옵션을 사용하면 1회 해시 반복에 필요한 시간을 설정할 수 있습니다. 높은 반복 시간의 유일한 단점은 암호화된 장치를 실제로 여는 데 시간이 너무 오래 걸린다는 것입니다. 루팅된 장치에서 --iter-time 10000(10초)을 사용한다고 가정하면 시스템이 실제 암호화 키를 가져오는 데 10초가 걸리므로 비밀번호를 입력한 후 부팅을 계속하기 전에 오랫동안 기다려야 합니다. . 이는 장치를 켤 때 한 번만 발생하므로 추가 성능에는 영향을 미치지 않습니다.

실제 암호화된 비밀번호는 기본 물리적 장치의 읽기/쓰기 속도와 머신의 작업 부하에 따라 달라집니다. 암호화/복호화는 CPU에서 수행되므로 가장 느린 CPU를 사용하면 동시에 실행되는 다른 프로그램에 영향을 미칠 가능성이 높습니다. 현재로서는 aes-xts-plain64가 가장 안전한 LUKS 암호로 간주되므로 매우 기밀 정보가 있는 경우 키 크기가 512인 aes-xts-plain64를 사용해야 할 것입니다(xts를 사용하면 키가 분할되기 때문입니다). 2 따라서 실제로 256비트 키로 aes를 얻습니다.)

귀하의 설정에 대한 제안을 한다면 반복 시간이 2초에서 10초 사이인 해싱 알고리즘으로 sha512가 될 것이며 AES-128은 여전히 ​​안전한 것으로 간주되므로 키 크기가 256인 aes-xts-plain64를 사용하는 것입니다. .

관련 정보