Certbot: Panjang bit kunci RSA default harus 3072

Saya bahkan menyarankan 4096 (saya melakukannya di hampir semua sistem saya).

Terima kasih,
Martin

Saya akan menyarankan juga 4096.

Tetapi beberapa bulan yang lalu, mereka tidak setuju dengan 4096 secara default: https://github.com/letsencrypt/letsencrypt/issues/489

Saya lebih suka kompromi (= RSA dengan 3072 bit-modulus) dibandingkan tanpa keamanan sama sekali secara default.

Sarankan 4096 juga.
Keamanan harus baik secara desain dan default: tidak ada pengguna standar yang mengubah konfigurasi default.

Dan tidak ada argumen yang dapat diterima untuk 2048/3072 vs 4096 bit (hanya overhead kecepatan yang sangat kecil).
3072 bit dapat menyebabkan masalah kompatibilitas jika hardcode agen pengguna beberapa ukuran kunci (2048 dan 4096 bit akan lebih baik didukung daripada 3072).

Terburuk, argumen regenerasi kunci 90 hari untuk membenarkan penggunaan kunci 2048 bit tidak baik:

• Regenerasi kunci merusak banyak perlindungan tumpukan TLS lainnya, seperti DANE/TLSA atau HPKP, konfigurasi yang diperkeras harus menonaktifkannya untuk menghindari masalah besar.
• Regenerasi kunci tidak mengatakan "penghancuran masa lalu". Jika server web tidak dikonfigurasi dengan benar hanya dengan paket sandi PFS, agen serupa NSA dapat mencegat dan menyimpan komunikasi jaringan yang dilindungi dengan kunci 2048 bit, dan dapat mendekripsinya dalam 20 atau 30 tahun, bahkan jika kunci yang sesuai dihancurkan. Tombol 4096 bit melindungi komunikasi non PFS yang lebih lama.
• Bahkan dengan sandi PFS saja, server web umumnya mendasarkan parameter DH yang dinegosiasikan pada ukuran kunci pribadi. Jika Anda hanya menggunakan kunci privat 2048 bit, parameter DH Anda hanya 2048 bit, dan kemungkinan lemah terhadap LogJam.

+1 lain untuk 4096, itulah yang selalu saya gunakan akhir-akhir ini.

Lihat #489 untuk banyak diskusi tentang masalah ini.

Dengan pengaturan default LE, RSA 2048 bit, 90 hari, coba retak? Saya sarankan untuk menutup masalah ini.

Pertanyaan bukanlah « bukti Anda dapat memecahkannya » (atau tetap pada 1024 bit, tidak ada yang memecahkannya sejak sekarang) tetapi « semua rekomendasi / keadaan seni meminta setidaknya 3072 bit » (NSA, NIST, ANSSI, FIPS, Qualys dan lagi).
TIDAK ada kelemahan yang valid untuk meng-upgrade ke 4096 bit secara default.

(Dan saya ulangi, bahkan dengan perpanjangan kunci 90 hari, jika tidak ada PFS yang digunakan, Anda memiliki validitas kunci praktis selama beberapa dekade bahkan jika validitas teknis hanya 90 hari, dan perpanjangan kunci 90 hari memecahkan banyak tumpukan TLS lainnya (TLSA, HPKP, penyematan sertifikat), jadi admin sistem yang waras HARUS menonaktifkannya dan menggunakan kembali kunci setidaknya selama 120 hari dan 1 tahun dalam praktik)

Namun, di 1.000.000 situs web teratas Alexa, lebih dari 89% situs web yang mengaktifkan SSL/TLS menggunakan RSA 2048 bit, termasuk banyak situs web perbankan online.

Yap, bank juga memiliki SSLv3 dan MD5 jika Anda mau https://imirhil.fr/tls/#Banques %20en%20ligne
Dan Google/Youtube juga https://imirhil.fr/tls/alexa.html
Dan situs porno tidak ada TLS sama sekali https://imirhil.fr/tls/porn.html
Bahkan CA memiliki SSLv3, MD5, RC4 atau SSLv2 (ya, Anda membaca dengan benar…) dan suite EKSPOR 40 bit https://imirhil.fr/tls/ca.html

Konfigurasi TLS SANGAT buruk di alam liar, ini bukan alasan untuk terus melakukan dadu.

@devnsec-com Jadi mereka tidak aman. Bahkan jika IPv6 dan DNSSEC adalah teknologi yang baik, mereka belum digunakan secara besar-besaran. Itu terjadi sama untuk RSA 4096 bit. Kita harus bergerak maju bukannya menginjak air.

Satu-satunya alasan untuk menggunakan RSA 3072 atau 4096 (atau bahkan lebih lama) adalah pemeriksaan di masa mendatang, tetapi dengan sertifikat hanya 90 hari, apakah semua pengguna benar-benar membutuhkan RSA lebih lama dari 2048 secara default? Jika Anda benar-benar paranoid, pilih kunci yang lebih panjang, ada parameter dan Anda dapat mengubahnya.

Semua pengguna membutuhkan 3072+ kunci secara default .

Orang-orang yang benar-benar mengetahui apa yang mereka lakukan pada akhirnya dapat mengurangi ukurannya, tetapi secara default , Let's encrypt harus menyediakan konfigurasi yang sesuai dengan keadaan seni.
Pengguna standar (99% sebenarnya) bahkan tidak melihat konfigurasi atau peduli dengan ukuran kunci yang dihasilkan atau bahkan tahu apa itu TLS sebenarnya…

Ingat, kita berbicara tentang sertifikat SSL/TLS, Anda dapat memiliki dukungan PFS di server Anda, dan dapat dicabut jika perlu. Kami tidak berbicara tentang kunci OpenGPG atau kunci SSH yang dapat Anda gunakan selama 20 tahun atau bahkan lebih lama.

Dan bertahun-tahun kemudian, ketika RSA 2048 terbukti tidak lagi aman, kami dapat mengubah default LE ke RSA 4096, hampir semua pengguna akan diubah ke RSA 4096 dalam waktu 90 hari.

Karena saya telah menyebutkan OpenGPG, saya akan mengatakan bahwa bahkan OpenGPG adalah default untuk RSA 2048.
Baca ini: https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

Anda bisa . Anda dapat memiliki tidak PFS juga. Dan jika kunci 2048 bit, Anda tidak aman. Bahkan dengan perpanjangan 90d. Dan jika tidak ada PFS, penghancuran kunci tidak berguna, data Anda sudah ada di alam dan harus didekripsi dalam beberapa dekade.

Dan hanya sertifikat yang bisa dicabut, bukan kunci.
Kuncinya persis seperti kunci GPG/SSH: setelah generasi, Anda harus menanganinya sampai kehancuran fisik permukaan bumi jika PFS dan selamanya jika tidak ada PFS.

Karena saya telah menyebutkan OpenGPG, saya akan mengatakan bahwa bahkan OpenGPG adalah default untuk RSA 2048.

GPG memiliki kelemahan nyata untuk menggunakan 4096 kunci (hanya beberapa kartu pintar yang mendukung lebih dari 2048, perangkat seluler…). Di TLS, tidak ada.

Dan di GPG, semua orang saat ini menghasilkan kunci 4096 bit, semua tutorial dan rekomendasi memintanya.

Anda baru saja membuat poin, alih-alih berdebat default ke RSA 2048 atau lebih lama, kita harus berbicara tentang default untuk mengaktifkan PFS. Karena tidak peduli berapa lama kuncinya, itu akan didekripsi cepat atau lambat, RSA 2048 akan, RSA 4096 juga.

Ya, tetapi Anda tidak memiliki cara untuk memastikan PFS dengan Let's Encrypt (dan lebih buruk lagi hanya sandi PFS, Anda dapat menegosiasikan rangkaian sandi PFS tetapi server dapat mendukung tanpa-PFS atau EKSPOR…).

Dan saat ini, ada kelemahan utama untuk hanya menggunakan suite sandi PFS (kompatibilitas browser, lihat https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA).

Dalam semua kasus, ini bukan pekerjaan CA.

Kami tidak berbicara tentang CA di sini, tetapi perangkat lunak klien, bukan?

Tidak. TLS sangat rumit, dengan banyak tumpukan.
Tidak ada perangkat lunak yang dapat menanganinya sepenuhnya.

Anda tidak dapat menebak apakah pengguna Anda memiliki DNSSec atau TLSA, harus memastikan kompatibilitas IE atau bukan agen pengguna standar, versi OpenSSL apa yang digunakan, dll.
Satu-satunya hal yang dapat dilakukan LE adalah menaikkan ukuran kunci…

Tidak, ketika LE menggunakan RSA 3072 atau 4096 secara default, seseorang akan mengatakan bahwa dia menginginkan RSA 8192 secara default untuk semua pengguna, ini adalah perlombaan senjata tanpa akhir.

@devnsec-com Tidak. NSA, NIST, ANSSI, FIPS, Qualys tidak merekomendasikan RSA 8192 tetapi setidaknya RSA 3072.

Tidak, jika seseorang meminta 8192, Anda dapat mengatakan 4096 saat ini aman dan direkomendasikan di mana-mana.
Saat ini, ini bukan kasus 2048.

Saya juga dapat mengatakan Yubico , Cisco , dan banyak perusahaan merekomendasikan RSA 2048 pada saat kita berbicara.

Semakin panjang kunci semakin aman, tetapi perusahaan bisnis lebih pragmatis dalam topik ini. Sekali lagi, RSA 2048 sudah cukup pada tahap saat ini sebagai default, selama kami mendukung kunci yang lebih panjang saat dibutuhkan.

Sumber yang bagus untuk percakapan ini - keylength.com

@devnsec-com Posisi Yubico dan Cisco valid, karena mereka memiliki masalah perangkat keras (HSM, PKI, dan kartu pintar tidak mendukung 4096 bit dengan baik).

Dari Yubico : « Ini bukan kendala dari Yubico, melainkan batasan perangkat keras dari chip NXP A700x yang digunakan dalam YubiKeys »
Dari Cisco: 4096 bit hanya tersedia dari Cisco IOS XE Rilis 2.4 (dan perangkat keras sulit untuk ditingkatkan), dan halaman yang diberikan sudah sangat tua (tampaknya tidak diperbarui sejak rilis 2.4 (2009), nilai default yang sama sejak setidaknya rilis 2.X …).

Dan ini bukan karena semua domba lain berlari menuju tebing yang harus kita ikuti…

@devnsec-com Saya juga menambahkan bahwa dokumentasi Cisco adalah tentang manajemen PKI dan CA, dan di bidang ini (sertifikat CA, bukan sertifikat pengguna akhir), CA/B-forum merekomendasikan setidaknya 2048 bit .

Dan ada perdebatan internal tentang 4096 inklusi juga, sejak 2014.

Apakah kami akan menyertakan rekomendasi tentang ukuran kunci? Beberapa orang sengaja ingin menggunakan kunci 4096 bit. Apakah mereka akan menerima saran? Dokumen tersebut dapat menjelaskan pertukaran antara keamanan, kompatibilitas, dan faktor lainnya

Tetapi tampaknya router perangkat keras tidak mendukung root lebih dari 2048 (Cisco)

Iñigo mengatakan bahwa produk terbaru Cisco tidak mendukung root SHA-1 dan 4096-bit. Kelvin mengatakan dia bisa mencoba bekerja dengan Cisco untuk mengubahnya.

@devnsec-com Komentar internal lainnya di forum CA/B.

Menetapkan tanggal target untuk rangkaian perubahan berikutnya guna meningkatkan keamanan/kinerja (RSA-4096/ECC/SHA-512/dll)

Halo teman-teman, Akan sangat bagus jika utas ini terus berjalan dan mendapat tanggapan dari staf LE.
Sejauh yang saya bisa baca, argumen @aeris tampaknya valid dan tidak bertentangan. Kecuali jika kami melewatkan sesuatu, saya juga berharap LE segera mengganti kunci RSA default ke 4096bit.

