RSA 2048 generasi keypair: via openssl 0.5s via gpg 30s, mengapa bedanya?


9

RSA 2048 generasi keypair: via openssl 0.5s via gpg 30s, mengapa bedanya Ada beberapa program yang dapat meningkatkan RSA public / private keypairs

GnuPG / OpenPGP misalnya memiliki wizzard yang diikutsertakan

gpg --gen-key

OpenSSL dapat menghasilkan keypair menggunakan baris perintah tesis ini

openssl genrsa -out testkey.private 2048
openssl rsa -in testkey.private -pubout -out testkey.public

untuk hal yang sama, yaitu menghasilkan bit RSA 2048 keypair yang saya dapat rasakan - pada mesin yang sama - waktu yang sangat berbeda.

opensslmenghasilkan keypair di sekitar 0,5s
gpgmembutuhkan waktu sekitar 30 dan bahkan iklan "gerakkan mouse untuk menghasilkan keacakan / entropi"

Bisakah perbedaannya dijelaskan? Saya tahu bahwa gpg melakukan beberapa littel lebih dari sekadar pembuatan kunci RSA, namun saya secara khusus memilih opsi (4)

Silakan pilih jenis kunci yang Anda inginkan:
   (1) RSA dan RSA (default)
   (2) DSA dan Elgamal
   (3) DSA (hanya masuk)
   (4) RSA (hanya masuk)
Pilihan Anda?

Oleh karena itu satu-satunya hal yang dihasilkan adalah keypair RSA 2048bit. Namun perbedaan waktu adalah 30 detik?

Bagi saya tampaknya gpg membuang-buang waktu atau OpenSSL tidak menunggu cukup waktu dan karenanya membuat kunci tidak aman.

Pertanyaan saya adalah apa yang bisa menjelaskan perbedaannya?

Memperbarui

Pembuatan RSA harus sebagai input keacakan. Oleh karena itu untuk memastikan bahwa openssl yang cepat bukan hanya hasil dari menggunakan beberapa keacakan disimpan saya batchrun beberapa kali

time bash -c "for i in {1..50}; do openssl genrsa -out / dev / null 2048; selesai;"

yang menghasilkan

0m16.577s asli
pengguna 0m16.309s
sys 0m0.092s

yaitu bahwa untuk 50 2048bits kunci RSA (saya berasumsi perlu banyak entropi / keacakan) openssl masih hanya diperlukan 16 detik. Asumsi saya di sini karenanya akan menjadi "jawaban" yang openssl harus dilanggar. Bagaimanapun saya tidak percaya Linux saya (kernel 3.2.0-59) telah menjadi sangat hebat dalam menghasilkan keacakan.

Mungkin perbedaannya hanyalah penggunaan openssl /dev/urandomdan penggunaan gpg /dev/randomyang jika benar dapat menjelaskan perbedaan waktu masalah saya adalah bahwa saya tidak tahu bagaimana saya akan mencari tahu tentang hal ini, untuk memverifikasi ini.

pembaruan2

Untuk menguji sumber acak openssl saya gunakan

strace -xe trace = file, baca, tulis, tutup openssl genrsa -out testkey5.private 2048 2> & 1 | grep acak -A1

yang menghasilkan

open ("/ dev / urandom", O_RDONLY | O_NOCTTY | O_NONBLOCK) = 4
baca (4, "\ x21 \ xd8 \ xaa \ xf1 \ x2b \ x5f \ x4a \ x89 \ x5d \ x6c \ x58 \ x82 \ xc1 \ x88 \ x21 \ x04 \ xfa \ x5b \ x18 \ x8a \ x8 \ \ x2b \ xe3 \ xf3 \ xc0 \ xb1 \ xef \ xfb \ x44 \ x15 \ x09 ", 32) = 32

sehingga tampaknya 32 byte dari /dev/urandom(bukan yang "lebih baik" /dev/random) sudah cukup untuk keypair RSA 2048bit di openssl. Karena itu sangat cepat!

