OneTimeSecret vs PrivateNote: mengapa lokasi enkripsi penting

Dua cara membangun tautan yang sama

Pada enkripsi sisi server, pengirim menyerahkan rahasia ke layanan melalui TLS. Layanan menerima teks biasa, mengenkripsinya, dan menyimpan teks sandi. Layanan kemudian dapat menyimpan muatan, mengantarkannya, mengakhiri masa berlakunya, dan menghapusnya. Server aplikasi menjadi bagian dari proses enkripsi karena teks biasa masuk ke layanan sebelum menjadi teks sandi.

Pada enkripsi sisi klien, perangkat pengirim mengenkripsi terlebih dahulu. Layanan menerima dan menyimpan teks sandi. Unggahan itu berjalan melalui TLS. Layanan tidak menerima kunci yang diperlukan untuk mendekripsi muatan standar. Perangkat penerima mendekripsi secara lokal. Layanan tetap dapat menyimpan, mengantar, mengakhiri masa berlaku, dan menghapus muatan tanpa memerlukan akses ke teks biasanya.

Kedua desain dapat menyediakan tautan sementara, akses terbatas, dan kedaluwarsa. Keduanya dapat secara akurat disebut terenkripsi. OneTimeSecret memakai arsitektur pertama; PrivateNote memakai yang kedua. Pertanyaan yang relevan karenanya bukan sekadar apakah tautan sekali pakai terenkripsi, tetapi sistem mana yang harus memiliki akses ke teks biasa agar tautan itu berfungsi.

OneTimeSecret: enkripsi sisi server

Pada alur OneTimeSecret yang biasa, pengirim menyerahkan rahasia melalui TLS. Aplikasi menerima teks biasa, mengenkripsinya di server, dan menyimpan muatan terenkripsi.

Ini memberi perlindungan yang berarti untuk data yang tersimpan. Memperoleh penyimpanan terenkripsi saja tidak serta-merta mengungkap isinya jika materi yang diperlukan untuk dekripsi tidak tersedia bagi penyerang.

Kompromi arsitektur terjadi sebelum penyimpanan. TLS melindungi rahasia saat berjalan antara browser dan OneTimeSecret, tetapi aplikasi harus memproses teks biasa agar dapat mengenkripsinya. Server aplikasi karenanya berada di dalam batas kepercayaan kriptografis.

Proses aplikasi yang jahat atau disusupi pada saat itu dapat mengakses rahasia sebelum dienkripsi untuk penyimpanan. Enkripsi sisi klien menghilangkan ketergantungan khusus ini dengan mengenkripsi rahasia sebelum sampai ke layanan.

Frasa sandi OneTimeSecret tidak mengubah batas enkripsi

Dokumentasi OneTimeSecret menjelaskan frasa sandi opsional. Saat frasa sandi dipakai, OneTimeSecret menyatakan rahasia dienkripsi di servernya memakai frasa sandi yang diberikan pengirim. OneTimeSecret menyatakan tidak menyimpan frasa sandi itu sendiri; yang disimpan adalah hash bcrypt yang dipakai untuk memverifikasi frasa sandi saat pengambilan. Menurut dokumentasinya, hash itu sendiri tidak dapat mendekripsi rahasia, dan rahasia tersimpan yang dilindungi frasa sandi tidak dapat didekripsi tanpa frasa sandi asli.

Pengambilan memakai batas sisi server yang sama. Penerima memberikan frasa sandi kepada OneTimeSecret melalui TLS. Layanan memverifikasinya dan melakukan dekripsi di server sebelum mengembalikan teks biasa.

Ini berarti proses aplikasi memiliki akses ke rahasia dan frasa sandi saat enkripsi terjadi, lalu memproses lagi frasa sandi dan teks biasa yang dihasilkan saat pengambilan. Proses aplikasi yang jahat atau disusupi yang beroperasi di salah satu titik itu berpotensi menangkap informasi tersebut. Ini adalah akibat dari tempat enkripsi dan dekripsi dijalankan, bukan klaim bahwa OneTimeSecret mencatat atau menyalahgunakan nilai-nilai itu.

Dokumentasi publik OneTimeSecret tidak dengan sendirinya menetapkan setiap detail hierarki kunci internalnya—misalnya, tepatnya bagaimana materi kunci sisi server, kunci per rahasia, derivasi kunci, dan frasa sandi yang diberikan digabungkan. Tidak perlu berspekulasi tentang detail implementasi itu untuk perbandingan ini. Sifat terdokumentasi yang relevan adalah bahwa enkripsi dan dekripsi berlangsung di sisi layanan.