+1 untuk RSA 3072bit secara default.

Seperti yang telah disebutkan, RSA 2048bit hanya setara dengan 112bit perlindungan kunci simetris. Itu berada di bawah minimum 128bit yang digunakan secara luas saat ini. RSA 3072bit hanya setara 128bit, jadi cukup untuk saat ini (dan minimum yang direkomendasikan oleh NSA per Januari 2016).

Perhatikan bahwa semua perkiraan umur panjang sebelumnya untuk ukuran kunci harus diambil dengan skeptisisme yang sehat, karena mereka umumnya mengasumsikan peningkatan linier dalam pemecahan kunci, tetapi serangan baru dapat menurunkan keamanan jauh lebih cepat.

Kunci RSA dengan >2048 bit saat ini tidak kompatibel dengan Amazon Web Services. Dari Panduan Pengembang Amazon CloudFront :

Ukuran maksimum kunci publik dalam sertifikat SSL/TLS adalah 2048 bit

Hanya berpikir saya akan menambahkan poin ekstra ini ke dalam percakapan.

Siapapun yang ingin memiliki RSA lebih besar dari 2048 bit cukup memasukkan --rsa-key-size 3072 atau --rsa-key-size 4096 untuk meminta ukuran kunci ini.
Harap perhatikan bahwa kunci RSA yang lebih besar membutuhkan waktu lebih lama untuk dibuat, dan apa pun yang lebih besar dari 4096 dapat membuat browser Apple yang lama mogok.

Ketika #2632 telah diterapkan, kelemahan kinerja hampir tidak berdampak bagi mayoritas.
Jadi kami dapat menggabungkan EC 256 dengan 3072 RSA (atau apa pun yang kami inginkan sebagai default) untuk memberikan kekuatan yang sama untuk keduanya.

Omong-omong, sebagai saran untuk mendukung kunci EC, miliki perintah seperti --ec-key-type untuk membuat kunci EC dan meminta sertifikat.
Saat ini saya membuat dan menandatangani kunci RSA saya menggunakan certbot dan kunci EC saya menggunakan skrip Shell.

@WilliamFeely itu #2625

Terima kasih.
Adapun ukuran kunci RSA, saya kira RSA 2048 masih standar industri, dan masih berwenang untuk kepatuhan PCI-DSS, dan dengan demikian mengapa masih default?

Inilah yang dikatakan oleh dokumentasi PCI-DSS terbaru ( v3.2, April 2016 ):

Lihat standar industri dan praktik terbaik untuk informasi tentang kriptografi yang kuat dan protokol yang aman (mis. NIST SP 800-52 dan SP 800-57, OWASP, dll.)

Untungnya, glosarium mendefinisikan Kriptografi Kuat sebagai berikut:

Kriptografi berdasarkan algoritme yang telah teruji dan diterima industri, bersama dengan panjang kunci yang memberikan kekuatan kunci efektif minimal 112-bit dan praktik manajemen kunci yang tepat. Kriptografi adalah metode untuk melindungi data dan mencakup enkripsi (yang dapat dibalik) dan hashing (yang merupakan “satu arah”; yaitu, tidak dapat dibalik). Lihat Hashing.

