#opg $OPG
Enkripsi terdengar lengkap bagi saya sampai saya mengajukan pertanyaan yang sedikit tidak nyaman:
Enkripsi untuk siapa?
Sebuah pesan bisa saja tertutup sempurna dan tetap dikirim ke mesin yang salah. Jika saya menerima kunci publik apapun yang diberikan server kepada saya, saya melindungi prompt dalam perjalanan tanpa membuktikan siapa yang bisa membukanya.
Itu adalah detail dalam OpenGradient Chat yang hampir saya abaikan.
Sebelum chat.opengradient.ai mengenkripsi permintaan pribadi, klien memeriksa enclave terlebih dahulu.
Ia memverifikasi bahwa attestation perangkat keras datang dari infrastruktur AWS Nitro yang asli. Ia membandingkan pengukuran PCR mesin dengan build yang disetujui yang direkam dalam registry TEE OpenGradient. Ia juga mengonfirmasi bahwa kunci enkripsi dibuat di dalam enclave yang tepat itu dan bukan secara sembunyi-sembunyi diganti di luar sana.
Hanya setelah semua pemeriksaan itu lolos, prompt akan disegel.
Pesanan ini mengubah cara saya berpikir tentang "enkripsi ujung-ke-ujung."
Enkripsi saja mengatakan bahwa orang luar tidak dapat membaca pesan itu.
Attestation menanyakan apakah penerima yang dimaksud benar-benar menjalankan perangkat lunak yang diklaimnya jalankan.
Pertanyaan kedua itu penting karena koneksi yang aman ke kode yang dimodifikasi tetaplah koneksi yang aman ke kode yang dimodifikasi.
@OpenGradient membuat klien memverifikasi tujuan sebelum mempercayai kunci. SDK menangani pemeriksaan sulit itu dengan tenang, tetapi pengguna mendapat manfaat dari hasilnya: sebuah build yang tidak disetujui seharusnya tidak menerima prompt sensitif sama sekali.
Bagi saya, itu lebih kuat daripada ikon kunci lainnya.
Apakah Anda lebih suka mempercayai enkripsi itu sendiri, atau membuat perangkat Anda memverifikasi mesin sebelum mengirimkan apapun?
Ini adalah jenis infrastruktur tersembunyi yang memberikan $OPG konteks produk yang sebenarnya.
Enkripsi terdengar lengkap bagi saya sampai saya mengajukan pertanyaan yang sedikit tidak nyaman:
Enkripsi untuk siapa?
Sebuah pesan bisa saja tertutup sempurna dan tetap dikirim ke mesin yang salah. Jika saya menerima kunci publik apapun yang diberikan server kepada saya, saya melindungi prompt dalam perjalanan tanpa membuktikan siapa yang bisa membukanya.
Itu adalah detail dalam OpenGradient Chat yang hampir saya abaikan.
Sebelum chat.opengradient.ai mengenkripsi permintaan pribadi, klien memeriksa enclave terlebih dahulu.
Ia memverifikasi bahwa attestation perangkat keras datang dari infrastruktur AWS Nitro yang asli. Ia membandingkan pengukuran PCR mesin dengan build yang disetujui yang direkam dalam registry TEE OpenGradient. Ia juga mengonfirmasi bahwa kunci enkripsi dibuat di dalam enclave yang tepat itu dan bukan secara sembunyi-sembunyi diganti di luar sana.
Hanya setelah semua pemeriksaan itu lolos, prompt akan disegel.
Pesanan ini mengubah cara saya berpikir tentang "enkripsi ujung-ke-ujung."
Enkripsi saja mengatakan bahwa orang luar tidak dapat membaca pesan itu.
Attestation menanyakan apakah penerima yang dimaksud benar-benar menjalankan perangkat lunak yang diklaimnya jalankan.
Pertanyaan kedua itu penting karena koneksi yang aman ke kode yang dimodifikasi tetaplah koneksi yang aman ke kode yang dimodifikasi.
@OpenGradient membuat klien memverifikasi tujuan sebelum mempercayai kunci. SDK menangani pemeriksaan sulit itu dengan tenang, tetapi pengguna mendapat manfaat dari hasilnya: sebuah build yang tidak disetujui seharusnya tidak menerima prompt sensitif sama sekali.
Bagi saya, itu lebih kuat daripada ikon kunci lainnya.
Apakah Anda lebih suka mempercayai enkripsi itu sendiri, atau membuat perangkat Anda memverifikasi mesin sebelum mengirimkan apapun?
Ini adalah jenis infrastruktur tersembunyi yang memberikan $OPG konteks produk yang sebenarnya.