mthiim/dilithium-java - Implementasi algoritme kriptografi tahan komputasi kuantum menggunakan Java

• Implementasi Dilithium 3.1 dalam Java, dengan operasi primitif dibungkus sebagai JCE provider, sehingga pembuatan kunci, penandatanganan, dan verifikasi dapat digunakan melalui antarmuka kriptografi Java yang terstandarisasi
• Berangkat dari fakta bahwa RSA dan ECC rentan terhadap serangan komputer kuantum yang menggunakan algoritme Shor, ini adalah implementasi untuk bereksperimen dan belajar tentang Dilithium, salah satu skema tanda tangan digital pasca-kuantum yang dipilih oleh NIST
• Termasuk dalam keluarga algoritme CRYSTALS dan berbasis kisi aljabar, Dilithium diimplementasikan berdasarkan implementasi referensi C dan dokumentasinya, sementara SHAKE128/256 yang digunakan secara internal disediakan melalui dependensi Bouncy Castle
• Mendukung seluruh tingkat keamanan terdokumentasi 2·3·5, dan ketiga tingkat tersebut semuanya menggunakan deterministic signature scheme serta lolos uji KAT dari paket resmi
• Alur penggunaan JCE adalah dengan mendaftarkan DilithiumProvider, lalu menggunakan KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium"), dan KeyFactory.getInstance("Dilithium") untuk melakukan pembuatan kunci, penandatanganan, verifikasi, dan pemulihan kunci
  • Tingkat keamanan ditentukan dengan DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5, atau getSpecForSecurityLevel()
  • Kunci publik dan privat memperoleh representasi byte melalui .getEncoded(), lalu diserialisasi dan dideserialisasi dalam format yang kompatibel dengan implementasi referensi
  • Representasi byte tidak mengenkodekan parameter spec, sehingga saat memulihkan kunci harus menyebutkan parameter spec pada DilithiumPublicKeySpec atau DilithiumPrivateKeySpec
• Menyediakan utilitas KAT.java yang membaca file permintaan known-answer test dari paket resmi Dilithium dan menghasilkan file respons, dengan argumen eksekusi dalam format <input-request-file> <output-response-file> <level>
• Implementasi saat ini merefleksikan Dilithium 3.1, dan berbeda dari FIPS 204 atau versi ML-DSA yang masih dalam proses standardisasi
• Ditulis “for fun” selama beberapa hari, bukan production-grade code, belum ditinjau kerentanannya oleh pihak ketiga, serta tidak memberikan jaminan maupun dukungan apa pun
• Tersedia di bawah lisensi Apache 2.0

[GN⁺]

Komentar Hacker News

• Senang melihat proyek saya mendapat perhatian di Hacker News. Ini adalah implementasi mainan murni yang terinspirasi dari makalah dan implementasi referensi.
  Semua test case yang disediakan lulus, tetapi ini terutama dibuat untuk bersenang-senang dan untuk melihat apakah bisa bekerja secara alami dengan antarmuka JCE standar. Jika ada pertanyaan atau masukan, silakan tanya

  • Saya penasaran apa yang diperlukan agar bisa dipakai di layanan nyata. Saya juga ingin tahu apakah ada library Java untuk kriptografi tahan kuantum yang sudah cukup siap untuk lingkungan produksi

• Bagian inti dari implementasi mainan Dilithium ini sebagian besar bisa dilihat di sini: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • Spesifikasi Dilithium juga ada di sini: https://pq-crystals.org/dilithium/data/dilithium-specificati...