Pada saat publikasi, contoh standar dan algoritme yang telah teruji dan diterima industri termasuk AES (128 bit dan lebih tinggi), TDES/TDEA (kunci tiga panjang), RSA (2048 bit dan lebih tinggi), ECC (224 bit dan lebih tinggi) , dan DSA/DH (2048/224 bit dan lebih tinggi). Lihat versi terbaru dari Publikasi Khusus NIST 800-57 Bagian 1 (http://csrc.nist.gov/publications/) untuk panduan lebih lanjut tentang kekuatan dan algoritma kunci kriptografi.

_ Catatan : Contoh di atas sesuai untuk penyimpanan data pemegang kartu yang persisten. Persyaratan kriptografi minimum untuk operasi berbasis transaksi, sebagaimana didefinisikan dalam PIN PCI dan PTS, lebih fleksibel karena ada kontrol tambahan untuk mengurangi tingkat eksposur.
Direkomendasikan agar semua implementasi baru menggunakan kekuatan kunci efektif minimal 128-bit._

Tidak perlu default ke 3072 untuk kunci RSA yang digunakan dengan server web.

Pertama-tama, Anda hanya boleh menggunakan cipher yang menyediakan FS. Dengan cara ini, sesi sebelumnya yang dicatat masih aman meskipun kunci pribadi Anda kemudian ditemukan.

Dengan sesuatu seperti GnuPG, Anda mungkin ingin menggunakan yang lebih besar (saya menggunakan 4096) karena FS bukanlah opsi, klien dan server tidak menegosiasikan kunci mereka sendiri ketika koneksi dibuat. Bahkan dengan GnuPG Anda benar-benar tidak memerlukan > 2048 dan jika Anda membutuhkannya, EC memberikan lebih banyak keuntungan, tetapi karena belum didukung dengan baik oleh klien dan pesan terenkripsi GnuPG mungkin sensitif selama beberapa dekade, 4096 setidaknya dibenarkan,

Tidak dapat dibenarkan dengan HTTPS jika FS digunakan. Ketika FS digunakan, Anda harus menggunakan cipher ECDHE bila memungkinkan sehingga kunci yang digunakan antara klien dan server lebih kuat. Jika server Anda masih mendukung kunci DHE maka itu adalah grup DH di mana Anda harus khawatir tentang berapa banyak bit, dan di sana, kebanyakan orang menggunakan grup 2048 DH yang telah ditentukan sebelumnya yang diterbitkan di RFC. Menghasilkan grup DHE 2048 bit Anda sendiri masuk akal.

Untuk kunci pribadi server, 2048 bit tidak dapat dengan mudah diretas dan oleh karena itu sudah cukup. Menyarankan default 3072 atau 4096 seperti menyarankan pemberat kertas 20 pon alih-alih 15 pon. Ya, 20 pon lebih berat tetapi tidak, tidak ada manfaat nyata dan kunci RSA 2048 bit Anda akan lama diganti sebelum tidak lagi aman.

Selalu gunakan kerahasiaan ke depan dan gunakan sandi ECDHE bila memungkinkan. Kunci pribadi, RSA 2048 sudah cukup baik dan jika Anda benar-benar ingin lebih baik, gunakan ECDSA bukan RSA untuk kuncinya.

Saya kira apa yang saya coba katakan, dan koreksi saya jika saya salah, adalah bahwa ketika TLS Anda membutuhkan cipher yang menggunakan Forward Secrecy maka satu-satunya tujuan sebenarnya dari kunci pribadi jangka panjang server adalah identitas.

Enkripsi aktual antara klien dan server yang terjadi menggunakan kunci sementara yang dinegosiasikan antara klien dan server yang tidak terkait dengan kunci yang digunakan dengan sertifikat x.509.

Itulah yang perlu Anda khawatirkan, jangan pernah menggunakan parameter DH < 2048 dan sebaiknya menggunakan ECDHE. Kunci pribadi untuk server kemudian hanya memiliki relevansi dalam menetapkan identitas server, dan RSA 2048 bit tentu cukup baik untuk itu terutama jika Anda mengikuti praktik terbaik untuk menghasilkan kunci baru setidaknya setahun sekali.

Jadi masalah ini harus ditutup, dan penekanan pada keamanan harus ditempatkan pada pemilihan rangkaian sandi yang tepat.

Menarik, tetapi ketika Applebaum dan Snowden merekomendasikan saya untuk menggunakan kunci RSA ukuran 4096 bit, yah, hmm, saya tidak tahu, saya pikir saya mungkin akan menindaklanjuti saran itu. Bukankah identitas justru yang coba kita sembunyikan/lindungi di sini?

@jult Tetap menggunakan 4096-bit, terutama jika Anda menggunakan GnuPG. Tidak sampai semua orang meningkatkan ke 2.1, kami akan memiliki akses ke kunci OpenPGP ed25519. dan mereka tidak terlalu kuat. (Saya sangat menyukai kunci SSH + GPG ed25519 saya, jadi dorong semua orang untuk menjauh dari RSA!)

Kunci RSA 2048-bit diharapkan dapat dipecahkan oleh penyerang dengan sejumlah besar sumber daya komputasi dalam beberapa tahun ke depan atau lebih. 768-1024 bit sudah rusak secara rutin.

Saya tidak berpikir 3072 adalah default yang masuk akal, itu agak tidak biasa.

2048-bit tidak akan direkomendasikan setelah tahun 2030, saya jamin, dan matahari terbenam akan bertahap seperti pada SHA-1. Saya telah membaca banyak dokumen standar pemerintah dan semacamnya...

Untuk sementara orang berlatih membuat kunci 8192-bit ke atas... Ini hanya perubahan dua atau tiga baris yang menyenangkan ke sumbernya, saya tidak yakin seberapa baik mereka dapat dioperasikan dengan orang lain.

. @WikiLeaks menerbitkan kunci enkripsi RSA PGP 8192-bit yang luar biasa kuat untuk pengiriman https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

— KM Gallagher (@ageis) 27 Mei 2015

@ageis Juga, ada batas yang cukup sulit pada 16384. Ini akan membutuhkan *banyak* peretasan lebih banyak untuk menjadi lebih besar; Saya mencoba.

— isis agora lovecruft (@isislovecruft) 8 September 2014

@jult Saya tidak akan membahas Appelbaum dan Snowden. Saya juga tidak terlalu mengenal mereka, tetapi saya melihatnya sebagai semacam daya tarik bintang rock terhadap otoritas yang Anda buat. Lihatlah semua sumber, saya dapat merekomendasikan beberapa terutama:

• http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
• https://pages.nist.gov/800-63-3/sp800-63b.html
• http://www.secg.org/sec2-v2.pdf
• http://www.ecc-brainpool.org/download/Domain-parameters.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf
• https://safecurves.cr.yp.to/

Secara pribadi, saya lebih tertarik untuk membuat semua orang diperbarui ke GnuPG 2.1, dengan format kbx yang lebih cepat, dan menghasilkan kunci ed25519 baru (pikiran @dkg atau @floodyberry?), dan saya berharap seri Yubico berikutnya akan mendukungnya. Bahkan saya bisa menjangkau untuk memeriksa; karena saya melakukan beberapa pengujian beta untuk YubiKey 4. Saya tidak suka bagaimana kunci harus dilindungi/diberi kata sandi untuk diekspor, karena itu membuat impor ke kartu pintar menjadi tantangan.

Sementara saya berada di sekitar masalah ini, saya akan menjatuhkan grafik yang bagus dari Publikasi Khusus NIST 800-57. Banyak lagi dari mana itu berasal. Hal yang sempurna untuk memulai pada Sabtu malam, ya?

Sekali lagi, beban ekstra pada ukuran selama jabat tangan klien tidak sebanding dengan risiko ekstra dengan ukuran kunci yang lebih kecil. Yang merekomendasikan untuk tidak menggunakan 4096 bit RSA gagal menghasilkan argumen yang valid untuk tidak melakukannya. Belum lagi fakta bahwa kami mengandalkan pembuatan kunci yang tepat , dan jika itu berakhir dengan cacat, kami jauh lebih baik dengan kunci 4096 bit.
Periksa ini; https://github.com/certbot/certbot/issues/489#issuecomment-114083162
Anda ingin memastikan bahwa Anda juga menghasilkan kunci Diffie Helman >=4096 bit, hal-hal seperti ini
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
jika Anda ingin masuk akal saat Anda mengaktifkan DH(E) di suite sandi Anda.

Saya baru saja menjalankan benchmark sintetis untuk tanda tangan RSA dan melihat ini:

(1024, 0.0008035948276519776)
(2048, 0.0025235090255737304)
(3072, 0.006322009086608887)
(4096, 0.013043954849243164)

Angka pertama adalah ukuran modulus dan yang kedua adalah jumlah rata-rata detik yang diperlukan per operasi tanda tangan.

Saya menemukan komentar @AliceWonderMiscreations tentang kerahasiaan ke depan agak persuasif; apakah ada yang kebetulan memiliki statistik terkini tentang fraksi koneksi TLS yang dinegosiasikan dengan berbagai ciphersuite hari ini? Jika sekarang sangat sedikit yang menggunakan sandi non-PFS, maka parameter panjang kunci RSA akan memiliki konsekuensi keamanan jangka panjang yang minimal.

FS dan non-FS adalah masalah terpisah. Ya, kami harus mendorong FS ciphersuites, dan baik klien maupun server harus menonaktifkan ciphersuites non-FS di mana mereka tahu itu mungkin untuk dilakukan. (TLS 1.3 tidak memiliki ciphersuite non-FS yang tersisa, ya!) Itu tidak berarti bahwa kita harus mengabaikan pentingnya kunci identitas kriptografik yang kuat, atau bahwa kita harus bermain melawan yang lain. Ingat bahwa kunci identitas palsu memungkinkan MiTM bahkan koneksi FS.

RSA 3072 tampaknya menjadi sweet spot di mana rekomendasi (seperti ENISA dan NIST) turun pada margin keamanan yang kuat untuk kunci yang dimaksudkan untuk digunakan selama dekade berikutnya.

Hai @dkg ,

FS dan non-FS adalah masalah terpisah. Ya, kami harus mendorong FS ciphersuites, dan baik klien maupun server harus menonaktifkan ciphersuites non-FS di mana mereka tahu itu mungkin untuk dilakukan. (TLS 1.3 tidak memiliki ciphersuite non-FS yang tersisa, ya!) Itu tidak berarti bahwa kita harus mengabaikan pentingnya kunci identitas kriptografik yang kuat, atau bahwa kita harus bermain melawan yang lain. Ingat bahwa kunci identitas palsu memungkinkan MiTM bahkan koneksi FS.

Dalam kasus default, saat ini kami hanya menggunakan kunci subjek RSA individu selama 60 hari (dengan risiko MITM aktif berlanjut selama 90 hari masa pakai sertifikat), dan kemudian beralih ke yang lain. Sepertinya ada perbedaan besar antara "penyerang yang dapat memecahkan kunci 2048-bit dalam 90 hari dapat melakukan serangan aktif" dan "penyerang yang dapat memecahkan kunci 2048-bit kapan saja dapat memulihkan teks biasa dari sesi lama yang itu terlibat dalam". Yang pertama benar dan yang terakhir tidak benar dalam kasus ciphersuite FS.

Rekomendasi tentang panjang kunci biasanya tampaknya mengasumsikan model ancaman di mana penyerang merusak kunci beberapa saat setelah kunci itu digunakan—misalnya rekomendasi yang Anda sebutkan di bawah tampaknya didasarkan pada model ancaman di mana penyerang membutuhkan waktu bertahun- tahun untuk memecahkannya. kunci individu. Dengan FS ciphersuites, model ancaman itu seharusnya tidak terlalu relevan untuk menentukan panjang kunci identitas karena kunci identitas yang diberikan sudah lama tidak digunakan.

RSA 3072 tampaknya menjadi sweet spot di mana rekomendasi (seperti ENISA dan NIST) turun pada margin keamanan yang kuat untuk kunci yang dimaksudkan untuk digunakan selama dekade berikutnya.

Poin yang saya hargai dalam argumen @AliceWonderMiscreations adalah bahwa kunci 2048-bit yang kami hasilkan tidak secara individual dimaksudkan untuk digunakan selama satu dekade, melainkan untuk digunakan selama beberapa bulan, ketika mereka digunakan untuk mengotentikasi negosiasi Diffie-Hellman. Jadi, rekomendasi ini mungkin mempertimbangkan konteks keamanan yang berbeda dalam banyak kasus. Dapat dibayangkan, kita harus lebih khawatir tentang modulus DH di sebagian besar model ancaman karena itu adalah parameter pembatas yang secara langsung mempengaruhi tingkat keamanan jangka panjang.

Saya akan mencoba mendapatkan beberapa data praktis tentang frekuensi penggunaan FS ciphersuites dan dampak kunci 2048 vs. 3072-bit pada kinerja server.

Sebagai pembaruan, saya mendengar perkiraan kasar dari beberapa sumber berbeda bahwa "sekitar 10%", "kurang dari 10%", dan "sekitar 1%" koneksi HTTPS sekarang menggunakan ciphersuite non-FS. Ini adalah target yang sangat sulit untuk ditentukan karena tergantung pada apakah itu dari perspektif browser, dari perspektif server, di negara tertentu, di situs web tertentu, untuk jenis situs web tertentu, dll., dan jenis-jenis situs web tersebut. perbedaan tampaknya menjelaskan perbedaan 1% -10%.

Secara pribadi, saya lebih peduli dalam hal ini dengan fakta bahwa kami menyimpan kunci pribadi lama di disk (yang saya ajukan masalah terpisah, https://github.com/certbot/certbot/issues/4635). Saya pikir ini harus menjadi prioritas yang lebih tinggi karena saya pikir penyerang yang mengkompromikan server untuk membaca lalu lintas lama umumnya jauh lebih mungkin daripada penyerang yang melanggar RSA 2048-bit untuk melakukannya.

Saya menyarankan yang berikut ini:

• Saya tahu @dkg telah melakukan banyak pekerjaan pada keamanan pertukaran kunci DH di TLS secara umum. Dapatkah Anda membuat atau menemukan beberapa alat yang membantu memindai situs untuk memperkirakan kekuatan pertukaran DH yang mungkin terjadi ketika klien terhubung ke setiap situs¹? (Saya tahu bahwa di beberapa area yang Anda khawatirkan, kami tidak dapat benar-benar mengetahui dari sisi klien seberapa aman pertukaran itu, tetapi saya hanya berpikir untuk mencoba memetakan kekuatan pertukaran DH sejauh bahwa kita dapat melihat dan menentukannya.) Kami juga mengenal banyak peneliti akademis yang tertarik dengan topik semacam ini...

• Saya masih akan mencoba memperbaiki https://github.com/certbot/certbot/issues/4635 sehingga kunci pribadi lama yang tidak lagi digunakan tidak ada di server web.

• Mungkin kita dapat memikirkan langkah-langkah berkelanjutan untuk mendorong pengguna mengupgrade browser web mereka, untuk meningkatkan jumlah DH yang digunakan di TLS.

Dengan mengingat hal itu, saya akan menegaskan kembali bahwa kunci 2048-bit yang kami hasilkan secara default biasanya tidak digunakan untuk secara langsung melindungi kerahasiaan kunci sesi, melainkan untuk mengautentikasi pertukaran kunci DH, di mana serangan harus dilakukan secara online. , serangan aktif dan interaktif dalam validitas sertifikat 90 hari. Jika tidak, penyerang harus memilih jalan serangan lain sebagai gantinya. Sulit bagi saya untuk melihat bahwa setiap sumber saran panjang kunci berpendapat bahwa kunci 2048-bit tidak cocok untuk otentikasi selama jendela 90 hari. Mereka lebih relevan secara langsung dengan kerahasiaan jangka panjang dari 1% -10% koneksi, tetapi mungkin kita dapat berupaya lebih keras untuk mengurangi persentase itu.

misalnya, sehubungan dengan algoritme dan sehubungan dengan ukuran parameter publik dan penggunaan kembali

Saya sedang melakukan penelitian lebih lanjut tentang saran terkait tentang kunci RSA, tetapi saya berencana untuk segera menutup masalah ini kecuali ada yang memiliki tanggapan terhadap tiga saran saya dalam balasan terbaru saya.

Bagaimana kalau menutup ini setelah #3349 selesai?

Bagaimana kalau menutup ini setelah #3349 selesai?

Saya akan mengatakan #6492 lebih relevan dan kita harus menutup ini setelah #6492 selesai (dan #4635).

Teman-teman, kripto 4096 bit tidak gratis. Ini sangat lambat dalam CPU berdaya rendah. Bahkan telepon modern menderita saat menggunakannya. Apakah Anda yakin beralih dari crypto yang tidak dapat dipecahkan ke crypto yang lebih tidak dapat dipecahkan lagi layak untuk merusak kinerja dan masa pakai baterai semua orang?

Panjang kunci 4096bit adalah masalah besar di IoT karena perangkat ini seringkali memiliki daya CPU yang sangat terbatas.

Kecepatan tangki RSA pribadi dari 3,6 hingga 0,6 untuk beralih dari 2048 hingga 4096 di salah satu perangkat tertanam kami yang lebih lama.

Seperti disebutkan sebelumnya, IoT dan perangkat lain tanpa akselerasi perangkat keras dapat menggunakan ECDSA (#6492).

Seperti disebutkan sebelumnya, IoT dan perangkat lain tanpa akselerasi perangkat keras dapat menggunakan ECDSA (#6492).

Apakah ada akselerasi perangkat keras RSA di banyak perangkat atau yang umumnya masih ditangani melalui perangkat lunak?

Akselerasi perangkat keras tersedia di beberapa MCU, tetapi tidak sebagian besar (lebih mahal). Juga sering dibatasi hingga 3072, karena ini adalah rekomendasi (https://www.keylength.com/)
Perhatikan bahwa verifikasi RSA cukup cepat. Hanya generasi dan tanda tangan yang sangat lambat.

OPENSSL_TLS_SECURITY_LEVEL=3 membutuhkan setidaknya 3072 bit.

Mengapa masalah ini masih terbuka? Agak jelas bahwa pengguna yang meminta tampaknya salah memahami relevansi di TLS, terutama pada tahun 2020.

TL;DR

• Sertifikat RSA hanya penting untuk membuktikan identitas server yang dapat dipercaya , dan diganti setiap 90 hari . Itu tidak akan dikompromikan karena panjang kunci 2048-bit dalam waktu itu hanya untuk meniru Anda.
• Itu dengan asumsi bahwa karena Anda sangat peduli dengan keamanan, Anda hanya mengizinkan suite sandi yang menawarkan FS (DHE/ECHDE), dan DHE juga tidak terlalu menjadi perhatian Anda karena untuk situs web, tidak ada browser web modern yang mendukung DHE untuk pertukaran kunci lagi (Safari dan Chrome menghentikan dukungan sekitar tahun 2016).
• RSA 1024-bit vs RSA 2048-bit ~4 miliar kali lebih sulit untuk diserang . RSA 768-bit rusak pada tahun 2010 (perlu 2 tahun dengan komputasi paralel yang setara dengan 2000 tahun satu mesin), Pada tahun 2020 kami hanya berhasil mencapai 829-bit, 512-bit vs 1024-bit adalah ~1 miliar kali dalam kesulitan, sementara 2048-bit vs 3072-bit hanya ~65k kali lebih sulit ...
• Identitas sertifikat Anda diverifikasi dalam rantai kepercayaan terhadap sertifikat CA , yang memiliki durasi validitas lebih lama tetapi masih RSA 2048-bit, Anda tidak memiliki kendali atas itu . Penyerang akan menargetkan bahwa jika mereka ingin meniru Anda, menambah panjang kunci Anda lebih dari itu tidak memberikan manfaat tambahan apa pun saat sertifikat tidak digunakan untuk hal lain.

Untuk sebagian besar penerapan, Anda harus memastikan suite sandi PFS saja, sertifikat RSA Anda tidak memiliki manfaat di sini di luar 2048-bit, Anda hanya mengurangi jumlah jabat tangan yang dapat didukung server secara bersamaan karena overhead tambahan. Konteks nasehat perlu diperhatikan, jangan hanya ditelanjangi secara membabi buta.

Gunakan DHE / ECDHE untuk pertukaran kunci saja, dengan server web Anda akan menemukan bahwa sejak 2015 browser secara bertahap telah menghapus dukungan untuk DHE juga. Safari melakukannya sebagai tanggapan terhadap Logjam pada tahun 2015, Chrome menghentikan dukungan DHE pada tahun 2016 ( Chrome 53 (Agustus 2016) ) karena banyaknya server yang masih bernegosiasi dengan grup DH 1024-bit, dan Firefox akhirnya bergabung pada tahun ini ( Firefox 78 ( Juni 2020) ). Jadi pada dasarnya untuk web, Anda hanya berurusan dengan ECDHE, kecuali jika Anda benar-benar mengetahui klien yang tidak dapat mendukungnya karena alasan tertentu, browser web telah mendukung ECC untuk waktu yang lama .

Kekhawatiran apa yang mungkin Anda khawatirkan sekarang? Sertifikat Anda diperbarui/diganti dalam waktu 3 bulan, satu-satunya masalah keamanan dengan sertifikat RSA adalah identitas, bahwa beberapa penyerang dapat meniru identitas Anda, tetapi agar hal itu terjadi, penyerang harus berhasil dalam <90 hari jendela tersebut.

Pada tahun 2020, rekor sejauh ini memecahkan RSA 829-bit (10 tahun sejak kami menyadari 768-bit dapat dipecahkan), rekor RSA 795-bit sebelumnya menyebutkan memiliki algoritme dan perangkat keras yang lebih baik yang tersedia untuk mencapai hasil dalam waktu sekitar setengah waktu komputasi. Lihat saja tahun komputasi 900-2000 pencapaian ini setara dengan kekuatan komputasi paralelnya (yang untuk 768-bit dikurangi menjadi 2 tahun).

RSA 512-bit kira-kira sekitar 50 bit dari kekuatan kunci simetris dalam keamanan. RSA 1024-bit dikenal sebagai 80-bit, dan RSA 2048-bit, 112-bit, sedangkan 3072-bit seperti yang disebutkan dalam edisi ini adalah 128-bit. Benar, fantastis sehingga RSA 768-bit (yang berada di antara 50-80 bit keamanan simetris) pada tahun 2010 dapat ditembus dalam rentang 2 tahun dan satu ton uang, satu dekade kemudian kami telah berhasil melakukan beberapa simetris bit setara lebih. Bagi siapa pun di mana ini terdengar seperti omong kosong, setiap bit tambahan dalam kekuatan kunci simetris menggandakan jumlah pekerjaan untuk dihitung jika Anda ingin memaksa semua kemungkinan (rata-rata Anda akan berhasil sekitar setengah jalan melalui semua pemrosesan itu) .

Sekarang bandingkan RSA 512-bit dengan 1024-bit, ada perbedaan sekitar 30-bit dalam keamanan simetris, 2^30 adalah sekitar 1 miliar, yaitu 50-bit (1.125.899.906.842.624 kunci potensial) dikalikan dengan 1 miliar (1.125.899.906.842.624.000.000.000), atau secara sederhana , 1 miliar kali lebih banyak usaha/waktu untuk istirahat. Dengan RSA 1024-bit vs 2048-bit, Anda memiliki perbedaan 32 bit, 2^32 sedikit di atas 4 miliar. Jadi kita punya (4.503.599.627.370.496.000.000.000.000.000.000). Sekarang, menabrak hingga 3072-bit adalah keamanan ekstra 16-bit yang lebih sederhana, 2^16 == 65.536... ya itu akan membuatnya lebih "aman", tidak sama dengan lompatan 4 miliar pengganda kami, tetapi kami telah mengalami peningkatan kesulitan yang signifikan dengan RSA 2048-bit.

Sekarang biarkan itu meresap dan pikirkan. 768-bit RSA pada tahun 2010 membutuhkan 2 tahun pemrosesan paralel yang setara dengan 2000 tahun dari satu mesin, dan satu dekade kemudian kami dapat melakukan sedikit lebih baik dengan semua kemajuan tersebut sejak saat itu. Masih jauh dari RSA 1024-bit kecuali seseorang dengan banyak uang dan waktu untuk disia-siakan ingin merusak sertifikat RSA Anda, ini tidak seperti grup DH bersama, nilainya jauh lebih kecil dari pengembalian, kecuali jika Anda memilikinya beberapa data yang sangat berharga dan tidak dapat diperoleh melalui cara yang lebih murah seperti penyiksaan fisik/pemerasan.

Bahkan jika seseorang memiliki sumber daya untuk disia-siakan untuk memecahkan sertifikat RSA Anda, itu bukan 1024-bit, kesulitan 2048-bit adalah 4 miliar kali lipat, itu tidak akan terjadi tanpa beberapa terobosan besar, kemungkinan kelemahan di mana panjang kunci tidak bukan masalah (lihat saja semua kerentanan lain di TLS yang telah mengatasi masalah tersebut). Jika Anda melampaui RSA 3072-bit dan itu digunakan untuk enkripsi Anda yang kebetulan menggunakan kunci 128-bit, maka sertifikat RSA Anda tidak masalah, dan kunci enkripsi 128-bit untuk AES hanya dapat diserang sebagai gantinya afaik.

Terlepas dari semua itu, seperti yang dinyatakan, kami hanya berbicara tentang RSA yang hanya memiliki relevansi untuk identitas jika Anda hanya menggunakan suite sandi PFS, apa pun sumber daya Anda, ada cara yang lebih baik untuk mengkompromikan server atau pengguna Anda daripada biaya untuk memecahkan 2048 -bit RSA cert dalam waktu kurang dari 90 hari...

OPENSSL_TLS_SECURITY_LEVEL=3 membutuhkan setidaknya 3072 bit.

Dan ini memiliki relevansi mengapa? Ada level 5 di sana yang mengamanatkan panjang kunci RSA minimum 15360 bit, mengapa berhenti di 3072 bit dengan logika itu?

Seperti yang dinyatakan oleh dokumen tertaut, defaultnya adalah 1 kecuali jika dikonfigurasi sebaliknya. Apakah Anda mengetahui perangkat lunak utama yang mengkompilasi OpenSSL dengan level 3? Sebagian besar waktu ketika OpenSSL digunakan, itu ditautkan ke salinan sistem, karena Anda ingin menerima pembaruan keamanan tanpa bergantung pada setiap aplikasi yang memperbarui salinan paket mereka sendiri (dengan asumsi perangkat lunak dipelihara/diperbarui secara teratur untuk itu sejak awal, yang tidak selalu terjadi dalam skenario ini).

pindai situs untuk memperkirakan kekuatan pertukaran DH yang mungkin terjadi saat klien terhubung ke setiap situs

@schoen Chrome pada tahun 2016 menjatuhkan dukungan DHE , mereka mencatat 95% koneksi DHE menggunakan params DH 1024-bit. Bukan berarti itu menjadi masalah sekarang karena browser modern tidak mendukung suite sandi DHE lagi.

Untuk server lain seperti email, mungkin masih berguna (walaupun dukungan ECDHE cukup bagus untuk beberapa waktu, dengan beberapa distro Linux seperti RHEL tidak memiliki dukungan hingga 6,5 ​​sekitar 2014). DHE harus menggunakan grup FFDHE resmi dari RFC 7919, yang memiliki minimal 2048-bit. Tak satu pun dari klien lama dengan batas 1024-bit seharusnya menjadi masalah, untuk situasi khusus di mana sysadmin akan berada dalam posisi berbayar untuk mengatasinya, tetapi ada sejumlah masalah keamanan yang dapat dihadapi pada saat itu termasuk rantai potensial masalah kepercayaan karena sertifikat root yang kedaluwarsa pada suatu sistem.

Mungkin kita dapat memikirkan langkah-langkah berkelanjutan untuk mendorong pengguna mengupgrade browser web mereka, untuk meningkatkan jumlah DH yang digunakan di TLS.

Saat Anda membuat saran ini, Safari dan Chrome tidak lagi menawarkan DHE afaik. Ini akan memiliki hasil yang berlawanan, mengurangi DHE, dengan asumsi bahwa pengguna bahkan dapat memutakhirkan browser / klien pada perangkat yang menjalankan perangkat lunak usang. Beberapa OS atau perangkat lunak lama dikunci ke implementasi TLS lama (seperti macOS / iOS Secure Transport), yang memengaruhi dukungan versi TLS, suite sandi yang didukung (macOS tidak memiliki AES-GCM hingga akhir 2015 rilis IIRC).

Mengenai siapa pun yang menganggap RSA 2048-bit tidak cukup untuk perlindungan identitas selama 90 hari, mengabaikan perlindungan lain seperti OCSP dan log CT, apakah Anda mengetahui rantai kepercayaan? Sertifikat Anda diverifikasi terhadap root LetsEncrypt dan sertifikat perantara, jika seseorang ingin menyerang sertifikat, akan lebih berharga untuk mengkompromikan sertifikat tersebut daripada yang dikeluarkan untuk situs tertentu.

Jika sertifikat hanya digunakan untuk keaslian dan tidak dikompromikan untuk mendekripsi lalu lintas yang direkam, maka Anda dapat meningkatkan panjang kunci situs web sesuka Anda, tetapi apa yang Anda peroleh dalam perlindungan dari serangan teoretis ini di mana Anda lebih aman daripada sebelumnya? sertifikat dalam rantai kepercayaan dikompromikan? (yang menggunakan RSA 2048-bit, ~termasuk LE root~ ( EDIT: Sayangnya, LE RSA root adalah 4096-bit ), yang memiliki masa berlaku lebih lama, 5 tahun untuk menengah, dan hingga 2035 untuk LE root)

Mengapa masalah ini masih terbuka? Agak jelas bahwa pengguna yang meminta tampaknya salah memahami relevansi di TLS, terutama pada tahun 2020.

TL;DR

* RSA certs only matter for **proving the identity of the server can be trusted**, and are being **replaced every 90 days**. It won't be compromised due to key length of 2048-bit within that time just to impersonate you.

Sepertinya Anda tidak mengerti X.509 (dan bukan TLS :rofl :) lebih baik… :rofl:
Cert bukanlah masalahnya tetapi kuncinya adalah. Dan di dunia X.509, kuncinya tidak mungkin untuk dicabut… Jadi rollover 90 hari tidak selalu relevan di sini, dan ini menjadi masalah bagi server yang tidak menggunakan ECDHE/DHE tetapi auth RSA biasa. Dan ini cukup banyak terjadi juga di tahun 2020…

Anda menghitung juga salah untuk kekuatan RSA-2048. Anda harus menghitung tidak hanya waktu cara terbaik saat ini untuk memecahkan kunci yang diberikan tetapi juga masa depan pada titik di masa depan kunci Anda tidak lebih berarti. Dalam hal bukan ECDHE/DHE (yaitu, saya ulangi, tidak terlalu jarang), itu bukan 90d tetapi 10-30y. Dan ini bukan hanya waktu yang harus diperhitungkan, tetapi juga biaya, evolusi teknologi, dan penemuan kelemahan/trik kripto. Dan itu terlihat secara khusus dalam kasus penjelasan Anda.
RSA-256 retak dalam ~ 60-an pada laptop standar ~ $ 1000 pada 09/2019. Tetapi RSA-512 retak dalam ~4 jam dan ~$75 pada tahun 2015.
https://www.doyler.net/security-not-included/cracking-256-bit-rsa-keys
https://eprint.iacr.org/2015/1000.pdf
Jelas tidak [masukkan di sini sejumlah besar] perbedaan kali antara keduanya, tetapi kurang lebih 1,8 dengan biaya konstan.
Ini juga cukup terlihat di benchmark cado-nfs untuk memfaktorkan kunci RSA. RSA-120 adalah 1.9h, RSA-130 adalah 7.5h (dan bukan 81d seperti yang diharapkan), RSA-140 adalah 23h (dan bukan 227y) dan RSA-155 adalah 5.3d (dan bukan 7452 milenium).

Inilah sebabnya mengapa entitas seperti ANSSI atau NIST mendasarkan rekomendasi mereka tidak hanya pada kemampuan komputer atau pengetahuan kriptografi terkini, tetapi juga pada peningkatan di masa mendatang yang diharapkan terjadi dalam jangka waktu penggunaan kunci/kebermaknaan

itu masalah untuk server yang tidak menggunakan ECDHE/DHE tetapi auth RSA lama biasa. Dan ini cukup banyak terjadi juga di tahun 2020

Jadi saran Anda untuk meningkatkan keamanan di sini adalah mendorong penggunaan ukuran kunci yang lebih besar daripada mendorong suite sandi hanya PFS? Mengapa?

Anda menghitung juga salah untuk kekuatan RSA-2048
Anda harus menghitung tidak hanya waktu cara terbaik saat ini untuk memecahkan kunci yang diberikan tetapi juga masa depan pada titik di masa depan kunci Anda tidak lebih berarti

Mohon dijabarkan lebih lanjut. Dalam hal apa Anda menyadari dalam dekade terakhir ini telah salah. Tidak ada kasus RSA 1024-bit yang diketahui difaktorkan/dirusak, apalagi 2048-bit yang memiliki entropi 2^32 bit lebih banyak ketika melihat kekuatan kunci simetrisnya.

1. RSA 2048-bit ~4 miliar kali lebih kuat dari RSA 1024-bit.
2. 3072-bit hanya ~65k kali lebih kuat (ketika membandingkan 112-bit dengan 128-bit keamanan simetris seperti yang didefinisikan oleh NIST secara resmi).
3. Jika kita mengasumsikan 1024-bit (kekuatan kunci simetris 80-bit) dapat dikompromikan dalam rentang daya komputasi 1 tahun. Itu 4 miliar tahun untuk 2048-bit.
4. Anda mengklaim beberapa kemajuan teknologi yang tidak diketahui dapat sangat mengurangi waktu komputasi itu, tetapi tidak mengancam RSA 3072-bit?

Kita dapat membandingkan 1024-bit sebagai dapat dipecahkan dalam 1 detik, kemudian 2048-bit masih setara dengan 136 tahun ( (1/31536000) * 2^32 ). Pencapaian seperti itu masih jauh dari terjadi, jika Anda ingin bersikeras bahwa itu adalah kekhawatiran yang valid, apakah Anda menyadari bahkan 512-bit diperhitungkan dalam 1 detik? RSA 512-bit pertama kali diperhitungkan selama 6 bulan pada tahun 1999 , sejak 2015 ada proyek Github (FaaS) yang memungkinkan Anda memanfaatkan AWS dengan mudah dengan biaya kurang dari $100 dan beberapa jam untuk memfaktorkan RSA 512-bit.

Dengan mengingat hal itu, RSA 1024-bit menjadi sekitar 2^28 (~250rb) hingga 2^30 (1 miliar) kali lebih sulit (saya tidak memiliki angka pasti maaf, tetapi tampaknya sekitar itu), dan akademisi saat ini masih jauh dari itu, saya tidak yakin bagaimana menurut Anda RSA 1024-bit mendekati komputasi secepat itu, yang harus dilakukan sebelum RSA 2048-bit bahkan sesuatu yang perlu dikhawatirkan rusak dengan cara ini .

Pendekatan yang biasa dilakukan di sini adalah GNFS (General Number Field Sieve), yang semakin tidak layak dengan sumber daya yang dibutuhkan semakin besar ukuran kunci . Ada juga bagan bagus dari riwayat anjak RSA ini , dan jawaban terkait yang menyematkan RSA 2048-bit untuk difaktorkan oleh 2048 berdasarkan itu, dan 1024-bit pada 2015-2020, yang secara akademis belum tercapai.

Mempertimbangkan hal di atas, saya ingin Anda mendukung bagaimana RSA 3072-bit menawarkan lebih banyak keuntungan keamanan tambahan. Jika RSA 2048-bit diserang dengan cara lain atau maju dengan kecepatan seperti itu secara teknologi, maka saya tidak melihat bagaimana RSA 3072-bit akan menawarkan banyak perlindungan tambahan?

Dalam kasus tidak ECDHE/DHE (yaitu, saya ulangi, tidak begitu jarang)

Saya suka bagaimana Anda mengklaim itu "tidak terlalu jarang", seberapa umum Anda menemukan jabat tangan Anda menggunakan pertukaran kunci RSA alih-alih DHE atau ECDHE hari ini? Apakah Anda bahkan punya satu contoh?

ini bukan 90d tapi 10-30y

Saya yakin saya cukup jelas dalam menyatakan periode perpanjangan 90 hari untuk sertifikat ketika tujuannya hanya melayani otentikasi, bukan pertukaran kunci.

Dan ini bukan hanya waktu yang harus diperhitungkan, tetapi juga biaya, evolusi teknologi, dan penemuan kelemahan/trik kripto. Dan itu terlihat secara khusus dalam kasus penjelasan Anda.

Ya, biaya. Sumber daya yang saya tautkan untuk mengutip RSA 1024-bit yang membutuhkan Terabytes RAM untuk menjalankan GNFS, dengan langkah reduksi linier menjadi bagian yang paling mahal/sulit untuk ditangani. Itulah masalahnya dengan kesulitan eksponensial, sesuatu yang murah/mudah bisa naik kesulitannya dengan sangat cepat.

RSA-256 retak dalam ~ 60-an pada laptop standar ~ $ 1000 pada 09/2019. Tetapi RSA-512 retak dalam ~4 jam dan ~$75 pada tahun 2015.

Saya telah menautkan ke proyek Github yang dapat melakukan pemfaktoran 512-bit di AWS. Saya tidak tahu jumlah pasti bit entropi simetris dari 256-bit RSA, mungkin sekitar 30-bit? (jadi kira-kira 1.048.576 kali perbedaan antara RSA 512-bit). Makalah 512-bit yang Anda tautkan menyebutkan 432 CPU (masing-masing 12 instance dengan 36 vCPU + 60GiB RAM) dan total 2770 jam CPU dengan memori atau penyimpanan 1,5-2GB untuk matriks (saya tidak terlalu terbiasa dengan perhitungan ini, jika Anda merasa bebas untuk berpadu).

Matematika saya mungkin buruk di sini, tetapi mari kita coba bandingkan dua sistem daya komputasi berdasarkan informasi itu, 2770 jam ke menit akan menjadi 2770 * 60 = 166200 yang dapat kita bandingkan dengan 1 menit dari RSA 256-bit sebagai log2(166200) = 17.34 , ~2^17, tidak terlalu jauh dari perkiraan 2^20, dan karena saya tidak tahu bit simetris yang tepat untuk salah satu dari ini, itu mungkin cukup akurat, dengan beberapa ruang gerak untuk peningkatan dalam teknologi dan algoritme , tapi tidak ada yang mengejutkan?

Pada tahun 1991, RSA 330-bit diperhitungkan dalam beberapa hari , CPU Intel Core2Duo kemudian dapat menanganinya dalam waktu kurang dari satu jam. RSA 256-bit akan kurang dari itu, mari kita berikan waktu 60 menit yang optimis dan katakan bahwa dalam ~30 tahun itu berkembang menjadi ~1 menit, pengurangan besar 60 kali. Itu setara dengan mengatakan 2^6 (64)... 6 bit. Seperti yang ditunjukkan sebelumnya, hanya dengan mempertimbangkan waktu, bukan sumber daya seperti peningkatan kebutuhan RAM, itu masih jauh dari ancaman yang valid. Selesaikan 6 bit lagi dalam 30 tahun ke depan, dan Anda telah berhasil memfaktorkan 1 detik dari RSA 256-bit, selamat, perjalanan panjang untuk mencapai RSA 2048-bit dalam kerangka waktu yang wajar.

Bahkan 15 tahun untuk RSA 512-bit yang meningkat dari 6 bulan menjadi 4 jam adalah 24hr * (6month * 30day) = 4320hr / 4hr = log2(1080hr) = 10 ~2^10. Itu pasti lebih baik dari pengurangan, ~1k kali lebih baik, tetapi masih bukan tingkat yang mengkhawatirkan dibandingkan. Saya pikir itu lebih lanjut didukung oleh bagaimana kemajuan telah melambat dengan para akademisi dapat memperhitungkan ukuran kunci RSA yang lebih besar.

Ini juga cukup terlihat di benchmark cado-nfs untuk memfaktorkan kunci RSA. RSA-120 adalah 1.9h, RSA-130 adalah 7.5h (dan bukan 81d seperti yang diharapkan), RSA-140 adalah 23h (dan bukan 227y) dan RSA-155 adalah 5.3d (dan bukan 7452 milenium).

Dari mana waktu yang diharapkan untuk menghitung ini berasal? RSA-155 (alias RSA 512-bit) diperhitungkan dalam 6 bulan yang lalu pada tahun 1999 , RSA-120 (397-bit RSA) dan RSA-130 (430-bit RSA) juga kemungkinan hanya berbeda sekitar 1-2 bit simetris ? Jadi peningkatan kira-kira 4 kali lipat diharapkan...?

Inilah sebabnya mengapa entitas seperti ANSSI atau NIST mendasarkan rekomendasi mereka tidak hanya pada kemampuan komputer atau pengetahuan kriptografi terkini, tetapi juga pada peningkatan di masa mendatang yang diharapkan terjadi dalam jangka waktu penggunaan kunci/kebermaknaan

Anda belum memberikan sesuatu yang substansial yang menunjukkan RSA 2048-bit mendekati lemah, bahkan dengan konteks historis di mana peningkatan penting telah dilakukan, sepertinya itu tidak terlalu relevan dengan peningkatan eksponensial. Anda tampaknya mengambil pandangan yang agak linier? Saya harap Anda mengetahui mengapa AES 128-bit dianggap aman (tampaknya mungkin lemah untuk Komputer Quantum suatu hari nanti menggunakan algoritma Grover) dan bahwa AES 256-bit dikatakan membutuhkan seluruh energi tata surya kita untuk menjadi habis untuk retak oleh bruteforce.

Selanjutnya, pertimbangkan data sensitif apa yang Anda coba lindungi tanpa mempertimbangkan praktik terbaik seperti hanya menggunakan cipher suite berkemampuan PFS, di mana data ini juga dianggap bermasalah untuk berpotensi didekripsi beberapa dekade dari sekarang (cukup sedikit data sensitif tidak sepenting dekade dari sekarang seperti saat ini).

TL;DR

Itu datang ke ini cukup banyak. Melanggar 2048-bit, bahkan jika beberapa dekade dari sekarang, masih akan sangat mahal, tetapi mari kita optimis dan katakan 1 juta dolar dan 10 tahun (atau 1 jika Anda suka).

• Apakah penyerang ini tertarik pada Anda secara khusus sekarang karena mereka akan dilengkapi untuk merekam lalu lintas server Anda untuk pengguna N (di mana N tidak masalah di luar persyaratan penyimpanan, karena Anda tidak aman menggunakan kunci yang sama untuk semua enkripsi bagaimanapun) .
• Lalu lintas ini akan dicatat selama X tahun, di mana setiap 90 hari sertifikat Anda berubah memerlukan serangan terpisah untuk masing-masing (waktu dan $$$$)? Atau penyerang mengetahui sebelumnya kapan harus merekam data tertentu yang mereka minati, meskipun perlu beberapa dekade sebelum mereka yakin dapat memecahkan enkripsi?
• Entah bagaimana ini adalah strategi yang lebih baik dan lebih murah daripada meretas server atau klien pengguna Anda secara langsung dan membahayakan sistem itu (maksud saya, mereka telah menempatkan diri mereka dalam serangan MitM untuk menangkap lalu lintas dan sudah mati untuk mengakses rahasia Anda dengan dana yang memadai, kan? ), apakah mereka tidak memiliki sumber daya yang tersedia untuk memilih serangan yang lebih praktis?
• Bukankah lebih murah & lebih mudah untuk mengancam atau memeras seseorang secara langsung untuk mendapatkan akses ke kunci pribadi RSA? Maka panjang kunci tidak masalah, jika Anda pintar dan hanya menggunakan suite sandi PFS, strategi ini tidak akan relevan.

Soooo pokoknya...

Dorong suite sandi PFS (DHE / ECDHE) bukan perbaikan kecil pada praktik keamanan buruk bandaid

Jadi saran Anda untuk meningkatkan keamanan di sini adalah mendorong penggunaan ukuran kunci yang lebih besar daripada mendorong suite sandi hanya PFS? Mengapa?

Karena LE memiliki ukuran kunci default, bukan pada konfigurasi httpd. Dan LE sudah mengambil tindakan di masa lalu (penonaktifan https pada HTTP-01, penghapusan TLS-SNI-01…) alih-alih menerapkan konfigurasi httpd.

Mohon dijabarkan lebih lanjut.

Tentu. Dan sederhananya lihat benchmark dari cado-nfs. Waktu untuk cracking bukanlah waktu teoritis yang diharapkan.
Kesenjangan kesulitan teoritis tidak diamati dalam praktek karena dua bias. Kami hanya dapat membandingkan waktu retak untuk keadaan seni tertentu dan pada waktu saat ini yang sama dan mengharapkan kesenjangan teoretis (dan dalam praktiknya, tidak demikian, lihat cado-nfs), tetapi tidak ada yang memastikan bahwa bit X+1 adalah 2 kali lebih sulit dari X jika kita membandingkan pengetahuan & kekuatan perhitungan saat ini dan apa yang akan kita miliki 1 bulan kemudian.
Dan lihat juga 2 contoh yang saya berikan. Hanya ada celah 2 kali antara celah 256 dan 512 bit antara 2015 & 2019 dengan kekuatan & biaya yang sama, di mana secara teori ada celah 10 kali.
Dan kami tidak dapat memastikan tidak akan ada trik break 3072 RSA besok di mana 4096 bit akan tetap lebih aman.

Saya telah menautkan ke proyek Github yang dapat melakukan pemfaktoran 512-bit di AWS. Saya tidak tahu jumlah pasti bit entropi simetris dari 256-bit RSA, mungkin sekitar 30-bit? (jadi kira-kira 1.048.576 kali perbedaan antara RSA 512-bit). Makalah 512-bit yang Anda tautkan menyebutkan 432 CPU (masing-masing 12 instance dengan 36 vCPU + 60GiB RAM) dan total 2770 jam CPU dengan memori atau penyimpanan 1,5-2GB untuk matriks (saya tidak terlalu terbiasa dengan perhitungan ini, jika Anda merasa bebas untuk berpadu).

Ya, sepertinya jumlah yang besar dan tidak praktis… Pada saat pemecahan 512 bit pertama (1999), dianggap tidak praktis karena membutuhkan komputer super tidak ada yang punya. Namun faktanya, tagihan AWS terkait untuk infrastruktur semacam itu pada tahun 2015 adalah… $100 untuk 4 jam dan IS praktis beberapa tahun kemudian, sebagian besar lebih cepat daripada kesenjangan miliaran miliaran miliar yang diharapkan pada tahun 1999.
https://arstechnica.com/information-technology/2015/10/breaking-512-bit-rsa-with-amazon-ec2-is-a-cinch-so-why-all-the-weak-keys/

Hanya ada celah 2 kali antara celah 256 dan 512 bit antara 2015 & 2019 dengan kekuatan & biaya yang sama, di mana secara teori ada celah 10 kali.

Apa... tidak. Saya sudah sangat jelas tentang hal ini kepada Anda dalam posting saya bahwa perbedaan antara 256-bit dan 512-bit bukanlah 2^256(basis Anda 10, 10^77), tetapi lebih seperti 2^20 atau kurang (di perbandingan yang saya lakukan dari dua contoh anjak piutang Anda yang dikutip itu sekitar 2 ^ 17).

Saya juga tidak yakin bagaimana Anda mengklaim "kesenjangan 2 kali"? Kekuatan dan biaya yang sama? RSA 256-bit diperhitungkan dalam kira-kira 1 menit, dengan RSA 512-bit setara dengan 166.200 menit (matematika dikutip dalam posting saya sebelumnya, jangan ragu untuk mengoreksi saya jika saya melakukan kesalahan).

Dan kami tidak dapat memastikan tidak akan ada trik break 3072 RSA besok di mana 4096 bit akan tetap lebih aman.

Anda benar-benar akan baik-baik saja dengan RSA 2048-bit, RSA 3072-bit memiliki peningkatan keamanan "marjinal", saya sudah menjelaskan ini, Anda sepertinya melewatkannya atau salah paham? Satu-satunya cara RSA 2048-bit menjadi tidak aman dalam rentang waktu yang jauh lebih singkat adalah ketika RSA 3072-bit Anda akan terancam dari tingkat kemajuan.

Jika ingin lebih aman, jangan gunakan RSA untuk pertukaran kunci. Saya telah meminta Anda untuk mengutip satu situs web di mana pertukaran kunci RSA diperlukan ((EC) DHE tidak didukung/dinegosiasikan untuk alasan apa pun), mengapa Anda tidak dapat menjawab ini, Anda mengklaim itu adalah kejadian umum yang membenarkan kenaikan harga. panjang kunci RSA default? Tolong dukung pernyataan itu. Anda mungkin menemukan server yang menawarkan RSA sebagai pertukaran kunci, mereka kemungkinan akan mengaktifkan pilihan rangkaian sandi server dan tidak akan dinegosiasikan oleh klien mana pun yang dapat mendukung rangkaian sandi PFS.

Namun faktanya, tagihan AWS terkait untuk infrastruktur semacam itu pada tahun 2015 adalah… $100 untuk 4 jam dan IS praktis beberapa tahun kemudian, sebagian besar lebih cepat daripada kesenjangan miliaran miliaran miliar yang diharapkan pada tahun 1999.

Biaya perangkat keras jauh lebih tinggi dari $100, bukan jumlah yang konyol, tapi ya ketersediaan untuk dengan mudah menyewa/mengakses sumber daya komputasi seperti itu telah membuatnya lebih mudah diakses. Perhatikan perangkat keras yang digunakan, itu bukan instans EC2 yang murah/kecil, ini adalah mesin yang cukup besar dalam hal menyewa sumber daya komputasi, kami memiliki RSA 768-bit yang diperhitungkan selama lebih dari satu dekade sekarang, namun Anda tidak melihat FaaS menjadi mampu menangani itu dengan murah? RSA 2048-bit masih jauh.

Apakah Anda memiliki sumber siapa pun yang mengklaim 512-bit diperlukan lebih dari satu miliar untuk menghitung? Cukup yakin sumber daya perangkat keras pada tahun 1999 yang diperhitungkan hanya dalam 6 bulan adalah jauh dari biaya miliaran. Dari mana harga ini berasal? Dari pernyataan yang lebih baru tentang bit keamanan yang lebih tinggi? Itu karena peningkatan eksponensial dalam kesulitan, yang tidak hanya membutuhkan lebih banyak waktu komputasi, tetapi sumber daya lain seperti RAM. Instans AWS faktor RSA 512-bit tersebut memiliki RAM 60GB, masing-masing (total 720GB)...

Lihat sekilas beberapa wawasan pemrosesan:

RSA-250 (829-bit RSA) yang difaktorkan pada tahun 2020 dicapai dalam waktu 3 bulan dengan puluhan ribu komputer dan menggunakan CADO-NFS yang ingin Anda tampilkan, tampaknya mereka telah mencapai pemfaktoran dalam ~kira-kira jumlah waktu komputasi yang sama~ ( EDIT: kesalahan saya, tahun, bukan jam) seperti yang dicapai oleh anjak AWS RSA 512-bit pada tahun 2015 (kira-kira 2700 jam CPU, AFAIK yang dinormalisasi ke Intel Xeon Gold 6130 2.1GHz yang direferensikan). RSA-240 (795-bit RSA) yang diperhitungkan pada Des 2019 menarik karena dibuat oleh tim yang sama dan pada perangkat keras yang sama yang memfaktorkan RSA 768-bit pada tahun 2010/2016 (juga menggunakan CADO-NFS). Mereka mencatat peningkatan algoritme dalam perangkat lunak CADO-NFS karena itulah yang memungkinkan peningkatan kinerja ~3x.

Berikut makalah tentang Anjak 2010 RSA 768-bit , lihat persyaratan RAM:

Tahap pertama dibagi menjadi delapan pekerjaan independen yang dijalankan secara paralel pada kelompok tersebut, dengan masing-masing dari delapan urutan menunjuk sekali setiap 214 langkah. Menjalankan urutan tahap pertama (atau ketiga) membutuhkan RAM 180 GB , satu b dengan lebar 64 bit membutuhkan 1,5 gigabyte, dan matriks mi tunggal 8 kilobyte, di mana rata-rata 565.000 disimpan per urutan tahap pertama. Setiap jumlah parsial selama evaluasi tahap ketiga membutuhkan 12 gigabyte .

Sebagian besar waktu, RAM 896 GB yang tersedia sudah mencukupi, tetapi selama bagian tengah perhitungan diperlukan lebih banyak memori (hingga sekitar 1 TB)

Dan mari kita kontraskan dengan faktor RSA 512-bit (2009, bukan AWS pada 2015) :

Pada tahun 2009, Benjamin Moody dapat memfaktorkan kunci bit RSA-512 dalam 73 hari hanya menggunakan perangkat lunak publik (GGNFS) dan komputer desktopnya (Athlon64 dual-core dengan cpu 1.900 MHz). Hanya kurang dari lima gigabyte penyimpanan disk yang dibutuhkan dan sekitar 2,5 gigabyte RAM untuk proses penyaringan.

Itu akan memberikan skala kasar penskalaan persyaratan RAM karena panjang kunci bertambah. Saya yakin mungkin ada hambatan lain yang harus diperhatikan dengan pemrosesan, terutama saat melakukannya secara terdistribusi. Jangan ragu untuk melihat lebih jauh dan mengidentifikasi berapa banyak RAM yang diperlukan untuk menyerang RSA 2048-bit.

Siapa yang sebenarnya Anda coba lindungi dari yang dilengkapi untuk menargetkan Anda atau lalu lintas pengguna Anda secara khusus untuk merekamnya dan melakukan serangan beberapa dekade dari sekarang?

Bukan skrip kiddy yang menunggu solusi AWS $ 100, mereka akan beralih ke hal-hal yang lebih baik saat itu dan mengorbankan jaringan Anda untuk merekam lalu lintas akan memakan biaya lebih banyak, jika tidak, itu adalah beberapa malware di mana tidak ada yang ditargetkan secara spesifik, selamat data Anda yang direkam tersegmentasi ke dalam periode 90 hari lalu lintas per kunci RSA sekarang berada di lautan banyak lainnya, ribuan, jutaan mungkin, $ 100 AWS bahkan jika mungkin tidak akan terlalu murah untuk menyerang semua itu, terutama ketika data memiliki nilai yang tidak diketahui, akan ada banyak sampah untuk membuang uang.

Tidak, jika seseorang menginginkan rahasia Anda, ada cara yang lebih terjangkau.

Untuk beberapa alasan, Anda memiliki keyakinan bahwa keamanan 4 miliar kali lebih kuat dari RSA 1024-bit ke 2048-bit tidak memadai, tetapi keamanan 65k kali lebih banyak dari RSA 2048-bit ke 3072-bit sudah memadai. Argumen Anda adalah bahwa teori keamanan 2048-bit menjadi aman secara komputasi tidak valid, tetapi entah bagaimana logika yang sama untuk RSA 3072-bit tidak berlaku dan itu jauh lebih aman? Apakah pintu kaca lebih aman karena saya menambahkan kunci yang lebih besar dan lebih aman?

TL;DR

Silakan periksa TL; DR sebelumnya, tetapi saya akan mengulanginya..

• Seseorang ingin merekam lalu lintas terenkripsi Anda menggunakan kunci RSA 2048-bit yang lemah .
• Mereka mampu melakukan serangan MitM ini, sehingga mereka memiliki keterampilan atau uang dan itu mungkin serangan yang ditargetkan.
• Data Anda harus mempertahankan nilainya di masa depan yang diinginkan untuk diperoleh sekarang meskipun hanya dapat didekripsi dalam 20+ tahun menurut perkiraan Anda.
• Serangan harus dapat dibenarkan untuk biaya yang harus dikeluarkan untuk mendapatkan nilai rahasia, harus diketahui jendela 90 hari mana yang akan ditangkap, jika tidak, serangan harus dihitung beberapa kali dengan harapan mendapatkan rahasia tersebut.
• Serangan ini entah bagaimana lebih efektif daripada metode lain untuk memperoleh data tersebut dengan cara yang lebih cepat / lebih murah?

Siapa yang waras akan melakukan itu? Itu hanya akan praktis pada target bernilai tinggi di mana tidak ada cara lain untuk mendapatkan informasi itu yang layak. Target tersebut entah bagaimana memiliki rahasia berharga seperti itu tetapi tidak repot-repot membayar seorang profesional atau mempertimbangkan praktik terbaik dalam mengamankannya (mereka tampaknya tidak dapat mengatur server dengan salin/tempel saran cipher suite Mozilla).

Ini tidak terlalu meyakinkan. Ini bukan LetsEncrypt, Anda berasumsi pengguna dengan rahasia berharga menggunakan Certbot bersama dengan rangkaian sandi pertukaran kunci RSA yang didukung oleh server mereka (tidak ada konfigurasi default yang melakukan ini), dan RSA 2048-bit jauh lebih lemah dari itu? Siapa pun pengguna ini, praktik keamanan mereka di tempat lain mungkin cukup lemah untuk mengkompromikan mereka secara langsung, mengapa harus menunggu 20-30 tahun untuk mendekripsi data ketika Anda dapat melakukan serangan aktif dan mendapatkan semua data menarik saat ini?

Solusi yang tepat adalah menyiapkan suite sandi dengan benar, dan proyek Certbot ini melakukan hal itu jika Anda tidak berpengalaman di bidang tersebut dan ingin mengandalkannya untuk mengurusnya untuk Anda. Tapi untuk beberapa alasan, itu tidak berlaku untuk diskusi ini?

Saya telah meminta Anda untuk mengutip satu situs web di mana pertukaran kunci RSA diperlukan ((EC)DHE tidak didukung/dinegosiasikan karena alasan apa pun)

https://cryptcheck.fr/https/bankofamerica.com (ya, Anda membacanya dengan benar)
https://cryptcheck.fr/https/caf.fr (administrasi negara untuk Prancis, setara dengan Pendapatan Keamanan Tambahan AS)
https://cryptcheck.fr/https/xn--trkiye-3ya.gov.tr
https://cryptcheck.fr/https/pfisng.dsna-dti.aviation-civile.gouv.fr
https://cryptcheck.fr/https/reader.xsnews.nl
https://cryptcheck.fr/https/protecpo.inrs.fr
https://cryptcheck.fr/https/tiscali.it

Saya menghitung 68 domain non PFS pada CryptCheck v2 saya selama 7221 analisis jabat tangan (~0,9%) dan 2091 lebih dari 349961 analisis jabat tangan (~0,6%) di v1 saya.

https://www.bankofamerica.com/

Protokol: TLS 1.2
Pertukaran kunci: ECDHE_RSA
Grup pertukaran kunci: P-256
Sandi: AES_128_GCM
CA: Percayakan

https://cryptcheck.fr/https/bankofamerica.com seharusnya mengidentifikasi IP server tambahan untuk domain yang sama yang tidak menyediakan pertukaran kunci ECDHE?

https://www.caf.fr/

Protokol: TLS 1.2
Pertukaran kunci: RSA
Cipher: AES_128_CBC dengan HMAC-SHA1
CA: Certinga

Saya tidak tahu tentang apa situs web ini atau rahasia sensitif apa yang harus dieksploitasi?

https://www.turkiye.gov.tr/

Protokol: TLS 1.2
Pertukaran kunci: RSA
Cipher: AES_128_CBC dengan HMAC-SHA1
CA: GlobalSign

Saya dialihkan ke ini dari nama domain Anda yang tampak aneh sehingga saya tidak dapat membayangkan siapa pun akan mengunjungi secara langsung dan menganggapnya sah/dapat dipercaya dari sebuah nama.

Ini seperti banyak orang lain berikut ini jelas merupakan situs web pemerintah. Mereka sering tertinggal dan perlu dapat diakses oleh khalayak luas, RSA seharusnya tidak menjadi pertukaran kunci default, tetapi sekali lagi, komunikasi apa yang terjadi di sini yang ingin Anda lindungi? Pemerintah sendiri jelas tidak terlalu peduli.

https://pfisng.dsna-dti.aviation-civile.gouv.fr/jts/auth/authrequired

Protokol: TLS 1.2
Pertukaran kunci: RSA
Sandi: AES_128_GCM
CA: Certinga

Sekali lagi, tidak tahu apa ini selain layanan pemerintah dengan login. Apakah ada informasi sensitif di luar detail login? Apa kekhawatiran di sini mengenai akses ke informasi sensitif 20-30 tahun dari sekarang? Bahwa saya menggunakan nama pengguna dan kata sandi yang sama di tempat lain dan masih terus melakukannya dalam waktu 20-30 tahun?

Bukankah penipuan phishing akan sama efektifnya jika detail login diinginkan (dan nilai data pada akun). Bisakah itu dicapai dalam waktu yang lebih singkat atau anggaran yang lebih kecil daripada menyerang sertifikat RSA?

https://reader.xsnews.nl/

Lebih dari satu menit yang dihabiskan untuk mencoba memuat/menyelesaikan URL, saya tidak dapat mengakses situs web ini.

https://protecpo.inrs.fr/ProtecPo/jsp/Accueil.jsp

Protokol: TLS 1.2
Pertukaran kunci: RSA
Sandi: AES_128_GCM
CA: GEANT

Tampaknya ini adalah situs web untuk beberapa perangkat lunak yang dapat Anda gunakan untuk membantu membuat keputusan pembelian. Informasi sensitif apa yang berisiko di sini?

https://www.tiscali.it/

Protokol: TLS 1.2
Pertukaran kunci: RSA
Sandi: AES_256_CBC dengan HMAC-SHA1
CA: Thawte

Situs berita? Sekali lagi, informasi sensitif apa yang menjadi perhatian dalam berinteraksi dengan situs web ini?

Ringkasan

Tidak ada satu pun dari hasil ini yang menunjukkan kebutuhan untuk melindungi komunikasi sensitif di luar perkiraan 20-30 tahun RSA 2048-bit yang disusupi. Situs web ini masih memerlukan serangan MitM yang efektif untuk menangkap lalu lintas antara klien dan server yang kemungkinan besar bukan merupakan masalah yang valid untuk salah satu dari mereka?

Tak satu pun dari ini menggunakan sertifikat yang dikeluarkan LetsEncrypt. Membuat perubahan untuk Certbot hanya bermanfaat jika Anda tahu pasti situs web tersebut menggunakan Certbot secara khusus sebagai klien ACME untuk CA tersebut (dengan asumsi mereka memiliki dukungan ACME pihak ketiga).

Terima kasih telah benar-benar menunjukkan beberapa situs web di mana RSA adalah pertukaran kunci yang dinegosiasikan (kecuali Bank of America yang tampaknya salah dan hanya divalidasi sebagai rangkaian sandi untuk situs web yang menghadap publik, bukan pertukaran sensitif yang sebenarnya).

Saya menghitung 68 domain non PFS pada CryptCheck v2 saya selama 7221 analisis jabat tangan (~0,9%) dan 2091 lebih dari 349961 analisis jabat tangan (~0,6%) di v1 saya.

Oke, jadi "tidak jarang" Anda kurang dari 1% dari 7.221 dan 349.961 situs web yang telah Anda pindai dengan CryptCheck? Sekarang pertimbangkan audiens dan nilai terukur aktual yang ditawarkan dengan menggunakan RSA 3072-bit alih-alih untuk mengamankan komunikasi tersebut, apakah itu benar-benar mengamankan sesuatu yang berharga dan apakah itu akan lebih aman dari alternatif yang lebih murah untuk membahayakan keamanan? (seperti pada, 2048-bit lebih lemah/lebih murah daripada serangan bertarget alternatif lainnya, di mana 3072-bit meningkatkan batas bawah serangan)

Berapa banyak dari 1 juta situs teratas Alexa yang menegosiasikan pertukaran kunci RSA? Berapa banyak dari mereka yang ditemukan menggunakan LetsEncrypt sebagai CA?

Saya menghitung bit simetris untuk RSA 512-bit dan 256-bit (berdasarkan persamaan dari NIST), dan kami mendapatkan 40-bit (RSA 256-bit), dan 57-bit (RSA 512-bit).

Menariknya, itu cocok dengan perbedaan 17-bit yang dikutip sebelumnya ketika membandingkan kedua komputasi dengan kemajuan terbaru (tampaknya dokumen NIST yang saya rujuk terakhir diperbarui pada tahun 2020).

Ini juga mengungkapkan bahwa jarak ke RSA 1024-bit hanya 23-bit dengan kekuatan kunci simetris yang setara, 8.388.608. Dan kita dapat melihat bahwa kemajuan saat ini untuk RSA 768-bit dan 795-bit atau rekor RSA 829-bit saat ini adalah:

768 == 69.74588053597235
795 == 70.91595938496408
829 == 72.35600867501326

• Rekor RSA 768-bit sejak 2010 dengan RSA 829-bit sebagai rekor pada 2020, peningkatan kurang dari 3-bit selama rentang satu dekade. 2000 vs 2700 tahun CPU (single-core). RSA 795-bit turun menjadi 900 tahun CPU pada November 2019.
• 57-bit (512-bit RSA) hingga 72-bit (829-bit RSA) dengan ~2700 jam komputasi~ ( EDIT: jam vs tahun, ups) antara 2015 dan 2020. ~15-bit (32,768) peningkatan~? (829-bit RSA membutuhkan waktu 3 bulan dan puluhan ribu mesin sebagai perbandingan). Faktor RSA 768-bit (Desember 2009) & 795-bit (Nov 2019) yang disorot menjadi sekitar 3x lebih cepat karena peningkatan perangkat lunak/algoritma saja.
• 2^6 (64) perkiraan untuk peningkatan RSA 256-bit sejak 1991.
• ~2^10 (1024) untuk perbedaan 1080 x dengan 512-bit selama 16 tahun (1999 - 2015) 6 bulan vs 4 jam, tidak jelas seberapa akurat perbandingannya, 8.000 MIPS tahun vs 2770 tahun CPU Intel biasanya dirujuk. Perbedaan utama di sini mungkin karena akses untuk menyewa perangkat keras secara murah dengan komputasi awan untuk mengurangi waktu, sambil memanfaatkan 15 tahun peningkatan HW dan peningkatan algoritme pada perangkat lunak sejak itu.

Saya baru saja menyadari bahwa saya telah membuat kesalahan sebelumnya ketika mengutip faktor RSA 829-bit dan membandingkannya dengan waktu faktorisasi RSA AWS 512-bit. Keduanya mengutip ~2700 unit komputasi waktu, tetapi saya tersandung dengan RSA 829-bit menjadi tahun, dan RSA 512-bit menjadi jam. Tampaknya ada perbedaan sekitar 8.760 ( (8760hrs * 2700yrs) / 2700hrs , di mana 8.760 adalah jam dalam setahun) kali (2^13) yang menurut saya adalah 4 tahun ( (4hrs * 8760hrs) / 24hrs / 365days ) yang akan mendekati satu juta dolar waktu komputasi di AWS? (mengabaikan fakta bahwa Anda mungkin membutuhkan lebih banyak RAM)

256-bit RSA 1 menit waktu komputasi vs 829-bit RSA 2700 tahun waktu komputasi = log2(525600mins * 2700yrs) (menit dalam setahun) sama dengan kira-kira 2^30. Sekali lagi, mirip dengan kesulitan komputasi RSA 512-bit, ini cukup mendekati delta dengan asumsi perbedaan kekuatan 2^32 bit. Kami mungkin dapat memfaktorkan kunci RSA lebih cepat, tetapi kesulitan komputasi tampaknya dipertahankan secara kasar?

Bukan informasi terbaik, tetapi cukup untuk mendapatkan gambaran kasar tentang tingkat kemajuan dan peningkatan.

• Kesulitan untuk menghitung secara kasar akurat dan konsisten selama beberapa dekade?
• Tingkat peningkatan komputasi untuk melakukan pemfaktoran lebih cepat telah meningkat dengan baik, tetapi tidak dengan jumlah yang signifikan?

1024-bit masih akan tetap di luar jangkauan untuk beberapa waktu, dan 2048-bit terlebih lagi berdasarkan kemajuan historis yang dibahas di atas. Ada sedikit bukti bahwa RSA 3072-bit dengan tambahan 2^16 (65k) hingga 2^22 (4 juta) bit kesulitan ekstra akan menghasilkan lebih banyak keuntungan keamanan daripada 2^30 (1 miliar) hingga 2^ 32 (4 miliar) 2048-bit memiliki lebih dari 1024-bit RSA. (bukannya itu tidak menambah kesulitan tambahan yang mencolok, tetapi berdasarkan asumsi bahwa RSA 2048-bit itu sendiri tidak akan cukup bertahan ketika seharusnya)

Berdasarkan upaya RSA 829-bit saat ini, dan bahwa ada sekitar 38-bit perbedaan tingkat keamanan bit untuk RSA 2048-bit. Jika kita mengambil daya komputasi konstan yang memfaktorkan RSA 829-bit dalam 3 bulan (4 durasi tiga bulan dalam setahun), kita mendapatkan 68.719.476.736 tahun ( 2^38 / 4 ), bahkan jika kita memiliki kemajuan untuk menurunkannya menjadi 1 miliar kali lebih sedikit kerja (2^30), masih sekitar 64 tahun, dan itu dengan puluhan ribu mesin .

Jika Anda masih berpikir 3072-bit sebagai minimum bermanfaat meskipun matematika saya (mungkin buruk?), analisis biaya-manfaat, dan penalaran akal sehat ... maka saya tidak berpikir saya memiliki hal lain yang dapat saya sumbangkan untuk meyakinkan Anda sebaliknya .

Ingatlah bahwa Anda menganjurkan perubahan dengan Certbot, bukan LetsEncrypt yang memberlakukan minimum untuk diterbitkan. Certbot sudah membantu pengguna dengan mengonfigurasi rangkaian sandi yang tepat yang menghindari seluruh masalah, jadi siapa yang benar-benar akan diuntungkan di sini - sementara semua orang (menggunakan Certbot) yang tidak menggunakan RSA sebagai pertukaran kunci menambahkan lebih banyak beban dan bandwidth pada server mereka (bahkan jika kecil untuk sebagian besar).

Masalah harus ditutup.

https://www.keylength.com/

https://www.keylength.com/

Anda telah menyumbangkan informasi itu 4 tahun yang lalu di utas ini . Tampaknya Anda tidak memahami konteks saran dari situs web itu dan bagaimana penerapannya di sini.

Jika Anda merasa lebih nyaman dengan RSA 3072-bit atau panjang kunci yang lebih besar untuk sertifikat Anda, secara eksplisit ikut serta seperti yang sudah Anda dapat, tidak ada alasan yang dapat dibenarkan ketika peduli tentang keamanan pragmatis untuk mengadopsi 3072-bit sebagai default baru . RSA 2048-bit sudah cukup .

Anda telah menyumbangkan informasi itu 4 tahun yang lalu di utas ini . Tampaknya Anda tidak memahami konteks saran dari situs web itu dan bagaimana penerapannya di sini.

Anda tidak lebih mengerti. Saran ANSSI misalnya

Sebagai bagian dari pengembangan teleservices dan pertukaran elektronik antara administrasi dan pengguna, otoritas administratif harus menjamin keamanan sistem informasi mereka yang bertanggung jawab atas pelaksanaan layanan ini.
Referensi Keselamatan Umum secara khusus dikenakan pada sistem informasi yang diterapkan oleh otoritas administratif dalam hubungan mereka satu sama lain dan dalam hubungan mereka dengan pengguna (ini adalah layanan jarak jauh seperti pembayaran denda kepada Administrasi).
Secara tidak langsung, Referensi Keamanan Umum ditujukan untuk semua penyedia layanan yang membantu otoritas administratif dalam mengamankan pertukaran elektronik yang mereka implementasikan, serta untuk produsen yang aktivitasnya menawarkan produk. keamanan.
Secara umum, untuk organisasi lain yang ingin menyelenggarakan pengelolaan keamanan sistem informasi dan pertukaran elektroniknya, Referensi Keamanan Umum disajikan sebagai panduan praktik yang baik sesuai dengan keadaan seni.

Dan begitu juga berlaku di Prancis untuk TUJUAN APA PUN DAN SARANA APAPUN , dan tidak dibatasi sama sekali untuk konteks yang masuk akal seperti tujuan militer.

Dan salah satu sarannya adalah "Disarankan untuk menggunakan modul minimal 3072 bit, bahkan untuk penggunaan tidak melebihi 2030 ". Dan 3072 bit tidak lagi merupakan saran tetapi wajib jika penggunaan/dampak diharapkan setelah 2030.

Bahkan CNIL, entitas Prancis tentang privasi & praktik yang baik, gunakan kertas ANSSI di dalamnya rekomendasi standar untuk situs web apa pun : https://www.cnil.fr/fr/securite-securiser-les-sites-web

ANSSI telah menerbitkan di situsnya rekomendasi khusus untuk menerapkan TLS atau untuk mengamankan situs web.

(Dan juga bertentangan dengan Let's Encrypt karena menyatakan bahwa Anda harus you must authorize only incoming IP network flows on this machine on port 443 and block all the other ports. tetapi this )

Saran NIST tidak terikat pada kepekaan menyampaikan informasi, tetapi saran umum berlaku di hampir semua kasus Anda harus mengelola kunci atau sertifikat juga.

Ini bukan pertama kalinya LE menggunakan konfigurasi default yang bertentangan dengan saran canggih dari lembaga pemerintah atau lainnya…

Oh, dan BSI mengulasnya tahun ini. Ini menyatakan dari

Catatan Penting: Masuk akal untuk menggunakan panjang kunci 3000 bit untuk RSA , DH, dan DSS, untuk mencapai tingkat keamanan yang homogen untuk semua mekanisme asimetris. Mulai tahun 2023, panjang kunci minimal 3000 bit diperlukan untuk implementasi kriptografi yang harus mematuhi Pedoman Teknis ini.

@aeris bahkan jika Prancis memberlakukan RSA 3072-bit sebagai wajib, itu bukan hukum di tempat lain. Perhatikan bahwa saran dan rekomendasi juga tidak sama dengan persyaratan wajib.

Saya akan terkejut jika mereka juga menyarankan menggunakan pertukaran kunci RSA di suite sandi sebagai praktik terbaik untuk keamanan/privasi. Jika Anda ingin menangani keamanan dan privasi dengan benar, gunakan suite sandi khusus PFS, sertifikat RSA Anda tidak akan relevan sejak saat itu karena hanya berperan dalam otentikasi.

Bagaimanapun, saya merasa saya mengulangi diri saya di sini dan saya tidak tertarik pada bolak-balik tanpa akhir. Jika Anda harus mematuhi otoritas/penasihat keamanan tertentu, maka lakukanlah dengan tegas tentang hal itu. Saya sudah merinci dengan cukup baik bahwa 2048-bit aman dan akan tetap demikian untuk masa mendatang, jika tidak, RSA 3072-bit juga tidak lagi mungkin aman.

Karena Anda agak bersemangat tentang topik ini, silakan coba dan pahami apa yang telah saya sampaikan kepada Anda, alih-alih membaca NIST / ANSSI / BSI / dll, lebih baik mereka memberi saran sedikit lebih tinggi dari yang dibutuhkan, mirip dengan bagaimana AES- 128 diperkenalkan sebagai tingkat keamanan terendah/terlemah untuk AES tetapi cukup aman dengan sendirinya.

Semua yang Anda peroleh dari 3072-bit adalah perasaan palsu "lebih aman", karena 2048-bit lebih dari cukup sehingga jika tidak, tidak ada alasan untuk berpikir 3072-bit akan lebih aman karena itu tambahan 16-bit keamanan tidak akan mengikuti kemajuan tersebut. Lakukan hal yang cerdas dan jangan terus menggunakan RSA sebagai pertukaran kunci... jika Anda hanya mengandalkan panjang kunci RSA yang lebih besar sebagai rasa aman daripada menerapkan praktik keamanan di tempat lain, Anda membodohi diri sendiri.

Jika Anda ingin terus berdebat demi kepatuhan daripada manfaat keamanan yang sebenarnya, saya akan membiarkan Anda melakukannya. Secara pribadi itu bukan perubahan yang berharga untuk default, dan untuk sebagian besar pengguna Certbot kemungkinan tidak diinginkan karena kekurangan dan tidak ada keuntungan pragmatis dalam keamanan yang sebenarnya.

Ini bukan pertama kalinya LE menggunakan konfigurasi default yang bertentangan dengan saran canggih dari lembaga pemerintah atau lainnya…

Mungkin karena mereka tahu lebih baik, terlepas dari apa yang mungkin Anda pikirkan. Bahkan dengan semua informasi yang disajikan kepada Anda sebelumnya, Anda tampaknya tidak tertarik atau terbuka sama sekali.

Meskipun mungkin tidak akan meyakinkan Anda lebih jauh, inilah yang dibutuhkan kekuatan simetris 2^128-bit untuk berhasil menyerang :

Total konsumsi energi dunia saat ini adalah sekitar 500 EJ (5×10^20 J) per tahun (atau begitulah kata artikel ini).

Ini akan menghasilkan total 2^138 pada tahun 2040 -- dan ini adalah untuk perhitungan tunggal selama sepuluh tahun yang memobilisasi semua sumber daya di seluruh planet .

Wawasan lain yang menghibur :

Singkatnya: bahkan jika Anda menggunakan semua dolar di Dunia (termasuk dolar yang tidak ada, seperti akumulasi hutang) dan menggoreng seluruh planet dalam prosesnya, Anda hampir tidak dapat melakukan 1/1000 dari pencarian kunci lengkap di kunci 128-bit .

Kunci enkripsi simetris 256-bit btw akan melebihi semua energi yang tersedia di tata surya kita untuk dipecahkan:

Hukum alam semesta fisik berarti bahwa bahkan kunci dengan ukuran sederhana ini tidak akan pernah dipaksakan secara kasar . Itu tidak berarti mereka tidak akan pernah bisa dihancurkan. Cacat dapat ditemukan dalam algoritma

tidak ada yang lebih kuat dari "tidak dapat memecahkannya" jadi membandingkan kekuatan di luar 100 bit atau lebih agak tidak ada artinya . - Sumber

Sekarang semua kutipan itu difokuskan pada kunci 128-bit seperti RSA 3072-bit, tetapi 110-112 bit RSA 2048-bit masih cukup besar. Namun jauh lebih murah untuk mengambil rute yang disarankan XKCD :)

Sepertinya argumen telah bergeser dari keamanan ke kepatuhan.

Sepertinya argumen telah bergeser dari keamanan ke kepatuhan.

Atau tidak. Ini hanyalah saran mutakhir dari entitas terkenal yang terkait dengan ekosistem keamanan tentang apa yang harus digunakan secara default untuk menghindari pemotretan di kaki Anda seperti yang kita lihat secara teratur di dunia TLS/X.509 setidaknya sejak satu dekade.