it-swarm-id.com

Enkripsi - haruskah saya menggunakan RSA atau AES?

Model saya adalah model di mana saya memiliki beberapa klien yang ingin berbicara dengan beberapa (tetapi tidak semua) klien lain.

Semua pesan akan dikirim melalui server.

Hanya dua klien yang berkomunikasi satu sama lain yang dapat mengetahui pesan tersebut. Jadi server DAN klien lain seharusnya tidak dapat mengetahui pesan apa yang dikirim.

Komunikasi antara dua klien dapat dimulai dan berakhir beberapa kali sehari.

Pesan akan berupa teks biasa dengan panjang potensial tidak terbatas, tetapi kemungkinan akan jauh lebih sedikit, pikirkan SMS pesan gaya.

Mengingat keadaan ini, bagaimana saya harus mengenkripsi pesan? Saya tidak keberatan menulis kode tambahan jika mengarah pada kecepatan atau efisiensi yang lebih baik.

Saya tahu dasar-dasar kasar bagaimana RSA dan AES bekerja tetapi saya tidak tahu apa yang terbaik.

Saat Anda membuat pasangan kunci publik/pribadi untuk RSA, apakah ada situasi di mana Anda perlu membuat pasangan baru? Atau bisakah satu klien memiliki satu kunci publik dan memberikan kunci yang sama kepada siapa saja yang ingin berbicara dengannya dan hanya dia yang dapat (pernah) membaca pesan, tetapi mereka menyimpan kunci publik untuk semua pesan di masa depan?

Atau haruskah saya memiliki kunci AES simetris yang terpisah untuk sepasang klien dan cukup membagikannya ketika kontak pertama kali dimulai dan menggunakannya selamanya. Sekali lagi, apakah ada keadaan di mana ini perlu dihasilkan lagi?

Bagaimana cara saya menyimpan kunci agar tetap ada jika klien crash/shutdown/reboot?

39
Cheetah

Tidak, kecuali keduanya. Anda mengajukan pertanyaan yang salah . Anda seharusnya tidak memikirkan algoritma kriptografi pada tahap ini, tetapi tentang protokol kriptografi.

Protokol kriptografi sulit dirancang, dan sering menjadi sumber bug keamanan. Anda tidak sepenuhnya memahami kriptografi kunci publik, sehingga Anda tidak siap untuk menggunakannya dalam protokol kriptografi Anda sendiri.

Pada tingkat tinggi, model Anda dapat menerima kriptografi kunci publik (mis. RSA). Biarkan setiap klien memiliki kunci privasinya sendiri dan publikasikan kunci publiknya ke klien lain. Kunci pribadi klien tidak berubah dari waktu ke waktu, kecuali jika klien telah dikompromikan. Kriptografi simetris (mis. AES) tidak akan skala dengan baik di sini karena setiap pasangan klien harus memiliki kunci rahasia sendiri.

Gunakan perangkat lunak yang ada bila memungkinkan. Menerapkan protokol kriptografi hampir sama rumitnya dengan mendesainnya. Untuk model di mana klien sesekali mengirim pesan satu sama lain, gaya email, alat yang akan berfungsi dengan baik adalah GnuPG . (Untuk komunikasi dua arah, gunakan SSL/TLS .)

Jadi: untuk operasi sehari-hari, untuk mengirim pesan, hubungi gpg, mengenkripsi dengan kunci publik penerima, dan sementara Anda melakukannya, tandatangani dengan kunci pribadi pengirim. Saat menerima pesan, periksa tanda tangan terhadap kunci publik pengirim yang dimaksud, dan dekripsi dengan kunci pribadi penerima. Dengan kata lain, kirim dengan gpg --sign --encrypt -r NAME_OF_RECIPIENT dan terima dengan gpg --verify diikuti oleh gpg --decrypt.

Masalah yang tersisa adalah masalah distribusi kunci. Setelah klien menghasilkan pasangan kunci, klien perlu memberi tahu klien lain tentang hal itu dan mendistribusikannya tanpa membiarkan kunci publik dicegat dan diganti dalam perjalanan oleh penyerang. Cara melakukan ini tergantung banyak skenario akurat Anda. Jangan abaikan keamanan bagian ini.

Jika, dan hanya jika, memohon GnuPG terbukti terlalu lambat, maka pertimbangkan untuk menggunakan implementasi protokol serupa yang lebih ringan, mungkin buatan rumahan (dari overhead rentang email ke SMS rentang overhead) .Di bawah kap, GnuPG menghasilkan kunci simetris untuk setiap pesan, karena kriptografi kunci publik mahal untuk pesan besar, algoritma kunci publik hanya digunakan untuk mengenkripsi kunci simetris dan untuk menandatangani intisari file. harus mengikuti model ini. Menggunakan AES untuk enkripsi simetris, SHA-256 sebagai algoritma cerna dan RSA sebagai algoritma kunci publik adalah pilihan yang baik.