• Saya penasaran apakah sebaiknya algoritma kriptografi tahan kuantum dipakai di atas algoritma yang lebih mapan dan luas digunakan seperti RSA/ECDSA.
  Kriptografi tahan kuantum masih terlalu mutakhir sehingga belum nyaman digunakan

  • Tampaknya itulah yang memang sedang dilakukan komunitas.
    Cloudflare baru-baru ini mengaktifkan kriptografi tahan kuantum dan menggunakan X25519+Kyber [0]. Kriptografi tahan kuantum milik Signal juga memakai pendekatan yang sama [1].
    Sepertinya tren ini muncul dari kejadian beberapa tahun lalu ketika suatu algoritma tahan kuantum berhasil dipecahkan di komputer klasik [2].
    Sekarang penyerang harus memecahkan algoritma klasik dan algoritma tahan kuantum sekaligus.
    [0] https://blog.cloudflare.com/post-quantum-to-origins/
    [1] https://signal.org/blog/pqxdh/
    [2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
  • Sejauh yang saya tahu, algoritma Shor masih belum realistis. Untuk menjalankannya dalam waktu yang masuk akal, dibutuhkan jauh lebih banyak qubit daripada yang saat ini memungkinkan.
    Kemungkinan perlu jutaan qubit, sementara perangkat tercanggih saat ini paling-paling masih di kisaran ratusan. Selama beberapa tahun ke depan, mungkin bahkan beberapa dekade, saya rasa kita belum perlu terlalu mengkhawatirkan algoritma tahan kuantum di kode produksi
  • Standar yang saat ini umumnya diterima, meski tidak disepakati semua orang, adalah enkripsi hibrida. Ini berbeda dari “hibrida” dalam KEM/DEM, tetapi biasanya akan dipakai bersama kriptosistem KEM/DEM hibrida.
    Pendekatan ini memastikan bahwa untuk mengakses plaintext, algoritma klasik dan algoritma tahan kuantum keduanya harus dipecahkan. Apakah enkripsinya cukup sekadar dibungkus, atau menggunakan hybrid KEM combiner seperti contoh Campagna dan Petcher, adalah persoalan yang lebih halus dan membutuhkan penilaian yang lebih cermat daripada level saya
  • Jika komputer kuantum menjadi lebih praktis selama masa hidup kita, rahasia saat ini tidak boleh terekspos pada analisis semacam itu di masa depan. Menskalakan komputer kuantum tidak sesederhana evolusi dari tabung vakum dan transistor menjadi integrated circuit, tetapi perkiraan tingkat kesulitan dari para ahli berkisar dari “sangat-sangat-sangat sulit” hingga “akan tetap mustahil secara fisik”.
    Apa pun pilihannya, itu lebih mungkin daripada memecahkan kunci enkripsi standar modern dengan brute force, jadi ada alasan untuk memprioritaskan keamanan pascakuantum hari ini.
    Namun benar juga bahwa kita harus berhati-hati. Jika algoritma PQ memiliki side-channel atau kerentanan implementasi, hasilnya bisa jauh lebih buruk. Bayangkan skenario terburuk: implementasi PQ memiliki kerentanan remote code execution. Karena itu, sebaiknya didekati dengan hati-hati dan kodenya ditinjau secara ketat
  • Tidak ada risiko praktis dalam memakai kriptografi tahan kuantum bersama kriptografi lama, asalkan kombinasi keseluruhannya tidak runtuh ketika salah satunya berhasil dipecahkan.
    Untuk key exchange, ini relatif mudah; tergantung metodenya, cukup XOR atau gabungkan output-nya

• README menyebut dependensi Bouncy Castle, dan BC sudah menyertakan beberapa skema tanda tangan PQC berbasis Java. Lihat https://doc.primekey.com/bouncycastle/interoperability#Inter... dan https://github.com/bcgit/bc-java

• Beberapa hari lalu Daniel Bernstein memperingatkan bahwa NSA mencoba menyebarkan implementasi kriptografi pascakuantum yang cacat. Saya tidak bisa menemukan tautannya

  • Tulisan yang dimaksud ada di sini. Namun yang dibahas adalah Kyber, bukan Dilithium.
    https://news.ycombinator.com/item?id=37756656

• Saya sudah menulis/mem-port implementasi Java satu file untuk sphincs+, skema tanda tangan pascakuantum lainnya, di sini.
  https://github.com/Peergos/sphincsplus

• “Sudah lama diketahui bahwa algoritma kriptografi RSA dan ECC rentan terhadap serangan komputer kuantum yang menggunakan algoritma Shor.”
  Jika ini benar dan komputer kuantum pada skala seperti itu benar-benar muncul, saya penasaran apa dampaknya terhadap Bitcoin

  • Akan dimigrasikan sebelum menjadi masalah. Bahkan jika benar-benar terjadi, cukup lakukan fork dengan memasukkan enkripsi tahan kuantum pada titik serangan pertama yang diketahui

• “Ini adalah implementasi yang dibuat untuk bersenang-senang dalam beberapa hari. Tidak dimaksudkan sebagai kode kelas produksi. Tidak ada jaminan atau dukungan dalam bentuk apa pun. Namun, ini mungkin berguna untuk mengintip dan bereksperimen dengan algoritma pascakuantum. Gunakan dengan risiko Anda sendiri. Jika Anda tidak menyukai ketentuan ini, Anda tidak boleh menggunakan perangkat lunak ini”