Pengukuran

RS48 menghasilkan generasi 2048bit berarti

  • Hanya 32 byte /dev/urandom(menggunakan openssl)
  • 300 byte /dev/random(menggunakan openPGP GNU Privacy Guard)

ini tentu saja menjelaskan perbedaan waktu!

Jawaban:


10

GnuPG mengkonsumsi beberapa byte dari /dev/randomuntuk setiap byte acak yang sebenarnya digunakannya. Anda dapat dengan mudah memeriksanya dengan perintah ini:

start cmd:> strace -e trace=open,read gpg --armor --gen-random 2 16 2>&1 | tail
open("/etc/gcrypt/rngseed", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\\\224F\33p\314j\235\7\200F9\306V\3108", 16) = 16
open("/dev/random", O_RDONLY)           = 4
read(4, "/\311\342\377...265\213I"..., 300) = 128
read(4, "\325\3\2161+1...302@\202"..., 172) = 128
read(4, "\5[\372l\16?\...6iY\363z"..., 44) = 44
open("/home/hl/.gnupg/random_seed", O_WRONLY|O_CREAT, 0600) = 5
cCVg2XuvdjzYiV0RE1uzGQ==
+++ exited with 0 +++

Untuk menghasilkan 16 byte dari entropi berkualitas tinggi, GnuPG membaca 300 byte dari /dev/random.

Ini dijelaskan di sini: Arsitektur Subsistem Angka-Acak

Linux menyimpan maksimum 4096 byte (lihat cat /proc/sys/kernel/random/poolsize) entropi. Jika suatu proses membutuhkan lebih dari yang tersedia (lihat cat /proc/sys/kernel/random/entropy_avail) maka penggunaan CPU menjadi lebih atau kurang relevan karena kecepatan makan dari kumpulan entropi kernel menjadi faktor yang relevan.


Impresif. Terima kasih untuk wawasan. Saya pikir itu cukup mencerahkan sehubungan dengan pertanyaan itu! Jadi sepertinya openssl puas dengan 32bytes /dev/urandomgpg berkualitas kurang bahkan mengatakan "1 byte /dev/randomtidak cukup baik untuk 1 byte acak". Apakah ini tidak berarti bahwa kunci openssl lebih rentan terhadap "terlalu sedikit keacakan" dibandingkan dengan gpg?
humanityANDpeace

1
@humanityANDpeace Randomness adalah diskusi tanpa akhir. Belum lama ini "pengguna utama" dari situs ini membuat klaim yang /dev/urandomcukup baik untuk keperluan crypto. Di milis GnuPG dia mungkin akan ditertawakan untuk itu. AFAIK tidak mungkin untuk membuktikan bahwa data tertentu adalah murni acak. Anda dapat menemukan non-keacakan tetapi hanya di mana Anda mencari pola itu.
Hauke ​​Laging

ya saya melihat :) Masih fakta bahwa gpg menggunakan 300bytes /dev/randomsementara openssl hanya menggunakan 32bytes /dev/urandomtampaknya menunjukkan potensi risiko keamanan bagi pengguna yang berhati-hati bagaimana menginginkan keypair RSA 2048bit. Karenanya saya akan memilih gpg. 32bytes tampaknya sangat kecil
humanityANDpeace

2
@ HaukeLaging “pengguna master” dari situs ini mendapatkan saran ini dari “pengguna utama” Keamanan Informasi dan Kriptografi , dengan penjelasan yang masuk akal (tidak seperti perhitungan ukuran kolam entropi Linux, yang tidak). Apakah rand dari / dev / urandom aman untuk kunci masuk? “Jawaban singkatnya adalah ya. Jawaban panjangnya juga ya. ”
Gilles 'SO- stop being evil'

