a16z memecahkan tiga pilihan utama dalam kriptografi Kunci Publik

金色财经_

Sumber: Noemi Glaeser, a16z crypto

Dalam Kriptografi Kunci Publik, selalu ada masalah yang sulit diatasi, yaitu bagaimana cara menghubungkan Kunci Rahasia (seperti Kunci Publik) yang dienkripsi dengan identitas spesifik (seperti orang atau organisasi). Masalah ini terletak pada kebutuhan untuk memiliki cara publik dan konsisten untuk menunjukkan hubungan antara identitas dan Kunci Publik, sehingga orang dapat dengan yakin menggunakan Kunci Publik tersebut untuk mengenkripsi informasi.

Jika tidak ada hubungan yang jelas seperti ini, orang lain mungkin tidak dapat menentukan siapa pemilik Kunci Publik tertentu, sehingga informasi enkripsi dapat dikirim ke orang yang salah, menyebabkan kebocoran informasi atau konsekuensi serius lainnya. Masalah ini masih ada dalam Web3.

Untuk masalah di atas, saat ini ada tiga solusi: Direktori Kunci Publik, enkripsi berbasis identitas (IBE), dan enkripsi berbasis registrasi (RBE). Ketiga metode ini memiliki kelebihan masing-masing dalam Anonimitas, interaktivitas, dan efisiensi. Misalnya, IBE memerlukan dasar kepercayaan yang kuat, tetapi dalam beberapa kasus, IBE memiliki kinerja yang lebih baik dalam Anonimitas dan efisiensi. Artikel ini bertujuan untuk mengeksplorasi aplikasi ketiga metode ini dalam Blok-on-chain, dan membandingkan kelebihan dan kekurangannya.

Tiga metode

Secara umum, metode umum untuk mengaitkan kunci terenkripsi dengan informasi identitas adalah dengan menggunakan infrastruktur kunci publik (PKI), di mana bagian intinya adalah direktori Kunci Publik. Dalam metode ini, pengirim informasi perlu berinteraksi dengan pihak ketiga yang terpercaya (biasanya lembaga yang memelihara direktori ini, seperti lembaga penerbit sertifikat) untuk mengirimkan informasi terenkripsi.

Namun, dalam lingkungan Web2, memelihara direktori Kunci Publik ini memerlukan biaya yang tinggi dan operasi yang rumit. Selain itu, pengguna juga menghadapi risiko penyalahgunaan kekuasaan oleh lembaga penerbitan sertifikat.

Beberapa alternatif yang diajukan oleh para kriptografer untuk mengatasi masalah infastruktur kunci publik (PKI). Pada tahun 1984, Adi Shamir mengusulkan enkripsi berbasis identitas (IBE), di mana identitas salah satu pihak (seperti nomor telepon, email, atau nama domain ENS) dapat langsung digunakan sebagai Kunci Publik. Pendekatan ini menghilangkan kebutuhan untuk memelihara direktori Kunci Publik, tetapi memperkenalkan masalah baru: harus bergantung pada pihak ketiga yang terpercaya (generator Kunci Rahasia) untuk menghasilkan Kunci Pribadi.

Pada tahun 2001, Dan Boneh dan Matthew Franklin mengusulkan konstruksi IBE yang pertama kali praktis, namun teknologi ini tidak banyak digunakan, terutama digunakan dalam beberapa sistem ekosistem tertutup, seperti lingkungan implementasi perusahaan atau pemerintah. Salah satu alasan mengapa IBE tidak digunakan secara luas mungkin karena ia membutuhkan asumsi kepercayaan yang kuat, yaitu kepercayaan pada pihak ketiga yang menghasilkan Kunci Rahasia.

Namun, seperti yang akan dibahas dalam teks berikut, masalah kepercayaan ini dapat diatasi dengan bergantung pada sebuah lembaga yang lebih lama (yaitu sekelompok peserta yang membentuk jumlah minimum yang sah), dan teknologi blockchain dapat dengan mudah mewujudkannya.

Kelebihan dan kekurangan

Saat membandingkan beberapa skema enkripsi ini, perlu mempertimbangkan banyak faktor yang berbeda. Saya membuat dua asumsi terkait hal ini:

Pengguna tidak akan memperbarui atau mencabut Kunci Rahasia mereka: Ini berarti dalam diskusi, diasumsikan bahwa setiap pengguna memiliki Kunci Rahasia yang tetap, tanpa perubahan.

Smart Contract tidak menggunakan layanan ketersediaan data off-chain (DAS) atau data blob: dengan kata lain, diasumsikan bahwa Smart Contract sepenuhnya bergantung pada data on-chain, tanpa melibatkan layanan data di luar rantai atau penyimpanan data tambahan.

