Yanılıyorsam düzeltin: Bir dosyayı şifrelerken, GPG tek seferlik bir AES şifreleme anahtarı oluşturur ve o anahtarı RSA kullanarak şifreler. Bunun, büyük miktarda veriyi işlerken AES'in üstün performansından yararlanacağı varsayılıyor.
Bu doğruysa, neden gpg --encrypt , örneğin, p7zip ’in AES-256 şifrelemesi?
Deneyelim ...
İlk önce, rastgele baytlarla dolu 500 MB'lık bir dosya oluşturuyorum:
dd if = / dev / urandom of = / tmp / foo bs = 1000000 count = 500 sonra GnuPG kullanarak şifreliyorum ve bu işlem tarafından geçen süreyi ölçüyorum (" keyID ", genel anahtarın UID'sidir Kullanıyorum):
zaman gpg -r "keyID" --cipher-algo AES256 --compress-algo none -o / tmp / bar --encrypt / tmp / foo Makinemdeki toplam süre (2,7 GHz'de Intel i7, 64 bit modu, GnuPG 2.0.22):
3.77s kullanıcı 0.55s sistemi% 99 cpu Toplam 4.328 yani saniyede 115 MB'lık bir şifreleme bant genişliği: o kadar da kötü değil! Şimdi tekrar deneyelim, ancak bu sefer sıkıştırmayı devre dışı bırakmadan (yani " --compress-algo none " seçeneklerini kaldıralım):
20.99s user 0.79s system% 98 cpu 22.038 toplam 5 kat daha yavaştır. İşte karşınızda: "Yavaş" olan şifreleme değil, sıkıştırmadır (birçok kullanım için 20 MB / s'den fazlası hala makul derecede hızlı olabilir).
115 MB / s, AES'in "taşınabilir" uygulamasıyla tutarlıdır. Özelleştirilmiş AES işlem kodlarını (i7'mde bulunan) kullanan kod, örneğin 300 ila 400 MB / sn'ye kadar daha hızlı olacaktır (AES-NI işlem kodlarının çok yüksek bir işlem hacmi olmasına rağmen, ayrıca ihmal edilemez bir gecikme süresine sahiptir, bu da en iyi performansın paralel işlemeyi gerektirdiği anlamına gelir, yani CTR modu; ancak OpenPGP standardı CFB 'yi zorunlu kılar,
Her neyse, iyi bir mekanik sabit disk yaklaşık 120 MB / sn'de başladığından, çok iyi bir İnternet erişimi (optik fiber) 10 MB / sn'nin altında olacağından biri söyleyebiliriz 115 MB / sn ham şifreleme hızı yeterlidir.