Seperti yang sudah dikatakan oleh In silico, RSA dan AES melayani dua tujuan yang berbeda. AES adalah algoritma yang cepat, cocok untuk mengenkripsi seluruh percakapan. Tetapi ada masalah: bagaimana memutuskan kunci mana yang akan digunakan antara dua pihak tanpa yang lain mengetahuinya?

RSA dapat menjadi solusi untuk ini. Jika Setiap peserta memiliki kunci RSA publik dari setiap peserta lain, siapa pun dapat memulai komunikasi terenkripsi dengan orang lain (dengan menggunakan kunci publik peserta lain) dan memutuskan kunci AES rahasia untuk digunakan. Setelah kunci AES diputuskan, sisa percakapan dapat dienkripsi menggunakan AES. Untuk membuktikan bahwa kepada peserta B bahwa itu benar-benar A yang ingin diceritakan kepadanya, tanda tangan digital dapat digunakan.

Apa yang saya jelaskan adalah, grosso modo, apa yang dilakukan dengan jabat tangan SSL ketika browser terhubung dengan server web yang mendukung SSL.

19
JB Nizet

Jangan salah paham, tapi ...

Saya tahu dasar-dasar kasar bagaimana RSA dan AES bekerja tetapi saya tidak tahu apa yang terbaik.

Jika Anda hanya tahu dasar-dasarnya, Anda mungkin bukan orang yang tepat untuk menyelesaikan masalah ini (belum). Keamanan adalah salah satu area di mana Anda harus sangat khusus dan hati-hati atau Anda membatalkan seluruh pengaturan keamanan Anda.

Selain itu saya tidak percaya kami memiliki informasi yang cukup untuk memberi Anda jawaban yang tepat. Kontrak bisnis tentang ekspektasi keamanan harus diketahui di muka.

Dalam kebanyakan kasus, kunci tidak pernah meninggalkan mesin yang digunakan untuk alasan keamanan, jadi jika Anda berniat untuk "berbagi" informasi, maka solusi kunci publik biasanya merupakan pilihan yang tepat dari sudut pandang keamanan murni. Pengecualian untuk ini adalah jika Anda dapat membagikan kunci simetris dengan cara yang aman seperti mengirim kunci ke orang tersebut di media fisik.

6
Andrew White

Pada dasarnya, penggunaan enkripsi kunci publik (seperti RSA) jauh lebih mahal daripada penggunaan enkripsi kunci simetris (seperti AES), dan ketika ada banyak pesan yang berpindah dari satu ke yang lain, lebih baik menggunakan simetris kunci.

Sekarang, pembuatan dan pertukaran kunci simetris dapat dilakukan menggunakan enkripsi kunci publik.

Sebagai contoh:

Setiap klien memiliki pasangan kunci publik-publik, dan kunci publik disimpan di server. Ketika dua klien memulai sesi komunikasi, masing-masing mengambil kunci publik yang lain dari server dan mengirim nomor terenkripsi ke yang lain. Kemudian masing-masing pihak hash dua angka dan menggunakan hasilnya sebagai kunci untuk mengenkripsi/mendekripsi data mulai sekarang.

3
MByD

Jika Anda menggunakan gaya PUBLIC/PRIVATE (RSA dengan bit yang cukup :)) Anda dapat mengatur jenis komunikasi aman yang Anda uraikan dengan cara ini:

  1. Alice menulis pesan
  2. Alice mengenkripsi itu menggunakan Alice's PRIBADI kunci
  3. Alice mengenkripsi lagi menggunakan Bob's PUBLIK kunci
  4. Alice mengirimkan hasilnya kepada Bob.

Kemudian:

  1. Bob menerima pesan (seharusnya) dari Alice
  2. Bob mendekripsi menggunakan Bob's PRIBADI kunci
  3. Bob mendekripsi lagi menggunakan Alice's PUBLIC kunci
  4. Jika semuanya berjalan dengan baik, Bob membaca pesan itu.

Catatan:

  • Bob adalah satu-satunya yang dapat membaca pesan ini.
  • Bob tahu tanpa keraguan bahwa itu berasal dari Alice.

Mendapatkan kedua atribut tersebut dengan AES sedikit lebih sulit.

2
Jesse Chisholm