Direktori Kunci Publik

Siapa pun dapat menambahkan entri (id, pk) yang belum digunakan ke dalam direktori on-chain dengan memanggil Smart Contract.

PKI Desentralisasi merujuk kepada memelihara direktori identitas (ID) dan Kunci Publik yang sesuai melalui Smart Contract. Direktori ini bersifat publik dan tidak tergantung pada pihak ketiga yang tercentralisasi. Sebagai contoh, ENS memelihara pemetaan antara nama domain (yaitu identitas) dan Metadata terkait, termasuk pemecahan Alamat domain tersebut (dapat disimpulkan dari transaksi-transaksi dengan Alamat tersebut untuk mendapatkan Kunci Publik). ENS merupakan sistem yang lebih kompleks, yang tidak hanya mencatat Kunci Publik tetapi juga menyimpan Metadata lainnya. Fungsi PKI Desentralisasi relatif lebih sederhana: Smart Contract hanya perlu memelihara daftar untuk mencatat setiap identitas beserta Kunci Publik yang sesuai.

Ketika pengguna ingin mendaftar identitas, pertama-tama mereka perlu membuat sepasang Kunci Rahasia (Kunci Publik dan Kunci Pribadi), atau menggunakan pasangan Kunci Rahasia yang sudah dibuat sebelumnya, untuk mengirimkan ID identitas mereka dan Kunci Publik ke Smart Contract (mungkin juga membayar biaya tertentu). Smart Contract akan memeriksa apakah ID tersebut sudah terdaftar oleh orang lain. Jika belum terdaftar, Smart Contract akan menambahkan ID dan Kunci Publik tersebut ke dalam direktori. Setelah pendaftaran selesai, siapa saja dapat mengakses Smart Contract untuk mendapatkan Kunci Publik yang sesuai dengan ID tertentu, sehingga dapat melakukan enkripsi pesan untuk pengguna tersebut. Jika pengirim telah melakukan enkripsi pesan sebelumnya ke pengguna ini dan sudah memiliki Kunci Publik pengguna, maka tidak perlu lagi meminta Kunci Publik dari Smart Contract. Setelah mendapatkan Kunci Publik, pengirim dapat menggunakan Kunci tersebut untuk melakukan enkripsi pesan seperti biasa, kemudian mengirimkan pesan yang telah dienkripsi ke penerima. Penerima menggunakan Kunci Pribadi yang sesuai untuk mendekripsi pesan dan mengembalikannya ke bentuk aslinya.

Mari kita lihat kelebihan dan kekurangan metode ini:

Kelebihan dan kekurangan dekripsi non-interaktif: Proses dekripsi tidak memerlukan interaksi dengan pihak lain, dekripsi dapat diselesaikan secara independen. Tidak ringkas: Sistem mungkin kurang ringkas dalam beberapa aspek, yang mungkin berarti kompleksitas yang tinggi, jumlah data yang besar, atau memerlukan sumber daya lebih banyak. Transparansi: Sistem mungkin transparan dalam beberapa aspek, yang berarti operasinya dapat dipublikasikan dan diperiksa. Enkripsi interaktif: Proses enkripsi mungkin memerlukan interaksi dengan pihak lain, yang meningkatkan kompleksitas. ID yang bebas: Pengguna dapat bebas memilih atau menggunakan ID identitas apa pun tanpa batasan format atau aturan tertentu. Pengirim tidak anonim: Identitas pengirim mungkin tidak sepenuhnya anonim dalam sistem.

Berbasis Identitas (IBE)

Identitas pengguna diwakili oleh Kunci Publik mereka, yang berarti Kunci Publik tidak hanya digunakan untuk enkripsi tetapi juga dapat berfungsi sebagai pengenal unik pengguna. Namun metode ini memerlukan ketergantungan pada satu atau lebih pihak ketiga yang dapat dipercaya, yang bertanggung jawab untuk menghasilkan dan mengeluarkan Kunci Rahasia. Selain itu, pihak-pihak ketiga ini juga perlu menjaga sebuah Kunci Rahasia utama selama siklus hidup sistem, yang dalam beberapa kasus dapat digunakan untuk dekripsi atau operasi penting lainnya.

