Peningkatan fitur pembangkitan bilangan acak aman di Go 1.22

 (go.dev)
2 poin oleh GN⁺ 2024-05-08 | 1 komentar | Bagikan ke WhatsApp
  • Go 1.22 mengubah sumber bilangan acak bawaan di math/rand dan math/rand/v2 menjadi generator yang kuat secara kriptografis, sehingga sangat mengurangi dampak jika terjadi kesalahan penggunaan di tempat yang seharusnya memakai crypto/rand
  • Generator Go 1 lama adalah linear feedback shift register yang menggunakan status 607 buah uint64, sehingga dengan mengamati 607 output saja, nilai masa lalu dan masa depan bisa dipulihkan
  • PCG-DXSM di math/rand/v2 meningkatkan kualitas statistik bilangan acak dan ukuran status, tetapi tetap tidak menjamin ketaktertebakan yang dibutuhkan untuk nilai rahasia
  • ChaCha8Rand yang baru menggunakan seed 32 byte, melakukan re-keying setiap 16 blok, dan memakai status 300 byte per core, serta diterapkan pada math/rand/v2, sebagian math/rand, dan seed hash map
  • Biaya performanya terbatas: ChaCha8Rand memang lebih lambat daripada generator Go 1, tetapi tidak sampai 2x, dan pada server umum selisihnya tidak melebihi 3ns sehingga keuntungan keamanannya lebih besar bagi sebagian besar program

Default bilangan acak yang diubah Go 1.22

  • Go 1.22 mengubah default di math/rand dan math/rand/v2 agar menggunakan generator pseudorandom yang kuat secara kriptografis
  • Tujuannya adalah mengurangi dampak ketika pengembang tanpa sengaja memakai math/rand di tempat yang seharusnya membutuhkan crypto/rand
  • API bilangan acak di Go secara tradisional dibagi menjadi dua kategori
    • math/rand: bilangan acak statistik untuk simulasi, sampling, analisis numerik, algoritme acak non-kriptografis, fuzzing, shuffle, exponential backoff, dan sebagainya
    • crypto/rand: bilangan acak kriptografis untuk kebutuhan yang memerlukan ketaktertebakan seperti kunci dan token

Mengapa bilangan acak statistik tidak cukup

  • Generator bilangan acak statistik bisa cukup untuk banyak penggunaan non-kriptografis jika lolos uji statistik dasar
  • Namun, pengamat yang mengetahui algoritmenya sering kali dapat memprediksi urutan berikutnya setelah melihat cukup banyak output
  • srand dan rand di Unix V3 adalah bentuk awal yang kemudian memengaruhi API bilangan acak di C dan berbagai bahasa lain
    • Menetapkan status dari seed integer tunggal
    • Menghitung nilai berikutnya dengan metode linear congruential generator (LCG)
    • Karena status internalnya sederhana, hanya dengan satu output pun nilai masa depan bisa dihitung dengan mudah
  • Pada LCG, konstanta dapat dipilih agar semua nilai output yang mungkin muncul satu kali sebelum berulang, tetapi bit-bit rendahnya memiliki kelemahan berupa pengulangan dengan periode pendek

Struktur dan kelemahan generator Go 1

  • Generator math/rand di Go 1 berasal dari keluarga linear feedback shift register
  • Status internalnya adalah slice vec yang berisi 607 buah uint64
    • vec[606] adalah “tap”
    • vec[334] adalah “feed”
    • Untuk membuat nilai berikutnya, tap dan feed dijumlahkan menjadi x, lalu x disimpan di posisi feed dan dikembalikan
  • Implementasi nyatanya tidak menggeser seluruh slice, tetapi hanya memindahkan posisi tap dan feed ke belakang untuk mengurangi biaya
    • Pembuatan nilai berikutnya memerlukan dua pengurangan, dua penjumlahan kondisional, dua load, satu penjumlahan, dan satu store
  • Karena nilai yang dikembalikan adalah salah satu elemen vektor status internal, 607 output sudah cukup untuk membocorkan seluruh status
    • Dengan mengisi vec yang sama dan menjalankan algoritmenya, nilai masa depan bisa diprediksi
    • Dengan menjalankan algoritme secara terbalik, nilai masa lalu juga bisa dipulihkan
  • Generator Go 1 memang bukan untuk tujuan keamanan, dan kualitas angka yang dihasilkannya juga bergantung pada cara vec awal diinisialisasi

