저는 현재 이론적, 실무적으로 RSA 키를 더 잘 이해하기 위해 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가 키 생성을 위해 사용자 공간에서 0 CPU-초가 걸렸다는 대답을 제공하는 이유는 무엇입니까? 다른 프로세스에서 수행됩니까?
- 키를 생성하는 데 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_availGnuPG가 "낮은 엔트로피" 모드로 실행될 때를 이해하기 위해 추가 터미널에서 실행하는 것이 좋습니다 .
현재 하드웨어 플랫폼에서는 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 대기에서 차단되었으므로 전체 실행 시간 중 실제 계산 시간이 차지하는 부분이 훨씬 더 큽니다.