Dalam sistem IBE, pengguna tidak seperti dalam sistem enkripsi tradisional yang menghasilkan pasangan Kunci Publik dan Kunci Pribadi mereka sendiri. Sebaliknya, pengguna perlu mendaftar menggunakan pembuat Kunci Rahasia yang terpercaya. Pembuat Kunci Rahasia memiliki pasangan utama Kunci Rahasia (termasuk Kunci Pribadi utama msk dan Kunci Publik utama mpk). Ketika pengguna menyediakan ID mereka sendiri, pembuat Kunci Rahasia akan menggunakan Kunci Pribadi utama msk dan ID pengguna untuk menghitung Kunci Pribadi yang khusus untuk pengguna tersebut. Kunci Pribadi yang dihasilkan perlu disampaikan kepada pengguna melalui saluran yang aman, biasanya menggunakan protokol pertukaran Kunci Rahasia untuk membangun saluran aman ini.

Bagi pengirim, sistem IBE menyederhanakan proses enkripsi. Pengirim hanya perlu mendownload Kunci Publik Utama (mpk) dari generator Kunci Rahasia sekali, setelah itu dapat menggunakan ID untuk mengenkripsi pesan. Bagi penerima, dekripsi juga mudah. Pengguna terdaftar dapat menggunakan Kunci Pribadi yang dikirimkan oleh generator Kunci Rahasia untuk mendekripsi Ciphertext yang diterima.

Kunci Pribadi utama dari generator kunci (msk) harus tetap ada dalam jangka waktu yang lama karena ia terus-menerus menghasilkan Kunci Pribadi pengguna baru selama sistem berjalan. Hal ini berbeda dengan beberapa sistem SNARK yang menghasilkan kunci tersebut selama proses pengaturan yang dipercayai, tetapi dapat dihapus setelah pengaturan selesai. Namun, dalam sistem IBE, Kunci Pribadi utama tidak dapat dihapus setelah inisialisasi seperti dalam SNARK.

Meskipun Kunci Pribadi utama (msk) disimpan dengan baik, setiap pengguna terdaftar masih perlu mempercayai bahwa pembuat kunci tidak akan membaca pesan mereka. Hal ini karena pembuat kunci dapat sewaktu-waktu menyimpan salinan Kunci Pribadi pengguna, atau menggunakan Kunci Pribadi utama untuk menghitung ulang Kunci Pribadi pengguna.

Generator Kunci Rahasia juga dapat memberikan pengguna Kunci Pribadi yang bermasalah atau terbatas, Kunci Pribadi ini dapat mendekripsi sebagian besar pesan, tetapi tidak dapat mendekripsi pesan tertentu yang ditentukan oleh Generator Kunci Rahasia. Ini berarti Generator Kunci Rahasia memiliki kemampuan untuk mengendalikan kemampuan dekripsi pengguna, sehingga dapat mengendalikan atau membatasi komunikasi pengguna.

Kelebihan Kekurangan penyimpanan on-chain tetap / minimal: Sistem membutuhkan jumlah penyimpanan yang kecil atau tetap di Blok-on-chain, tidak akan bertambah seiring waktu. Asumsi kepercayaan yang kuat: Sistem bergantung pada satu atau beberapa pihak ketiga yang dipercaya, yang berarti harus ada kepercayaan yang kuat terhadap pihak-pihak tersebut. Jika pihak ketiga ini terganggu atau tidak dapat diandalkan, keamanan sistem akan terancam. Enkripsi non-interaktif: Proses enkripsi tidak memerlukan interaksi dengan pihak lain, pengirim dapat melakukan enkripsi secara independen. Pengirim anonim: Sistem dapat menjaga anonimitas pengirim, melindungi privasi. ID yang sembarang: Pengguna dapat memilih atau menggunakan ID identitas sembarang, tidak terbatas oleh format atau aturan tertentu.

Berbasis pendaftaran enkripsi (RBE)

Seperti IBE, dalam sistem ini, identitas pengguna (misalnya Alamat email atau nomor telepon) berfungsi langsung sebagai Kunci Publik mereka. Namun, berbeda dengan IBE, sistem ini tidak lagi bergantung pada pihak ketiga terpercaya atau sekelompok quorum untuk mengelola Kunci Rahasia. Sebaliknya, pihak ketiga terpercaya ini digantikan oleh seorang pengelola kunci (key curator).

Saya akan membahas salah satu cara konstruksi RBE yang efisien di bagian ini, karena menurut pengetahuan saya ini memiliki keunggulan yang signifikan dibandingkan dengan konstruksi RBE praktis lainnya, yaitu dapat dideploy pada Blokon-chain karena berbasis pasangan, bukan berbasis kisi.