2
32 byte dibaca dari CSPRNG yang diunggulkan dengan baik memberikan keamanan 256 bit (yang sangat banyak ). Kunci RSA-2048 bit hanya menawarkan keamanan sekitar 112 bit. Satu-satunya properti yang meragukan /dev/urandomadalah bahwa (di linux) tidak memblokir sebelum diunggulkan langsung setelah boot. Setelah diunggulkan, itu akan tetap aman selamanya.
CodesInChaos

7

Saran Anda bahwa perbedaan ini adalah karena opensslpenggunaan / dev / urandom dan gpgpenggunaannya /dev/randombenar.

Anda dapat menonton entropi yang tersedia turun saat membuat kunci dengan gpgmenggunakan:

watch -n 1 cat /proc/sys/kernel/random/entropy_avail

Saya menggunakan program untuk menghasilkan deskripsi langkah-langkah untuk menyiapkan kartu pintar OpenGPG dengangpg , jadi saya harus menjalankan gpgbeberapa kali sampai semuanya berjalan sebagaimana mestinya. Setelah menjalankan awal saya perhatikan bahwa /dev/randomtidak akan memiliki cukup entropi dan gpg hanya akan menunda menunggu untuk akumulasi baru.

Saya menulis sebuah program kecil untuk memberikan data non-acak tambahan, dan ketika melakukannya gpgtidak akan "berhenti" tetapi menghasilkan kunci segera: bagus untuk menguji skrip agar berjalan dengan benar, tetapi tentu saja bukan sesuatu yang harus Anda lakukan saat membuat nyata Anda kunci.

Program untuk mempercepat gpg( jangan gunakan dalam situasi nyata ):

# For testing purposes only 
# DO NOT USE THIS, tHIS DOES NOT PROVIDE ENTROPY TO /dev/random

import fcntl
import time
import struct

RNDADDENTROPY=0x40085203

while True:
    random = "3420348024823049823-984230942049832423l4j2l42j"
    t = struct.pack("ii32s", 8, 32, random)
    with open("/dev/random", mode='wb') as fp:
        # as fp has a method fileno(), you can pass it to ioctl
        res = fcntl.ioctl(fp, RNDADDENTROPY, t)
        time.sleep(0.001)

Ketika saya menjalankan ini sambil menonton entropy_availsaya bisa melihat entropi yang tersedia naik menjadi lebih dari 3800.


Terima kasih atas jawabannya. Saya masih menantikan untuk menguji gpg, yang sayangnya kurang batchable dan lebih interaktif. .. Tetap saja. Apakah Anda yakin panggilan berulang catdengan sendirinya belum menguras entropi? Apakah Anda memiliki beberapa bukti atau sumber yang memberi tahu penggunaan gpg /dev/randomyang akan menyempurnakan jawabannya? Terakhir, apakah itu juga berarti bahwa openssl menghasilkan kualitas RSA-keypairs yang lebih rendah daripada gqg?
humanityANDpeace

@humanityANDpeace Dimungkinkan (meskipun kurang jelas) untuk menggunakan GnuPG dalam mode batch. Cari Unattended key generationdi file /usr/share/doc/packages/gpg2/DETAILS(atau apa pun itu di distro Anda). The /dev/randombukti dalam jawaban saya.
Hauke ​​Laging

@humanityANDpeace Jawaban Hauke ​​lebih tepat, tetapi saya menemukan beberapa referensi untuk itu sambil meneliti cara mengatur kartu OpenGPG saya. Batching tidak mudah, tetapi program python yang saya gunakan telah saya sediakan di bitbucket
Anthon

Saya suka jawaban dan keduanya menyarankan solusi yang tepat. terima kasih atas bitbucket tautannya!
humanityANDpeace

1
Memunculkan proses baru menghabiskan entropi, oleh karena itu pendekatan yang lebih baik akan menggunakan readshell builtin:while read -r < /proc/sys/kernel/random/entropy_avail; do clear; date; printf '\nAvailable entropy: %s bytes\n' "$REPLY"; sleep 1; done
nyuszika7h
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.