Hosting sendiri dapat membuat kepercayaan pada server itu masuk akal

OneTimeSecret bersifat sumber terbuka. Organisasi dapat menjalankan instansnya sendiri di dalam perimeter keamanan perusahaan, bukan mengirim rahasia ke layanan publik.

Pada penerapan itu, memercayai server aplikasi berarti memercayai infrastruktur yang sudah dioperasikan organisasi. Teks biasa tetap sampai ke server itu, karena enkripsi tetap terjadi di sana. Pihak di seberang batas adalah server, operator, dan cadangan milik organisasi sendiri. Bagi tim yang sudah menerima sistem itu sebagai bagian dari jalur yang dilalui rahasia, enkripsi sisi server dapat menjadi pilihan yang masuk akal. Ini mempersempit celah antara model ancaman sisi server dan sisi klien, karena operator bukan lagi layanan luar.

PrivateNote mengenkripsi sebelum unggah

PrivateNote standar dienkripsi sebelum diunggah. Browser pengirim, atau proses CLI, ekstensi Chrome, ekstensi editor, atau MCP lokal, menghasilkan kunci acak dan mengenkripsi muatan dengan AES-256-GCM. Hanya teks sandi yang diunggah. TLS membawa teks sandi itu dari browser ke worker Cloudflare milik PrivateNote. Kunci dekripsi ditempatkan di fragmen URL, bagian setelah #, misalnya https://privatenote.ai/note/abc123#…. Fragmen ditangani di sisi klien dan tidak disertakan dalam permintaan HTTPS (RFC 3986, §3.5; Standar URL). Worker menerima pengenal catatan dan mengembalikan teks sandi melalui koneksi TLS yang sama. Browser menyimpan fragmen dan mendekripsi secara lokal.

Frasa sandi melindungi kunci jika saluran tautan disusupi

Frasa sandi di PrivateNote melakukan pekerjaan yang berbeda dari frasa sandi di OneTimeSecret. Catatan sudah berupa teks sandi sebelum meninggalkan perangkat. Jika Anda menambahkan frasa sandi, browser menurunkan kunci pembungkus darinya dengan Argon2id dan memakai kunci pembungkus itu untuk mengenkripsi kunci catatan. Fragmen URL kemudian menyimpan kunci yang dibungkus. Penerima memerlukan tautan dan frasa sandi. Browser membuka bungkus kunci secara lokal, baru kemudian mendekripsi catatan.

PrivateNote tidak menerima frasa sandi. Permintaan pembuatan membawa teks sandi, salt, dan parameter yang diperlukan browser penerima untuk mencoba frasa sandi secara lokal. Tidak ada hash sisi server yang bertugas memverifikasi frasa sandi. Frasa sandi yang salah gagal didekripsi di perangkat.

Frasa sandi juga melindungi kunci sisi klien secara lokal jika saluran yang membawa tautan disusupi. Saluran itu kemudian melihat kunci yang dibungkus, bukan kunci yang dapat membuka catatan dengan sendirinya. Ini bukan mekanisme yang menjaga PrivateNote di luar jalur teks biasa. Pemisahan itu sudah ada pada catatan standar, dengan atau tanpa frasa sandi. Bagikan frasa sandi pada saluran yang berbeda dari tautan. Pesan yang sama meruntuhkan dua lapisan menjadi satu — aturan yang sama seperti membagikan kata sandi dengan aman.

Penanganan kunci PrivateNote dijelaskan di Cara kerjanya: kunci isi dibungkus dengan Argon2id, dan kunci yang dibungkus berjalan di dalam tautan.

Asumsi kepercayaan klien web yang tersisa

Enkripsi sisi klien di browser bukan aplikasi web tanpa kepercayaan. Kriptografi dapat berjalan secara lokal sementara JavaScript yang menerapkannya dikirim oleh situs. Browser memercayai kode yang diterimanya untuk sesi itu.

Seseorang yang dapat mengubah JavaScript itu — melalui aplikasi, CDN, atau jalur penerapan — dapat mengubah klien dan menangkap kunci pada sesi browser di masa depan. Itu kegagalan yang berbeda dari mencuri basis data. Kompromi penyimpanan mengekspos teks sandi. Pengiriman kode berbahaya menyerang endpoint saat kunci benar-benar ada.