Dalam sistem RBE, setiap pengguna menghasilkan sepasang Kunci Rahasia mereka sendiri (termasuk Kunci Publik dan Kunci Pribadi). Pengguna juga perlu menghitung beberapa nilai pembaruan (ditandai sebagai a dalam gambar) berdasarkan Kunci Pribadi mereka dan sebuah String Referensi Publik (CRS). Nilai-nilai pembaruan ini digunakan untuk operasi lebih lanjut dalam sistem. Keberadaan String Referensi Publik (CRS) berarti pengaturan sistem tidak sepenuhnya tanpa kepercayaan. Namun, proses pembuatan CRS menggunakan metode konstruksi daya yang disebut tau. Metode konstruksi ini dapat diselesaikan melalui kerjasama beberapa peserta on-chain. Selama setidaknya satu peserta jujur, CRS ini aman.

Smart Contract telah mengatur pengguna N yang diharapkan menjadi beberapa buckets, ketika pengguna mendaftar di sistem, mereka perlu mengirimkan ID identitas, Kunci Publik, dan nilai pembaruan mereka ke Smart Contract. Smart Contract akan memelihara seperangkat parameter publik pp, yang berbeda dari string referensi publik (CRS) yang telah disebutkan sebelumnya. pp dapat dipahami sebagai ringkasan singkat dari Kunci Publik semua pengguna yang terdaftar di sistem. Setelah menerima permintaan pendaftaran pengguna, Smart Contract akan memeriksa nilai pembaruan untuk memvalidasi kebenaran. Setelah berhasil divalidasi, Smart Contract akan mengalikan Kunci Publik pengguna ke dalam bucket pp yang sesuai. Langkah ini setara dengan memasukkan Kunci Publik pengguna baru ke dalam kumpulan parameter publik sistem untuk penggunaan operasi selanjutnya.

Dalam sistem enkripsi berbasis registrasi (RBE), pengguna perlu menyimpan beberapa informasi secara lokal yang digunakan untuk membantu mereka mendekripsi pesan. Ketika pengguna baru mendaftar ke dalam grup yang sama dengan mereka, informasi-informasi ini perlu diperbarui. Pengguna dapat memantau Blok rantai secara manual untuk memperbarui informasi-informasi ini, atau Smart Contract dapat menyediakan informasi pengguna yang baru terdaftar, yang dapat pengguna peroleh secara berkala untuk menjaga agar informasi dekripsi mereka tetap terkini.

Dalam sistem ini, pengirim hanya perlu melakukan dua hal:

Download Common Reference String (CRS): This only needs to be downloaded once and does not need to be updated afterwards.

Unduh parameter publik: Pengirim perlu sesekali mengunduh parameter publik terbaru. Bagi pengirim, penting bahwa parameter publik ini mencakup Kunci Publik penerima, dan tidak perlu mengunduh versi terbaru setiap kali, asalkan bisa menemukan Kunci Publik penerima.

Kemudian, pengirim menggunakan CRS yang diunduh, parameter publik, dan ID entitas penerima, untuk melakukan enkripsi pesan dan mengirimkannya ke penerima. Ini berarti pengirim tidak perlu sering memperbarui data, asalkan parameter publik memiliki Kunci Publik penerima.

Ketika pengguna menerima pesan enkripsi, mereka pertama-tama akan memeriksa informasi bantu yang disimpan secara lokal untuk melihat apakah ada nilai yang memenuhi syarat tertentu (misalnya, nilai yang telah lulus pemeriksaan validasi). Jika pengguna tidak menemukan nilai yang memenuhi syarat secara lokal, ini berarti bahwa mereka perlu mendapatkan informasi pembaruan terbaru dari Smart Contract. Begitu pengguna menemukan nilai informasi bantu yang sesuai, mereka dapat menggunakan nilai ini dan Kunci Pribadi mereka sendiri untuk mendekripsi Ciphertext yang diterima, sehingga mengembalikan pesan asli.

Jelas, skema ini lebih kompleks dibandingkan dua skema lainnya. Namun, penyimpanan on-chain yang dibutuhkannya lebih sedikit daripada direktori Kunci Publik, dan juga menghindari asumsi kepercayaan yang kuat dari IBE.

Parameter yang ringkas:

  • Hubungan antara ukuran parameter yang disimpan di on-chain dengan jumlah pengguna adalah sublinier, ini jauh lebih kecil dari kunci publik yang diperlukan oleh direktori (naik linier), tetapi tetap bukan konstan, jadi dalam hal ini tidak sebaik sistem IBE (enkripsi berbasis identitas).