Perbaikan yang dibawa PCG dan batasannya yang tersisa

  • math/rand/v2 mengadopsi PCG karya Melissa O’Neill sebagai generator bilangan acak statistik yang lebih modern
  • PCG di Go berbasis LCG 128-bit dan menggunakan fungsi scramble untuk mereduksi status 128-bit menjadi output 64-bit
  • Dalam pembahasan proposal, Go menggunakan scramble berbasis perkalian berdasarkan usulan O’Neill
    • Bentuk ini disebut PCG-DXSM
    • Numpy juga menggunakan bentuk PCG ini
  • Status PCG jauh lebih kecil daripada generator Go 1
    • Generator Go 1: 607 buah uint64
    • PCG: dua buah uint64
  • PCG tidak terlalu sensitif terhadap nilai status awal dan lolos berbagai uji statistik, tetapi tetap tidak menjamin ketaktertebakan
    • PCG-XSL-RR dapat dibalik
    • PCG-DXSM juga tidak akan mengejutkan jika ternyata dapat dibalik
  • Untuk pembuatan nilai rahasia, yang dibutuhkan adalah generator lain, bukan PCG

Bilangan acak kriptografis dan peran sistem operasi

  • Bilangan acak kriptografis harus secara praktis tidak dapat diprediksi, bahkan oleh pengamat yang mengetahui cara pembuatannya dan telah melihat banyak output sebelumnya
  • Protokol kriptografi, kunci rahasia, perdagangan modern, dan privasi online bergantung pada bilangan acak kriptografis
  • Penyediaan bilangan acak sebenarnya ditangani oleh sistem operasi
    • Sistem operasi mengumpulkan keacakan dari perangkat fisik seperti mouse, keyboard, disk, dan timing jaringan
    • Belakangan ini juga dimanfaatkan noise listrik yang diukur langsung oleh CPU
  • Setelah sistem operasi mengumpulkan keacakan yang cukup, misalnya minimal 256 bit, sistem akan membuat urutan bilangan acak panjang menggunakan algoritme hash atau kriptografi
  • Dulu perangkat file seperti /dev/random umum digunakan, tetapi sistem operasi modern kini menyediakan syscall secara langsung
  • crypto/rand di Go menyembunyikan perbedaan antar-OS dan menyediakan antarmuka yang sama lewat rand.Read

Desain ChaCha8Rand

  • Generator baru ChaCha8Rand di Go 1.22 adalah bentuk yang sedikit dimodifikasi dari cipher stream ChaCha karya Daniel J. Bernstein
  • ChaCha juga banyak digunakan dalam bentuk ChaCha20 pada TLS dan SSH
  • Too Much Crypto karya Jean-Philippe Aumasson menilai bentuk 8-round, yaitu ChaCha8, juga aman, dan ChaCha8 kira-kira 2,5 kali lebih cepat
  • ChaCha8Rand memakai ChaCha8 sebagai rand.Source, sehingga blok yang dihasilkan tidak di-XOR dengan input, melainkan langsung digunakan sebagai stream bilangan acak
    • Ini setara dengan mengenkripsi atau mendekripsi data yang seluruhnya bernilai 0

