저는 현재 RSA 키를 이론적으로나 실제적으로 더 잘 이해하기 위해 연구하는 고등학교 프로젝트를 진행하고 있습니다. 프로젝트의 일부는 다양한 길이의 RSA 키를 생성할 때 CPU가 수행하는 작업의 양을 확인하기 위해 테스트하기로 선택한 실험이었습니다. 또한 결론을 도출해야 할 경우 데이터 포인트로 시간을 절약하고 싶습니다.
컴퓨터는 Ubuntu 16.04를 실행 중이며 애플리케이션은 기본 저장소에서 다운로드되었습니다.
계획은 GnuPG를 사용하여 다양한 길이(1024, 2048 및 4096)의 RSA 키를 생성하고 GNU Time을 사용하여 CPU의 작업량과 프로세스를 실행하는 데 걸린 시간을 가져오는 것입니다. 이 프로세스는 다음과 같이 Python 스크립트를 사용하여 자동화됩니다.
[1024, 2048, 4096] 길이의 경우:
1.1. X번:
1.1.1. Gnu PG 명령 실행 및 시스템 리소스 모니터링
1.1.2. 시스템 리소스 사용량을 파일에 기록합니다.
그런 다음 내 가설이 올바른지 확인하기 위해 몇 가지 그래프를 그릴 것입니다.
그런데 GnuPG 테스트 구현에 관해 몇 가지 질문이 있습니다. 질문 후에 구현이 어떻게 작동하는지 설명합니다. 내 질문은 다음과 같습니다
- 이 설정으로 내가 원하는 효과를 얻을 수 있나요?
- 해지된 인증서의 자동 생성을 비활성화할 수 있나요?
- 일부 키를 생성하는 데 시간이 더 오래 걸리는 이유는 무엇입니까?
- GnuPG가 사용자 공간에서 키를 생성하는 데 CPU 초가 0이라는 대답을 제공하는 이유는 무엇입니까? 다른 프로세스에서 수행됩니까?
- 키 생성 시간이 1초 미만(벽시계 > 1)일 때 CPU 워크로드 매개변수에 값(0 < CPU)만 표시되는 이유는 무엇입니까?
--batch
매뉴얼을 읽어보면 키를 생성하는 가장 쉬운 방법은 해당 옵션을 켜는 것 같습니다 . 파일의 옵션을 다음과 같이 설정했습니다.
# Text syntax in this file
#%dry-run
%echo Generating RSA key...
# Don't ask after passphrase
%no-protection
Key-type: RSA
Key-Length: 1024
Name-Real: Real Name
Name-Email: [email protected]
Expire-Date: 0
# Generate RSA key
%commit
%echo Done!
이 파일을 실행하는 명령은 Gnu Time 부분과 GnuPG 부분의 두 부분으로 구성됩니다. GNU Time 명령은 다음과 같습니다:
$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%"
GnuPG 명령은 다음과 같습니다.
$ gpg2 --gen-key --homedir=./rsa-keys --batch [filename]
쉘에서 실행하는 명령(중요한 경우 Fish 쉘 사용)은 다음과 같습니다(GNU Time + GnuPG):
$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%" gpg2 --gen-key --homedir=./rsa-keys --batch [filename]
명령 출력:
Wall clock: 36.83[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.04[s], CPU (userspace): 0.00[s], CPU (workload): 8%
Wall clock: 4.76[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 72.39[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 57.52[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 84.71[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 63.32[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.10[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 47.58[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 64.72[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.05[s], CPU (userspace): 0.00[s], CPU (workload): 6%
Wall clock: 0.03[s], CPU (userspace): 0.00[s], CPU (workload): 11%
Wall clock: 29.62[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 55.02[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 36.08[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 42.92[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 40.41[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 204.36[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 246.42[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.50[s], CPU (userspace): 0.00[s], CPU (workload): 0%
답변1
GnuPG는 를 읽고 /dev/random
엔트로피가 충분하지 않을 때 차단합니다(논란의 여지가 있는 행위입니다). 실제 계산 노력은 무시할 수 있습니다. 엔트로피 풀이 여전히 "새 비트"로 가득 차 있기 때문에 처음/몇 번의 실행이 더 빨리 종료되는 것을 볼 수도 있습니다. watch cat /proc/sys/kernel/random/entropy_avail
GnuPG가 언제 "낮은 엔트로피" 모드로 실행되는지 확인하려면 추가 터미널에서 실행하는 것이 좋습니다 .
현재 하드웨어 플랫폼에서는 IO 또는 절전 모드로 인해 차단된 프로세스가 백그라운드에 배치되므로 CPU 시간이 계산되지 않습니다.
$ time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' sleep 5
Wall clock: 5.00[s], CPU (userspace): 0.00[s], CPU (workload): 0%
이는 다음에서 일부 바이트를 복사할 때도 발생할 수 있습니다. /dev/random
(특히 가상 머신에서는 시간이 꽤 걸릴 수 있습니다.)
time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' dd if=/dev/random of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes copied, 210.672 s, 0.0 kB/s
Wall clock: 210.67[s], CPU (userspace): 0.00[s], CPU (workload): 0%
마지막으로 이는 빠른 반복으로 인해 CPU 작업 부하가 높아지는 이유도 설명합니다. 프로세스가 IO 대기에서 더 짧은 시간 동안 차단되므로 실제 계산 시간이 전체 실행 시간에서 훨씬 더 큰 부분을 차지합니다.