enkripsi yang memiliki interaksi tertentu:

  • Saat mengirim pesan, pengirim memerlukan salinan parameter publik yang mencakup penerima tujuan. Ini berarti pengirim perlu memperbarui parameter ini pada suatu titik waktu setelah pendaftaran penerima, tetapi tidak perlu memperbarui secara individual untuk setiap penerima, karena satu pembaruan mungkin mencakup banyak Kunci Rahasia penerima. Secara keseluruhan, interaktivitas pengiriman pesan lebih banyak daripada IBE, tetapi lebih sedikit daripada menggunakan direktori Kunci Publik.

Dekripsi dengan interaksi tertentu:

  • Sama seperti enkripsi, penerima memerlukan informasi bantuan yang sesuai dengan versi parameter publik yang digunakan saat enkripsi. Ketika pengguna baru mendaftar di suatu grup, parameter publik dan informasi bantuan akan diperbarui, dan nilai yang dapat didekripsi dari Ciphertext sesuai dengan versi parameter publik yang digunakan saat enkripsi. Pengguna dapat memilih untuk secara berkala memperbarui informasi bantuan daripada selalu memperbarui setiap kali, kecuali ketika dekripsi gagal. Berbeda dengan pembaruan parameter publik, memperbarui informasi bantuan lebih sering tidak akan mengungkapkan informasi pribadi.

Pengirim anonim:

  • Seperti halnya dengan direktori Kunci Publik, pengirim dapat mengenkripsi pesan secara mandiri (asalkan memiliki parameter terbaru) tanpa perlu mengkonsultasikan informasi tertentu yang terkait dengan penerima. Ketika pengirim perlu membaca informasi dari on-chain, informasi tersebut tidak terkait dengan penerima tujuan (kecuali jika pengirim hanya meminta skor parameter tertentu, tetapi ini mungkin akan mengungkapkan sebagian informasi).

Transparansi:

  • Meskipun sistem memerlukan pengaturan kepercayaan (mungkin didistribusikan atau dikelola eksternal) dan mengeluarkan String Referensi Publik yang disesuaikan (CRS), setelah pengaturan selesai, sistem ini tidak lagi bergantung pada pihak ketiga yang dipercayai atau kelompok arbitrase. Meskipun sistem ini bergantung pada pihak ketiga yang terkoordinasi (Smart Contract), sistem ini sepenuhnya transparan, di mana siapa pun dapat bertindak sebagai koordinator atau memeriksa apakah itu beroperasi dengan jujur melalui verifikasi transisi status (ini juga mengapa itu dapat diimplementasikan sebagai Smart Contract). Selain itu, pengguna dapat meminta bukti keanggotaan (non-) ringkas untuk memeriksa apakah mereka sendiri atau orang lain terdaftar dalam sistem. Ini berbeda dengan sistem IBE, di mana sulit bagi pihak ketiga yang dipercayai untuk membuktikan bahwa mereka tidak secara rahasia mengungkapkan Kunci Rahasia dekripsi (misalnya menyimpan salinan rahasia atau mengungkapkannya kepada orang lain). Sebaliknya, direktori Kunci Publik sepenuhnya transparan.

Kumpulan ID yang Terbatas:

  • Ini adalah versi dasar yang menggambarkan konstruksi RBE. Untuk secara transparan menentukan kelompok mana ID tersebut milik, ID harus memiliki urutan yang umum dan pasti. Nomor telepon dapat diurutkan dengan mudah, tetapi mengurutkan string apa pun mungkin sangat kompleks atau bahkan tidak mungkin, karena jumlah kelompok dapat sangat besar atau tak terbatas. Ini dapat ditangani dengan menyediakan kontrak terpisah untuk menghitung pemetaan ini, atau dengan menggunakan metode cuckoo-hashing yang diusulkan dalam pekerjaan selanjutnya untuk mengatasi kompleksitas ini.

Penerima Anonim:

  • Metode ini dapat mencegah Ciphertext dari bocor dan mengungkapkan identitas penerima.
Lihat Asli
Penafian: Informasi di halaman ini dapat berasal dari pihak ketiga dan tidak mewakili pandangan atau opini Gate. Konten yang ditampilkan hanya untuk tujuan referensi dan bukan merupakan nasihat keuangan, investasi, atau hukum. Gate tidak menjamin keakuratan maupun kelengkapan informasi dan tidak bertanggung jawab atas kerugian apa pun yang timbul akibat penggunaan informasi ini. Investasi aset virtual memiliki risiko tinggi dan rentan terhadap volatilitas harga yang signifikan. Anda dapat kehilangan seluruh modal yang diinvestasikan. Harap pahami sepenuhnya risiko yang terkait dan buat keputusan secara bijak berdasarkan kondisi keuangan serta toleransi risiko Anda sendiri. Untuk detail lebih lanjut, silakan merujuk ke Penafian.
Komentar
0/400
Tidak ada komentar