Perubahan pada ChaCha8Rand

  • ChaCha8Rand menggunakan seed 32 byte sebagai kunci ChaCha8
  • ChaCha8 menghasilkan blok 64 byte, dan perhitungannya memperlakukan blok sebagai 16 buah uint32
  • Implementasi umum dapat menghitung 4 blok sekaligus dengan instruksi SIMD, tetapi untuk dipakai sebagai input XOR, blok yang terinterleaving perlu diurai lagi
    • ChaCha8Rand mendefinisikan blok terinterleaving itu sendiri sebagai stream bilangan acak, sehingga menghilangkan biaya unshuffle
  • Pada tahap akhir blok ChaCha8, nilai tertentu ditambahkan ke tiap uint32
    • Setengahnya adalah material kunci dan setengahnya lagi adalah konstanta yang sudah diketahui
    • ChaCha8Rand tidak menambahkan kembali konstanta yang diketahui itu, sehingga menghapus setengah dari penjumlahan akhir
  • Setiap blok hasil ke-16, 32 byte terakhir digunakan sebagai kunci untuk 16 blok berikutnya
    • Re-keying ini memberikan semacam forward security
    • Sekalipun seluruh status memori generator bocor, yang bisa dipulihkan hanya nilai sejak re-keying terakhir, bukan nilai masa lalunya
  • Go memublikasikan spesifikasi C2SP ChaCha8Rand dan test case agar implementasi lain dengan seed yang sama dapat berbagi repeatability yang sama dengan implementasi Go

Lokasi penerapan di standard library

  • Runtime Go mempertahankan status ChaCha8Rand per core yang di-seed dengan bilangan acak kriptografis dari sistem operasi
    • Ukuran status per core adalah 300 byte
    • Pada sistem 16 core, ukurannya setara dengan status tunggal generator Go 1 bersama yang berukuran 4.872 byte
    • Karena statusnya per core, bilangan acak bisa dihasilkan cepat tanpa lock contention
  • Fungsi paket math/rand/v2 selalu menggunakan ChaCha8Rand
    • Contoh: rand.N, rand.Float64
  • Fungsi paket math/rand menggunakan ChaCha8Rand jika rand.Seed belum dipanggil
    • Contoh: rand.Intn, rand.Float64
    • Jika rand.Seed dipanggil, perilakunya harus kembali ke generator Go 1 demi kompatibilitas
  • Runtime memilih seed hash untuk map baru dengan ChaCha8Rand, menggantikan generator berbasis wyrand sebelumnya
    • Jika penyerang mengetahui fungsi hash tertentu pada implementasi map, ia bisa menyiapkan input untuk memaksa map berjalan dalam waktu kuadratik
    • Menggunakan seed per map, bukan satu seed global, juga menghindari bentuk degradasi lain
    • Tidak sepenuhnya jelas apakah seed map benar-benar membutuhkan bilangan acak kriptografis, tetapi pergantian ini sederhana dan merupakan pilihan yang hati-hati
  • Kode yang membutuhkan instance ChaCha8Rand terpisah dapat membuat rand.ChaCha8 secara langsung

Mengurangi dampak kesalahan keamanan

  • Go bertujuan membantu penulisan kode yang aman secara default dengan mengurangi atau menghapus kesalahan umum yang menimbulkan masalah keamanan
  • Ketika Read pada math/rand dinyatakan deprecated di Go 1.20, ditemukan bahwa sebagian pengembang memakai math/rand di tempat yang sebenarnya membutuhkan crypto/rand, seperti pembuatan material kunci
  • Di Go 1.20, kesalahan seperti ini merupakan masalah keamanan yang serius
    • Harus diselidiki untuk apa kunci itu digunakan
    • Bagaimana kunci itu mungkin terekspos
    • Apakah output bilangan acak lain memberi petunjuk bagi penyerang untuk menurunkan kunci
  • Di Go 1.22, kesalahan yang sama tetaplah kesalahan, tetapi kemungkinan berubah menjadi bencana keamanan menjadi lebih kecil
  • Meski begitu, untuk nilai rahasia tetap lebih baik memakai crypto/rand
    • Kernel sistem operasi dapat melindungi nilai acak dengan lebih baik
    • Kernel terus menambahkan entropi baru ke generator
    • Implementasi kernel telah menerima lebih banyak peninjauan