Cadangan basis data di kemudian hari tidak dapat membuat kunci sisi klien yang tidak pernah disimpan di sana. Klien yang secara aktif disusupi dapat menyerang rahasia yang ditangani selama sesi itu. Asumsi yang sama tertulis dalam model ancaman PrivateNote: kode aplikasi yang dikirim tidak diubah secara jahat, dan perangkat pengirim serta penerima dipercaya pada saat enkripsi dan dekripsi.

Perangkat lunak yang terpasang mempersempit ketergantungan pada halaman yang baru diunduh. CLI, ekstensi editor, atau aplikasi asli menjalankan kode yang Anda pasang. Klien itu tetap bergantung pada sistem operasi, penandatanganan, dependensi, dan saluran pembaruan. Alat pengembang memakai pemisahan yang sama seperti browser: enkripsi secara lokal, unggah teks sandi, tinggalkan kunci di fragmen.

Masa hidup dan kerahasiaan

Tautan sekali pakai menjawab dua pertanyaan yang terpisah. Berapa lama muatan terenkripsi seharusnya ada? Dan siapa yang dapat mendekripsinya selama ada? Menghancurkannya setelah pengambilan atau kedaluwarsa mempersingkat jendela. Itu tidak menentukan siapa yang dapat membacanya selama jendela itu. Masa hidup dan kerahasiaan saling mendukung. Yang satu tidak menggantikan yang lain.

Pembedaan itu paling tajam saat muatan adalah kewenangan: kunci API, kredensial basis data, token awan, kode pemulihan, kata sandi infrastruktur. Layanan berbagi rahasia ada karena pengirim ingin lebih sedikit sistem yang dipercaya dengan informasi itu. Jika perantara hanya perlu membawa objek terenkripsi yang tidak tembus, menegakkan kedaluwarsa, dan menghapusnya, server dapat melakukan pekerjaan itu tanpa menerima rahasia atau kunci yang membukanya.

Di mana batas itu berada

“Terenkripsi” tidak memberi tahu Anda di mana batas kepercayaan berada. Standar yang layak dipakai adalah batas kepercayaan minimal: prinsip hak akses minimum yang diterapkan pada siapa yang harus melihat teks biasa. Dalam rekayasa kriptografi modern, tujuannya bukan sekadar memercayai bahwa server berperilaku baik, tetapi mengurangi keharusan matematis untuk memercayai sejak awal.

OneTimeSecret menggambarkan sistem terenkripsi sisi server. Dengan perlindungan frasa sandi, OneTimeSecret menyatakan rahasia yang tersimpan kemudian tidak dapat didekripsi tanpa frasa sandi, dan bahwa kompromi server akan membuat rahasia tetap aman selama frasa sandi itu tidak diketahui. Frasa sandi yang lemah dapat dibobol dengan paksa. Jika lemah, kompromi itu tetap dapat membuat rahasia dapat dipulihkan. Teks biasa dan frasa sandi sampai ke OneTimeSecret saat pembuatan, karena enkripsi terjadi di servernya, dan frasa sandi dikirim kembali saat pengambilan agar server itu dapat mendekripsi.

PrivateNote membuat pilihan arsitektur yang berbeda. Muatan dienkripsi sebelum sampai ke layanan, dan kunci muatan standar tetap di sisi klien. Frasa sandi, jika Anda menetapkannya, juga melindungi kunci sisi klien itu secara lokal jika saluran yang membawa tautan disusupi. Frasa sandi tidak dikirim ke PrivateNote.

OneTimeSecret mengenkripsi rahasia Anda. Klien yang memakai layanan PrivateNote mengenkripsinya sebelum layanan menerimanya. Pembedaan itu tidak bergantung pada asumsi bahwa salah satu penyedia berniat jahat. Ini mereduksi pertanyaan menjadi arsitektur: berapa banyak sistem yang perlu akses ke teks biasa agar layanan berfungsi?

Pertanyaan umum

Sumber primer

Informasi arsitektur tentang OneTimeSecret ditinjau terhadap dokumentasi publiknya pada 23 September 2026. Implementasi produk dan dokumentasi dapat berubah.

• Dokumentasi OneTimeSecret
• OneTimeSecret tentang keamanan dan frasa sandi
• Kode sumber OneTimeSecret
• Cara kerja enkripsi PrivateNote
• PrivateNote untuk pengembang, termasuk CLI
• RFC 3986, bagian 3.5, yang memisahkan fragmen dari URI sebelum dereferensi
• Standar URL, fragmen, tentang penanganan fragmen di sisi klien