Latar belakang kriptografi DKLS23

Multi-party Compute menandatangani dengan dua algoritma kunci: ECDSA di secp256k1 dan EdDSA di Ed25519 (segera hadir). Halaman ini membahas protokol ECDSA nilai minimum, DKLS23, dan perubahan yang dilakukan Google pada protokol tersebut. Untuk algoritma yang didukung, lihat Blockchain yang didukung.

Threshold ECDSA dan DKLS23

Berbeda dengan skema tanda tangan lainnya, masalah penandatanganan nilai minimum untuk ECDSA terkenal sulit. Hingga tahun 2017, sebagian besar solusi melibatkan konsekuensi yang signifikan.

Pada tahun 2018, DKLS menghadirkan solusi pertama untuk penandatanganan 2-dari-2 untuk ECDSA yang hanya mengandalkan asumsi kriptografis berbasis ECDSA (misalnya, tidak memerlukan Paillier, RSA, atau kelompok asumsi kekerasan kriptografis lainnya). Ide terobosan dalam protokol ini adalah cara baru untuk memperdebatkan keamanan berbahaya untuk pendekatan berbasis MPC (upaya sebelumnya untuk menerapkan teknik MPC generik yang aman dari serangan berbahaya menghasilkan protokol yang memerlukan waktu eksekusi dalam hitungan menit, bukan milidetik).

Peningkatan berikutnya oleh penulis yang sama menghasilkan protokol k-out-of-n, dan akhirnya peningkatan DKLS23 menghasilkan framework generik untuk ECDSA nilai minimum k-out-of-n 3 putaran yang mencakup semua pendekatan sebelumnya, dan mengidentifikasi pendekatan DKLS sebagai yang paling efisien di sepanjang metrik performa yang penting. Secara khusus, versi protokol tersebut hanya mengandalkan komitmen ideal dan primitif perkalian dua pihak. Protokol yang dihasilkan memerlukan komputasi milidetik satu digit per pihak (menghasilkan peningkatan kecepatan yang signifikan dibandingkan pendekatan pesaing), dan yang penting, protokol ini mengandalkan primitif kriptografi yang lebih sederhana yang hanya menggunakan operasi kurva elips (berbeda dengan Paillier yang mahal, operasi homomorfik, dan bukti rentang zero-knowledge yang mahal serta bukti pembentukan kunci kriptografi yang diperlukan dalam pekerjaan lain).

Protokol ini telah dievaluasi secara internal oleh beberapa auditor, termasuk pakar yang disewa oleh Coinbase dan pakar kriptografi lainnya. Doerner dan Roy DR26 baru-baru ini mengidentifikasi satu kesalahan perhitungan dalam analisis keamanan untuk pengganda DKLS yang memerlukan 22 pemanggilan OT tambahan untuk mencapai keamanan 120 bit yang diklaim. Perubahan ini telah diterapkan. Demikian pula, auditor eksternal lainnya telah menunjukkan detail yang hilang dalam penulisan protokol sehubungan dengan implikasi siaran dalam model saluran point-to-point (terutama, penting untuk menggemakan beberapa parameter konfigurasi untuk mencapai pengetahuan umum).

Pekerjaan selanjutnya di Google pada protokol ini telah secara substansial memperkuat implementasi, mengurangi resource yang diperlukan untuk mengoperasikan protokol dalam skala besar, dan memperluas fungsionalitas skema. Misalnya, literatur akademis kurang menentukan pemilihan dan penerapan Random oracle. Meskipun merupakan abstraksi akademis yang berguna, penerapan Random Oracle adalah tugas yang rumit dan telah menyebabkan beberapa kelemahan yang didokumentasikan oleh audit keamanan.

Aspek penting dari pekerjaan kami adalah mengembangkan sistem jenis (berdasarkan dua operasi spawn dan fork, serta penggunaan sistem jenis yang ketat untuk mencegah penyalinan, pemindahan, dan aliasing pointer ke oracle) untuk memastikan bahwa setiap sesi dan subsesi menggunakan oracle acak yang berbeda.

Peningkatan penting lainnya berkaitan dengan pemilihan ID sesi dan subsesi. Model UC, dan semua protokol yang terbukti aman dalam model tersebut, mengharuskan lingkungan untuk menyediakan ID sesi baru. Dalam praktiknya, sistem harus memastikan bahwa musuh tidak dapat melanggar asumsi ini, dan hal ini biasanya mengharuskan peserta untuk mempertahankan status tak terbatas untuk tujuan ini. Kami telah menambah protokol DKLS asli dengan putaran tambahan untuk memilih ID ini dengan cara yang hanya memerlukan status ukuran konstan.

Secara keseluruhan, protokol yang diupdate dan diperkuat masih menyelesaikan operasi penandatanganan dalam puluhan milidetik.

Dalam hal fungsionalitas, makalah DKLS23 hanya mempertimbangkan struktur akses nilai minimum k-out-of-n standar. Dalam praktiknya, pelanggan mungkin memerlukan struktur akses yang meniru aturan organisasi. Literatur kriptografi berisi banyak pendekatan untuk merancang struktur akses untuk berbagi rahasia. Di sini, kami telah memperluas protokol DKLS untuk mendukung struktur akses yang lebih umum yang dapat disusun dari gerbang threshold-k-out-of-n. Hal ini memungkinkan kebijakan seperti "2 dari 3 grup berikut: (a) pelanggan, (b) 2 dari 10 petugas kontrol risiko, (c) 2 dari 3 pimpinan departemen keuangan, hukum, dan akuntansi", dll.

Di API v1beta, Anda menentukan struktur akses ini sebagai kebijakan kunci KeyRing, di kolom keyPolicy. Setiap kunci yang dibuat di KeyRing akan menggunakannya. Kebijakan kunci dapat memiliki maksimal dua level: aturan nilai minimum root, dan aturan nilai minimum tepat di bawahnya. Aturan nilai minimum di root tidak boleh berisi aturan nilai minimum lainnya.