Kasus yang tampak tidak seperti kriptografi

  • Pembuatan UUID acak bisa terlihat cukup memakai math/rand karena UUID bukan nilai rahasia
  • Namun, jika math/rand di-seed dengan waktu saat ini, komputer yang berbeda bisa menghasilkan nilai yang sama ketika berjalan pada saat yang sama
    • Kemungkinan ini lebih besar pada sistem yang hanya menyediakan presisi waktu milidetik
  • Bahkan dengan auto-seeding berbasis entropi OS di Go 1.20, seed generator Go 1 tetap hanya integer 63-bit
    • Program yang membuat UUID saat startup dibatasi pada 2⁶³ kemungkinan UUID pertama
    • Setelah sekitar 2³¹ UUID, peluang tabrakan mulai muncul
  • ChaCha8Rand di Go 1.22 di-seed dengan entropi 256 bit
    • UUID pertama yang mungkin menjadi 2²⁵⁶
    • Tidak perlu khawatir tentang tabrakan
  • Load balancing di mana server frontend secara acak menugaskan permintaan ke server backend juga dapat memerlukan bilangan acak yang tidak dapat diprediksi
    • Jika penyerang dapat mengamati penugasan dan mengetahui algoritme yang bisa diprediksi, ia dapat memusatkan permintaan mahal ke backend tertentu
    • Pada generator Go 1, ini jarang tetapi mungkin terjadi
    • Di Go 1.22, ini bukan masalah

Karakteristik performa

  • Keunggulan keamanan ChaCha8Rand memang memiliki biaya kecil, tetapi performanya tetap berada pada kisaran yang sama dengan generator Go 1 dan PCG
  • Ada dua operasi pembanding
    • Uint64: mengembalikan uint64 berikutnya dari stream bilangan acak
    • N(1000): mengembalikan bilangan acak dalam rentang [0, 1000)
  • Pada chip x86 64-bit yang dibangun dengan GOARCH=386 lalu dijalankan dalam mode 32-bit, PCG lebih lambat daripada ChaCha8Rand karena perkalian 128-bit milik PCG
    • ChaCha8Rand menggunakan aritmetika SIMD 32-bit
  • Pada sebagian sistem, Go 1: Uint64 lebih cepat daripada PCG: Uint64, tetapi Go 1: N(1000) lebih lambat daripada PCG: N(1000)
    • N(1000) pada Go 1 memakai dua pembagian integer 64-bit untuk penyempitan rentang
    • N(1000) pada PCG dan ChaCha8 sebagian besar menggunakan algoritme math/rand/v2 yang lebih cepat dan menghindari pembagian
  • Secara keseluruhan, ChaCha8Rand lebih lambat daripada generator Go 1, tetapi tidak lebih dari 2x lebih lambat
  • Pada server umum, selisihnya tidak melebihi 3ns, dan sangat sedikit program yang menjadikan selisih ini sebagai bottleneck

Kesimpulan

  • Go 1.22 meningkatkan keamanan program tanpa perubahan kode
  • Cara utamanya adalah memperkuat math/rand sendiri untuk mengurangi masalah umum ketika math/rand keliru dipakai sebagai pengganti crypto/rand
  • Ada juga contoh seperti paket npm keypair yang mencoba membuat pasangan kunci RSA dengan JavaScript Math.random saat Web Crypto API tidak tersedia
  • Keamanan sistem tidak bisa bergantung pada asumsi bahwa pengembang tidak akan pernah melakukan kesalahan
  • ChaCha8Rand di Go 1.22 menunjukkan bahwa pendekatan memakai generator pseudorandom yang kuat secara kriptografis bahkan untuk bilangan acak “matematis” pun dapat memberikan performa yang kompetitif dibanding generator lain

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-08
Komentar Hacker News

  • Seperti yang disebutkan di artikel, rclone melakukan kesalahan persis seperti ini.
    Saat me-refactor kode yang menggunakan Read dari crypto/rand, import-nya otomatis berubah, dan mungkin karena bercampur dengan kode yang menggunakan math/rand, goimports mengubahnya menjadi math/rand.
    Akibatnya, yang dipakai bukan generator angka acak aman, melainkan generator deterministik yang di-seed oleh rclone dengan waktu, dan itu tidak terlihat di diff :-(
    https://www.cvedetails.com/cve/CVE-2020-28924/
    Jadi saya sangat mendukung perubahan ini.

    • Aduh, itu menyakitkan; maaf. Karena pada 2016 goimports diubah agar memprioritaskan crypto/rand, saya tidak yakin apa yang terjadi saat refactoring itu.
      Mungkin di file yang sama ada kode yang menggunakan API khusus math/rand.
      https://go-review.googlesource.com/24847
      Bagaimanapun, senang melihat bagian seperti ini dirapikan.
    • Saya juga pernah menerima laporan kerentanan karena seseorang mengira math/rand digunakan. Sebenarnya tidak begitu; mereka hanya tertukar antara beberapa file, jadi bukan masalah besar, tetapi ini menunjukkan betapa membingungkannya keseluruhan hal ini.
      text/template dan html/template juga mirip. Kalau dipikir lagi, penyamaran nama paket seperti ini adalah ide buruk.
    • Saya juga melihat bahwa jika mencari "secure password generation golang", hampir semua contohnya menggunakan math/rand.
      Lebih buruk lagi, semuanya menginisialisasi ulang seed dengan waktu saat ini tepat sebelum membuat kata sandi.
      Saya mengetahuinya setelah menemukan seseorang memakai math/rand di kode kami, lalu mencari tahu dari mana mereka menyalinnya.
    • goimports hampir sejak awal menangani math/rand.Read dan crypto/rand.Read secara khusus.
      Namun, commit tahun 2016 di https://github.com/golang/tools/commit/0835c735343e0d8e375f0... menyebutkan ada masa ketika "rand.Read" bisa ditafsirkan sebagai "math/rand".
      Mungkin kejadian itu terjadi pada periode tersebut.
    • Sepertinya tidak terlalu sulit menyediakan pemanggilan API dengan nama seperti "PredictableRand".

  • Minggu lalu spacey juga memposting ini di https://news.ycombinator.com/item?id=40237491, tetapi tampaknya postingan itu keliru terkubur sebagai duplikat dari https://news.ycombinator.com/item?id=40224864.
    Dua tulisan blog go.dev itu adalah dua bagian dari seri yang sama, tetapi cukup berbeda. Tulisan kali ini membahas algoritma generator angka acak aman yang efisien, sedangkan tulisan sebelumnya membahas desain API Go.

  • Russell Cox secara konsisten menghasilkan blog teknis, proposal, dan karya yang sangat bagus.
    Jika ingin meningkatkan kejernihan menulis dan berpikir, Russell Cox adalah titik awal yang bagus.

    • Berkat seri tulisannya tentang finite state automata dan regex, saya jadi sangat tertarik pada bidang itu.
      Saat itu saya bahkan tidak tahu siapa Russ Cox, tetapi seri tulisannya benar-benar luar biasa.
      Untuk materi gratis tentang implementasi regex, mungkin itu yang kualitasnya paling tinggi; berikutnya adalah beberapa buku yang berfokus pada compiler, tetapi itu tidak gratis dan juga tidak mudah dicari di web.
    • Ia juga membuat demo video yang bagus https://research.swtch.com/acme

  • Saya pernah menggunakan math/rand di tempat yang seharusnya wajib memakai crypto/rand.
    Akibatnya, versi awal dnscrypt-proxy2 menggunakan kunci statis.
    Penyebabnya adalah ekstensi VSCode yang otomatis menambahkan import. Di semua file sumber yang membutuhkan angka acak aman, saya secara hati-hati mengimpor crypto/rand langsung, tetapi di satu file saya terlewat; semuanya tetap terkompilasi dan berjalan dengan baik, dan saya tidak menyadari bahwa ekstensi itu diam-diam menambahkan import math/rand ke file tertentu tersebut.
    Sejak itu, untuk menghindari rand yang salah terimpor otomatis, saya mengimpor crypto/rand dengan alias cryptorand.
    Sebagai catatan, Zig juga menggunakan generator angka acak berbasis ChaCha8, dan untuk operasi kriptografi pengguna tidak dapat menyediakan generator sendiri; generator yang aman selalu digunakan. Untuk pengujian, beberapa fungsi menerima seed eksplisit.
    Untuk lingkungan terbatas, pustaka standarnya juga menyertakan generator yang lebih kecil berdasarkan permutasi Ascon dan konstruksi Reverie.

    • Saya tidak tahu persis apa yang terjadi dalam kasus Anda, tetapi besar kemungkinan tidak seperti yang Anda jelaskan.
      Pada 2016, goimports diubah agar memprioritaskan crypto/rand dibanding math/rand (https://go-review.googlesource.com/24847), dan itu sebelum dukungan VSCode untuk Go muncul.
    • Orang lain juga mengatakan hal yang sama. Jujur saja, praktik menambahkan import secara otomatis terlihat benar-benar aneh, dan meruntuhkan tujuan memisahkan nama ke dalam namespace yang berbeda.

  • Bahkan pada era 2020-an, saya sering bertanya-tanya mengapa implementasi random default di berbagai bahasa pemrograman masih memakai generator bilangan acak cepat seperti LFSR atau MT.
    Tampaknya lebih baik mengambil sikap konservatif dengan menganggap orang tidak tahu apakah mereka membutuhkan generator bilangan acak semu atau generator bilangan acak semu yang aman secara kriptografis, lalu mengubah default ke yang kedua dan membiarkan hanya orang yang membutuhkan yang pertama memilihnya secara eksplisit.

    • API random berorientasi objek baru di PHP 8.2 melakukan persis seperti itu.
      Jika developer tidak secara eksplisit memilih mesin random yang akan digunakan, mereka akan mendapatkan generator yang aman secara kriptografis.
      Bagian yang sulit sekarang adalah meyakinkan orang untuk pindah ke API baru. Lebih jauh lagi, bahkan memindahkan orang dari mt_rand(), yang memakai instance global Mt19937, ke random_int() berbasis CSPRNG yang sudah tersedia sejak PHP 7.0 pun tidak mudah.
      [1] https://www.php.net/releases/8.2/en.php#random_extension
    • Belakangan ini saya mulai memakai sebuah library Go baru yang membuat ID acak untuk beberapa komponen dalam struktur data yang kompleks.
      Dalam use case saya, ada puluhan ribu komponen, dan setelah diprofiling, sebagian besar waktu inisialisasi struktur data ternyata dihabiskan di Read() milik crypto/rand, yang di MacBook saya menjalankan system call.
      Setelah library itu saya patch agar memakai Read() dari math/rand, performanya meningkat besar.
      Selain math/rand memang lebih cepat, saya juga khawatir akan menguras entropy pool sistem tanpa alasan khusus. Dalam kasus ini, satu-satunya alasan ID perlu bersifat acak adalah agar setelah struktur data diserialisasi/deserialisasi, komponen bisa ditambahkan lagi nanti, dan saya tidak berniat melakukan itu.
      Saya tidak tahu persis bagaimana timing perubahan yang dibahas di blog ini berkaitan dengan pengalaman saya. Mungkin saya memakai versi lama library tersebut, dan kalau sekarang crypto/rand pada dasarnya sudah hampir tak bisa dibedakan dari math/rand, ya bagus saja :-)
    • Salah satu argumen yang lebih kuat untuk memakai CSPRNG, dalam hal ini ChaCha8, adalah bahwa dalam benchmark ia berada dalam rentang kurang dari 2x dibanding PCG.
      Ukuran state-nya masih relatif besar (64 byte vs 16 byte), tetapi jauh lebih baik daripada mt19937 atau PRNG lama Go.
      Jika CSPRNG jauh lebih lambat, seperti umumnya terjadi pada CSPRNG biasa yang bukan varian ChaCha dengan round dikurangi, daya tariknya sebagai default akan berkurang.
    • Kapan lagi orang membutuhkan yang pertama? Yang terpikir oleh saya hanya seed tetap ketika butuh hasil yang dapat direproduksi, misalnya untuk pengujian atau verifikasi.
      Ada satu faktor kecil lain yang mendorong orang ke PRNG meski mereka tidak membutuhkan seed. API CSPRNG selalu menyertakan error yang harus ditangani untuk mengantisipasi kegagalan system call atau kekurangan entropi.
      Seberapa sering pembacaan crypto/rand benar-benar gagal? Seberapa banyak harus membaca untuk menguras entropi di sistem modern? Saya belum pernah melihat kegagalan bahkan pada miliaran request, dan dd juga berjalan baik.
      Saya jadi bertanya-tanya apakah API bergaya Must/panic mungkin lebih cocok sebagai default untuk sebagian besar use case.
      Sebagai tambahan, saya melihat paket secrets di Python (https://docs.python.org/3/library/secrets.html), dan tidak ada satu pun penyebutan bahwa ia bisa melempar exception. Apakah dalam praktiknya hal itu memang tidak terjadi?
    • Saya menyukai pendekatan “semua random di sistem harus berasal dari CSPRNG kecuali jika secara eksplisit opt out.”
      Dengan sedikit kehilangan performa, kita mendapat jaminan yang jauh lebih kuat bahwa bencana tidak terjadi karena memakai generator bilangan acak yang salah.
      Sayang sekali di hampir semua bahasa, developer masih harus memperhatikan sudut tajam ini.

  • Sebagai tambahan bagi yang belum tahu, gosec dan perluasannya, golangci-lint, akan memberi peringatan atas penggunaan math/rand.
    https://github.com/securego/gosec/blob/d3b2359ae29fe344f4df5...

    • Salah satu hal yang paling saya sukai dari math/rand/v2 adalah bisa memakainya di perusahaan tanpa directive nolint dan diskusi PR sesudahnya.

  • Saya masih menafsirkan rekomendasi terkait keamanan dan opsi v2 baru ini.
    Postingan blog memakai kalimat seperti “untuk nilai rahasia, Anda butuh yang lain”, lalu membahas secara detail randomness kriptografis, ChaCha8, dan cara ia di-seed dari random sistem, sehingga memberi kesan sangat “aman”.
    Namun dokumentasi paketnya mengatakan begini:
    ... but it should not be used for security-sensitive work ... This package's outputs might be easily predictable regardless of how it's seeded. For random numbers suitable for security-sensitive work, see the crypto/rand package.
    Kalau begitu, mengapa postingan blog memberi kesan seolah math/rand/v2 dipakai untuk “nilai rahasia”?
    Singkatnya, apakah maksudnya semua hal yang sensitif tetap harus memakai crypto/rand, dan peningkatan yang dijelaskan di sini hanyalah jaring pengaman ketika seseorang memakai math/rand/v2 secara tidak semestinya?

    • Benar. math/rand/v2 memang bukan yang optimal, tetapi jika seseorang secara keliru memakainya di tempat yang seharusnya memakai crypto/rand, itu tidak lagi langsung menjadi cacat keamanan yang fatal.
      Di tulisannya juga disebutkan begini:
      Tetap lebih baik memakai crypto/rand. Kernel sistem operasi lebih mampu menjaga nilai random tetap rahasia dari berbagai serangan pengintaian, kernel terus menambahkan entropi baru ke generator, dan ia telah mendapat lebih banyak peninjauan. Namun, memakai math/rand secara tidak sengaja tidak lagi menjadi bencana keamanan.

  • Bahkan pada benchmark terburuk, strategi baru ini hanya sekitar setengah lebih lambat dibanding generator angka acak yang tidak aman, dan sebagian besar benchmark hasilnya jauh lebih dekat
    Go berhasil menyeimbangkan keamanan dan performa dengan baik untuk pustaka standar dan aplikasi yang dibangun di atasnya. Semoga ekosistem lain juga mengikuti
    Jika aplikasi membutuhkan angka acak yang cepat dan tidak aman, generator internal harus diimplementasikan sendiri
    Menaruh angka acak yang tidak aman di tempat yang mudah dijangkau adalah alat untuk mencelakakan diri sendiri yang seharusnya bisa disingkirkan

    • Sejujurnya, ini terlihat lebih buruk
      Mendorong orang untuk berasumsi bahwa primitif "random" aman secara kriptografis berarti mendorong praktik buruk
      Menjadikan math/rand/v2 aman secara kriptografis mungkin menyelesaikan satu masalah, tetapi sekarang sesuatu yang tampaknya tidak menjanjikan keamanan menjadi “baik-baik saja”
      Secara umum, fungsi math/rand tidak memiliki konvensi bahwa ia aman secara kriptografis. Jika itu diubah sehingga kode buruk kebetulan berjalan dengan benar, hal itu bisa menutupi kesalahan lain apa yang mungkin kita buat jika kita melakukan kesalahan yang begitu jelas seperti ini

  • math/rand di Go 1 lebih tepat disebut additive lagged Fibonacci generator
    Publikasi pertamanya adalah makalah oleh Green, Smith, dan Klem
    [1] https://doi.org/10.1145/320998.321006

    • Sepertinya makalah itu tidak menyebut bagian “lagged”. Atau mungkin saya yang melewatkannya
      Saya juga tahu https://www.leviathansecurity.com/blog/attacking-gos-lagged-..., dan di sana juga disebut lagged Fibonacci generator
      Rob Pike dan saya beberapa bulan lalu berkorespondensi lewat email dengan Don Mitchell, yang menulis versi C asli dari generator Go 1, untuk menanyakan bagaimana ia menjelaskan algoritme ini, dan ia menjawab, “seingat saya, Jim dan saya mengimplementasikan generator mirip LFSR milik Marsaglia”
      Saya rasa kedua deskripsi itu—lagged Fibonacci dan generator mirip LFSR—sama-sama benar dari sudut pandang yang berbeda. Keduanya boleh saja, tetapi di tulisan ini saya memilih memakai penjelasan dari penulis aslinya

  • Kalau harus menyebut satu kekurangan kecil, di sini tampaknya keacakan statistik dan generator angka acak semu tercampur penggunaannya
    Definisi keacakan statistik di wiki adalah “sebuah deret angka dikatakan acak secara statistik ketika tidak memiliki pola atau keteraturan yang dapat dikenali”
    Apakah definisi ini juga berlaku untuk true random number generator (TRNG)? Kita semestinya berharap demikian. Setidaknya dalam jangka panjang atau pada batasnya harus begitu. Jika tidak, itu bukan TRNG
    TRNG harus menghasilkan “deret angka tanpa pola atau keteraturan yang dapat dikenali” dalam jangka panjang
    Jadi, keacakan statistik tidak berarti PRNG, tetapi dapat dikatakan bahwa itu juga berlaku untuk TRNG
    Masalahnya tampaknya muncul karena ada banyak uji keacakan statistik untuk memverifikasi apakah PRNG memiliki bentuk keacakan statistik yang terbatas
    Jadi untuk mengidentifikasi PRNG, istilah “generator angka acak semu” mungkin lebih tepat daripada “keacakan statistik”. Meski begitu, ini hanya kekurangan yang sangat kecil