Mungkinkah solusi yang mungkin untuk ini adalah:

• buat saluran khusus (mungkin tersembunyi per default) per pengguna di server rumah pengguna
• setiap perangkat baru mengirimkan pesan polling (terenkripsi) ke semua perangkat lain (melalui ruangan ini)
• semua perangkat lain membalas dengan status e2e terenkripsi (tanpa pasangan kunci identitas), atau hanya semua kunci yang diperlukan untuk mendekripsi riwayat ruang

@apexo ini semacam rencananya, kecuali kami sekarang memiliki API simpan-dan-teruskan "ke perangkat" khusus untuk berbagi data seperti ini, yang dienkripsi secara bergantian oleh olm. Selain itu, kami mungkin akan meminta status ratchet historis dari perangkat tertentu daripada semuanya, dan mengharuskan pengguna target untuk menyetujui/menolak permintaan tersebut. misalnya "Matthew telah menambahkan perangkat baru 'iPad' dan meminta riwayat kamar sejak 18 September. Apakah Anda ingin berbagi riwayat?" atau sesuatu.

@ara4n Jadi saya saat ini berada di ruangan yang terdaftar dengan tujuh perangkat dari tiga mesin dan banyak browser. baik, saya kira vektor -> transisi kerusuhan membantu meningkatkan jumlahnya. Tetapi dengan hanya satu orang lain di ruangan itu, ini tidak praktis.
Saya lebih suka jika sertifikat sisi klien dapat dikenali sebagai pengguna, dan verifikasi menjadi proses otomatis yang tidak bergantung pada perangkat atau interaksi anggota di ruang dan saya hanya melihat riwayatnya. Akan bekerja pada perangkat pribadi (yaitu bukan komputer perpustakaan).
Untuk memahami prosesnya, bagaimana ID dihasilkan, dan berapa lama disimpan/disimpan? Apakah mereka berubah dengan perubahan versi kernel, browser atau jika saya membersihkan cookie? Saya cukup yakin saya melewatkan diskusi di perangkat yang sama dengan yang saya masuki saat itu...

PS: Saya belum melihat masalah / diskusi lain tentang masalah ini, jadi saya harap ini adalah tempat yang tepat untuk meletakkan ini :)

Mungkin melihat dompet Bitcoin, misalnya http://wallet.counterwallet.io , yang meminta frasa sandi 12 kamus kata dari pengguna. Frasa sandi itu adalah kunci pribadi.

Sekarang ketika saya masuk ke perangkat, saya dapat ditanya apakah saya ingin membuat kunci khusus perangkat, atau apakah saya ingin memasukkan kunci pengguna dari frasa sandi seperti itu.

Bisakah saya memeriksa pemahaman saya, apakah yang berikut ini mewakili perilaku yang diharapkan saat ini?

Katakanlah saya berada di ruangan yang enkripsinya diaktifkan dan kami semua dengan senang hati mengobrol dan semua orang telah memverifikasi kunci. Kemudian saya keluar dari kerusuhan dan kembali untuk melihat bahwa semua percakapan sebelumnya dienkripsi lagi dan tidak ada cara untuk mendapatkan kunci asli untuk Anda, jadi riwayat tetap tidak tersedia?

Terima kasih!

Tidak masalah apakah kunci diverifikasi. Intinya adalah bahwa algoritma enkripsi (megolm/ld double ratchet) mengenkripsi ke kunci saat ini dari semua orang yang hadir.

Sekarang jika Anda keluar dari Riot, kunci Anda dibuang dari penyimpanan lokal, dan setelah bergabung kembali, kunci baru dibuat. Pesan mendatang sekarang akan dienkripsi (juga) ke kunci itu, tetapi karena Anda tidak lagi memiliki akses ke kunci sebelumnya, pesan lama tidak dapat diakses lagi.

Solusinya adalah IMHO untuk memungkinkan seseorang mengekspor/mengamankan/mencadangkan kunci seseorang dan memulihkannya saat bergabung kembali.

Benar, terima kasih @madduck

Saya mengalami masalah kegunaan utama dengan enkripsi ujung ke ujung dalam kerusuhan, dan saya tidak menyadari bahwa itu karena keluar menghapus kunci sesi Anda! riot-Android/#869 akan menyenangkan, karena saya tidak tahu!

Sekarang saya mengerti mengapa saya kehilangan kunci saya -- dan terkunci dari riwayat obrolan saya -- saya harus mengatakan bahwa saya benar-benar kesal. Saya yakin semua orang setuju bahwa Anda tidak harus terus-menerus masuk ke program obrolan Anda agar dapat menggunakannya dengan andal. Menyembunyikan pesan lama dari pendatang baru ke saluran adalah satu hal, tetapi masalah yang sama ini berarti saya tidak dapat membagikan kunci dekripsi dengan diri saya sendiri! Menurut pendapat saya, E2E seharusnya tidak diluncurkan sebagai fitur sebelum masalah ini diselesaikan. Ini adalah kecelakaan kereta api bagi semua orang yang saya kenal yang mencoba menyalakannya.

@kebertx Selain dari masalah ini (yang sekarang saya mengerti) e2e luar biasa bagi saya dan orang-orang yang pernah saya

IIRC, diiklankan sebagai beta dan setidaknya di aplikasi Android dikatakan bahwa e2e adalah "fitur lab eksperimental yang dapat rusak dengan cara yang tidak terduga." Jadi saya pikir peringatan itu sudah cukup adil.

Karena itu, saya pikir banyak hal dapat ditingkatkan (peringatan sederhana tentang kehilangan kunci saat keluar, misalnya akan berguna untuk pengguna baru).

IMO, senang memiliki fitur lebih awal dan dapat mengujinya.

Hai @kebertx , maaf Anda memiliki pengalaman buruk. Memang benar bahwa e2e saat ini masih sangat beta, dan hal-hal tentu perlu ditingkatkan, yang, sebagian, mengapa masalah ini ada.

FWIW, saya rasa tidak perlu logout. Saya memiliki riot.im yang dikecualikan dari cookie munger saya, jadi saya tidak memiliki masalah ini. Demikian pula, saya tidak keluar dari aplikasi Android, tetapi masalahnya akan muncul ketika saya harus beralih ke telepon baru, dan pada saat itu saya berharap mereka sudah memperbaikinya.

(fwiw peringatan telah ditambahkan)

Saya juga tidak melihat kebutuhan untuk keluar, jika aplikasi mendukung banyak identitas , yang tampaknya tidak dilakukan oleh kerusuhan, jadi masuk dan keluar akan menjadi solusi bagi saya. Atau saya bisa menggunakan pengguna Android kedua, tetapi itu lebih menguras baterai saya.

@madduck Anda juga dapat melakukan sebaliknya dengan mengekspor kunci pribadi yang ada sebagai mnemonik - misalnya BIP39 menggunakan 2048 daftar kata (https://github.com/bitcoin/bips/blob/master/bip-0039/english. txt) yang cukup untuk menyimpan kunci 128-bit (2048^12). Meskipun satu masalah adalah bahwa kunci ed25519 dan curve25519, apakah saya percaya diturunkan secara independen di Olm? Jadi, Anda akan membutuhkan mnemonik untuk keduanya, atau dukungan yang diturunkan satu dari yang lain.

@ara4n

Demikian pula jika saya diundang ke sebuah ruangan oleh seseorang dan mereka ingin berbagi sejarah masa lalu dengan saya, mereka membutuhkan cara untuk mentransfer data kunci.

Saya tidak yakin saya memahami masalah aslinya dengan sangat baik, tidak bisakah anggota yang ada hanya membagikan kunci semua session_keys yang telah mereka terima dari anggota lain di ruangan itu melalui. sendToDevice api yang sama menggunakan Sesi Olm seperti yang biasa dilakukan ketika klien membagikan kunci sesi keluar mereka?

setelah membaca komentar sebelumnya - sebagian besar tidak terkait dengan bug ini, tetapi merupakan masalah umum UISI (#2996) atau masalah manajemen utama (#3611);

Sesuai https://github.com/vector-im/riot-web/issues/2996#issuecomment -299290453 kami melanjutkan dan menerapkan ini secepatnya, baik untuk menyediakan pintu keluar untuk membersihkan UISI yang tersisa serta untuk menyediakan fitur sinkronisasi riwayat ke perangkat baru tanpa harus mengekspor/mengimpor ulang kunci sesi megolm secara manual. @richvdh , @NegativeMjark dan saya baru saja membahas bagaimana ini harus bekerja, menghasilkan rencana:

• Jika klien menerima pesan yang tidak memiliki kunci sesi megolm (yaitu UISI), ia harus mengirim pesan ke_perangkat ke semua perangkat (yaitu "*" ) milik mereka sendiri dan pengirim, meminta kunci yang hilang .
• Secara default, pengirim akan secara otomatis membagikan ulang kunci megolm ke perangkat yang telah mereka verifikasi (jika mereka mengirim pesan ke perangkat itu, atau perangkat mereka sendiri).
• Jika perangkat tidak diverifikasi, mereka memiliki opsi untuk memverifikasinya sebelum berbagi, atau mengabaikan permintaan (dan/atau memasukkan perangkat ke daftar hitam?)
• Kami juga akan menyediakan pengaturan yang disebut "Jangan secara otomatis membagikan kunci E2E dengan perangkat baru" di pengaturan, sehingga pengguna paranoid dapat secara eksplisit mengotorisasi ini.

Secara terpisah, kami jelas perlu meningkatkan UX verifikasi, misalnya dengan menandatangani silang perangkat untuk mempercayainya secara otomatis, kode QR atau mnemonik untuk memverifikasi sidik jari, dll. Namun ini semua #2142 dan ortogonal dengan masalah sebenarnya berbagi kunci.

Kami juga membahas apakah kami harus menyimpan kunci megolm di server, untuk mencoba meningkatkan masalah kapasitas penyimpanan kunci sisi klien (#3660) atau untuk menyediakan cara yang lebih mudah untuk mencadangkan kunci dan/atau membagikannya - ini adalah #3661. Kami menyimpulkan bahwa ini pada dasarnya adalah pengoptimalan untuk penyimpanan kunci dan tidak akan mengubah semantik kripto sama sekali (yaitu jika Anda kehabisan penyimpanan sisi klien, Anda dapat menggunakan layanan penyimpanan cloud terenkripsi untuk menyimpan data, tapi itu tidak akan mengubah perilaku E2E kami).

Akhirnya, kami mempertimbangkan kasus tepi bahwa Alice dan Bob sama-sama paranoid, dan hanya pernah menggunakan Matrix dengan membuka jendela penyamaran, masuk, mengirim pesan, dan menutup tab (tidak masuk akal). Akibatnya, pada titik tertentu mereka mungkin tidak akan memiliki perangkat apa pun yang aktif. Oleh karena itu ketika Alice mengirim pesan ke Bob, dia tidak akan tahu cara mengenkripsi untuknya, dan ketika Bob mendapatkan UISI, tidak akan ada perangkat Alice yang bisa dia minta kunci megolm (kecuali Alice kebetulan sedang login dan telah mengimpor kembali kunci megolmnya pada saat Bob meminta histori, atau mungkin nanti). Kami menyimpulkan bahwa ada dua kemungkinan solusi untuk ini:

1. Perkenalkan konsep 'perangkat virtual' sehingga Alice & Bob dapat memelihara perangkat virtual yang disimpan terenkripsi di server, dan diteruskan di antara login fisik, membiarkan mereka mengambil percakapan saat diinginkan - ini hampir bertindak sebagai 'kunci identitas '.
2. Perkenalkan konsep perangkat yang sengaja 'menghidrasi' dan 'menghidrasi', sehingga saat Bob berhenti menggunakan jendela Penyamarannya, dia dapat secara eksplisit mengekspor perangkat tersebut secara utuh ke stik USB atau apa pun, dan kemudian menghidrasinya kembali saat membuka tab penyamaran - secara efektif mencadangkan & membatalkan pencadangan perangkat.

Pada akhirnya, kedua hal ini sama saja dengan ide yang sama, apakah perangkat disimpan terenkripsi di server atau di stik USB. Keduanya menderita #3822 - bahwa jika dua perangkat identik pernah ada secara bersamaan Olm akan benar-benar terjepit dan E2E akan rusak. Jadi kesimpulannya adalah untuk mengedukasi pengguna bahwa mereka perlu menjaga setidaknya satu perangkat tetap aktif jika mereka mengharapkan E2E berfungsi, kecuali jika kita pernah mencapai perangkat dehidrasi/rehidrasi.

@pik : semoga ini sedikit menyelesaikan kebingungan Anda :)

Apakah juga akan ada tombol di suatu tempat untuk meminta _semua_ kunci dari salah satu perangkat Anda sendiri, untuk membantu migrasi dari satu perangkat ke perangkat lainnya? Tanpa ini, sepertinya ketika orang ingin mengganti satu perangkat dengan yang lain, orang perlu mengekspor/mengimpor kunci secara manual (sedikit kurang nyaman daripada hanya mengklik tombol untuk meminta kunci), atau pergi ke setiap ruang terenkripsi dan isi ulang ke awal sehingga perangkat secara otomatis meminta kunci (jauh lebih tidak nyaman).

@uhoreg mungkin. saya agak takut pada seberapa kuat tombol seperti itu; setidaknya penyerang perlu mengetahui ID sesi megolm yang mereka coba dapatkan kuncinya dalam acara "send_missing_keys" to_device yang diuraikan di atas. Sedangkan "send_all_keys_ever" terasa seperti hal yang buruk untuk jatuh ke tangan yang salah...

saya telah membagi garis singgung 'perangkat hidrasi/dehidrasi' menjadi #3825

Pemikiran: kami memiliki masalah UX secara umum di mana acara "send_missing_keys" hanya akan ditindaklanjuti oleh perangkat pengirim jika itu terjadi secara online. Jadi kita mungkin berakhir menatap UISI cukup lama sampai salah satu perangkat yang memiliki kunci mengambil permintaan dan tindakan itu. Mungkin kita dapat mengurangi ini di UI dengan mengganti nama ubin "meminta kunci..." ketika skenario ini terjadi (bukan UISI)?

Pada akhirnya, kedua hal ini sama saja dengan ide yang sama, apakah perangkat disimpan terenkripsi di server atau di stik USB. Keduanya menderita #3822 - bahwa jika dua perangkat identik pernah ada secara bersamaan Olm akan benar-benar terjepit dan E2E akan rusak. Jadi kesimpulannya adalah untuk mengedukasi pengguna bahwa mereka perlu menjaga setidaknya satu perangkat tetap aktif jika mereka mengharapkan E2E berfungsi, kecuali jika kita pernah mencapai perangkat dehidrasi/rehidrasi.

Jadi dalam hal ini kunci Bob tetap sama tetapi device_id dapat berubah (jika saya mengerti dengan benar). Saat ini dimungkinkan untuk memulihkan deviceId saat login (tetapi mengetik ID perangkat sepertinya bukan fitur UI yang ramah pengguna). Mungkin tidak menggunakan to_device tetapi memiliki to_curve25519_key api akan bekerja tetapi itu mungkin menimbulkan masalah baru juga?

Atau bagaimana dengan menghasilkan device_id secara deterministik dari kunci publik curve_25519/ed_25519? Pada dasarnya jika kunci Anda berubah, device_id Anda berubah - jika Anda mengimpor kunci Anda, itu dianggap sebagai perangkat yang sama.

tidak, ide perangkat virtual atau rehidrasi adalah mereka akan menyimpan ID perangkat yang sama. setuju bahwa menghasilkan ID perangkat dari pubkey-nya akan masuk akal. silakan gunakan bug split-out #3825 untuk diskusi lebih lanjut tentang ide rehidrasi. (Tuhan, saya berharap GH punya threading)

@ara4n di poin ketiga https://github.com/vector-im/riot-web/issues/2286#issuecomment -299532155, haruskah dikatakan

(jika mereka mengirim pesan ke pengguna itu , atau itu perangkat mereka sendiri).

dari pada

(jika mereka mengirim pesan ke perangkat itu , atau perangkat mereka sendiri).

Atau apakah itu benar-benar hanya mengirim ke perangkat yang seharusnya sudah menerima kunci?

ya, ini adalah sebuah pemikiran. idenya adalah bahwa perangkat pengirim akan mengirim ulang kunci ke salah satu perangkat pengguna target jika mereka telah memverifikasi perangkat tersebut.

https://github.com/matrix-org/matrix-js-sdk/pull/454 dll memberikan perbaikan sebagian untuk bug ini; kami sekarang meminta kunci dari perangkat kami sendiri.

Masih ada pekerjaan yang harus dilakukan di sini, meskipun:

• membuat pengelolaan permintaan kunci lebih dapat diandalkan (setelah Anda menutup dialog, tidak ada cara untuk berubah pikiran)
• UX yang lebih baik untuk menangani permintaan utama secara umum (#4522)
• tanyakan juga kepada perangkat pengirim asli untuk kuncinya (karena itulah satu-satunya perangkat yang mengetahui dengan pasti apakah Anda berada di ruangan pada saat itu)

dokumen desain untuk ini adalah https://docs.google.com/document/d/1USqQVhEEiuBQF9MmECHEyN6zy6BolTJSdTfytbTT_sY/edit , ftr

Ini semua dilakukan dan hidup pada semua SDK sekarang, selain kemampuan untuk kunci permintaan dari perangkat pengirim asli.

Permintaan maaf saya; pesan ini sepertinya sedikit membingungkan bagi saya, jika kemampuan untuk meminta kunci dari perangkat pengirim asli belum dilakukan dan hidup, lalu apa sebenarnya, dan apa yang masih hilang? Juga, banyak dari masalah yang dirujuk ini masih Terbuka; apakah mereka termasuk dalam "semua"?

masalah yang dirujuk yang terbuka masih terbuka.
kemampuan untuk meminta kunci antara perangkat milik pengguna diimplementasikan dan aktif di matrix-{js,ios,android}-sdk.
kemampuan untuk memintanya dari perangkat pengirim asli tidak ada, oleh karena itu bug ini belum ditutup.

Terima kasih! Itu sangat membantu membentuk gambaran yang jelas.

Baru saja membahas ini dengan @richvdh dalam sinkronisasi mingguan pagi ini, dan kesimpulannya adalah bahwa kami mungkin ingin menerapkan tombol "mohon minta ulang kunci untuk pesan ini", untuk mengurangi skenario di mana permintaan atau respons keyshare hilang. Skenario meliputi:

• Menerima kerusakan atau kesalahan perangkat sebelum mengirim respons
• Toko e2e klien rusak
• ...dan pada dasarnya penyebab utama UISI lainnya.

Kami sangat setuju bahwa akan lebih baik untuk memperbaiki akar penyebab daripada kertas di atas mereka seperti ini - tetapi diberi pilihan antara memiliki dan tidak memiliki tombol penyelamatan terakhir, saya pikir ini adalah pilihan yang paling buruk sekarang.

Dalam pengalaman saya, permintaan tersebut tampaknya hilang pada dasarnya setiap saat sejauh ini, yang sedikit disayangkan. Menandatangani perangkat baru adalah satu-satunya cara yang saya miliki untuk memulihkan ketika kripto secara acak memutuskan untuk rusak, dan mengekspor/mengimpor ulang kunci E2E secara manual melibatkan terlalu banyak langkah rawan kesalahan untuk menjadi sesuatu yang ingin saya pertaruhkan berulang kali pada opsec saya.

@ara4n Tombol permintaan ulang di Riot-web sepertinya tidak berfungsi untuk pesan lama _Anda_.

kemampuan untuk memintanya dari perangkat pengirim asli tidak ada

masih hilang?

Saya telah menulis proposal lain untuk menyelesaikan ini (yaitu untuk meminta kunci dari perangkat pengirim, serta kasus khusus DM): https://docs.google.com/document/d/1_wDoDQ02JLZwYeVb-QVPylnJUXJVTZ9bNoGHd_Go6Zg

Ada banyak diskusi tentang ini di #e2e- dev:matrix.org tempo hari (sekitar https://matrix.to/#/!uewiilduiDRfPomIha:matrix.org/$1530880581166IkkUg:sw1v.org), di mana kami menyadari bahwa tidak apa-apa bagi penerima untuk mengirim permintaan berbagi kunci ke anggota ruang sewenang-wenang (kebaikan modulo UX), dengan asumsi bahwa klien melacak keanggotaan ruang pada titik ketika mereka pertama kali melihat sesi megolm yang diberikan. Karena kami merotasi sesi megolm setiap kali ada yang pergi, maka klien yang berperilaku baik di ruangan dapat memutuskan apakah pemohon harus diizinkan melihat pesan atau tidak.

Kami mungkin tidak pernah ingin memunculkan kotak dialog KS req untuk klien tersebut untuk perangkat yang tidak diverifikasi, tetapi untuk perangkat yang diverifikasi mungkin kami dapat secara diam-diam menghormati permintaan sebagai cara yang lebih baik untuk memulihkan dari UISI?

dengan asumsi bahwa klien melacak keanggotaan suatu ruangan pada titik ketika mereka pertama kali melihat sesi megolm tertentu

ini adalah asumsi besar, meskipun. Mereka tidak, dan itu akan menjadi sejumlah besar data, dan akan terbang di hadapan gagasan bahwa klien tidak perlu menyimpan riwayat kamar yang lengkap.

(varian tempat kami berbagi kunci untuk ruang tertentu OOB adalah https://github.com/vector-im/riot-web/issues/6454

Apakah ini masih diselidiki?

Saya baru-baru ini menyiapkan server Synapse saya sendiri dan menemukan bahwa memulai ulang terkadang menyebabkan beberapa sesi tidak dapat didekripsi oleh beberapa perangkat. Ada juga daftar masalah GitHub lain yang cukup panjang terkait dengan pesan yang tidak didekripsi ketika seharusnya dapat didekripsi.

Sepertinya mengaktifkan fitur ini sendirian dapat membuat banyak masalah enkripsi menjadi jauh lebih enak. Saya telah menambahkan hadiah $100 untuk masalah ini untuk mendorong penyelesaiannya. Itu berakhir pada 20 November, tetapi jika masih aktif, saya dapat memperpanjangnya.

Detail hadiah: https://www.bountysource.com/issues/38093648-let-devices-request-keys-to-decrypt-past-history-for-a-room

Ada beberapa perbaikan terbaru di Synapse untuk menyelesaikan beberapa masalah dekripsi. Selain itu, @JorikSchellekens telah menambahkan beberapa kode untuk membantu men-debug masalah tersebut.

Orang-orang menunjukkan bahwa kadang-kadang pesan saya agak meradang dan drastis, namun kenyataannya enkripsi di Riot masih buruk, bermasalah, dan tidak dapat digunakan. Alasan:

1. Jika saya memiliki beberapa perangkat, saya perlu memverifikasi semuanya. Jika orang lain di ruangan saya perlu memverifikasi semua perangkat mereka dan mereka harus memverifikasi perangkat mereka dan semua perangkat saya yang membosankan, membuang banyak waktu dan sangat aneh. Tidak ada utusan lain yang menggunakan algoritma yang rumit dan rumit seperti itu.
2. Jika saya membutuhkan ruang terenkripsi dengan puluhan atau ratusan orang - Kerusuhan menjadi benar-benar tidak dapat digunakan di sini karena jumlah negosiasi melebihi semua batas dan kenyamanan yang wajar.
3. Saya punya kamar dengan 2 orang. Yang pertama (memegang kunci enkripsi dan cadangan di server) dapat mengirim pesan yang dapat didekripsi dan dilihat oleh yang pertama dan kedua, namun pesan dari yang kedua tidak dapat didekripsi oleh yang pertama. Dan situasi seperti itu SANGAT sering muncul saat masuk kembali, memuat ulang, mengirim pesan - tidak dapat diprediksi. Permintaan ulang kunci enkripsi dari perangkat lain tidak berfungsi sama sekali.

Pikirkan kebutuhan untuk memperbaiki dan mengubah ide enkripsi secara radikal untuk membuatnya nyaman dan transparan bagi orang-orang: #9633.

Saya baru saja membaca seluruh utas ini dan saya masih tidak mengerti persis apa konsekuensi dari E2E atau seharusnya bagi pengguna.

Jika memang benar-benar keluar dan masuk kembali dapat menyebabkan Anda kehilangan akses ke pesan yang sebelumnya Anda miliki, itu tampaknya tidak masuk akal. Masuk dan keluar di perangkat yang sama seharusnya tidak memengaruhi akses ke pesan dengan cara apa pun. Juga, pesan saat ini dari aplikasi ini sama sekali tidak jelas. Ini memiliki beberapa pesan tentang "cadangan kunci" dan kemudian alternatifnya adalah "Saya tidak ingin pesan terenkripsi saya". Jika kasus logout kehilangan akses ke pesan, aplikasi perlu mengatakannya secara eksplisit, seperti "PERINGATAN: Jika Anda logout, Anda akan kehilangan akses ke pesan terenkripsi!"

Juga disarankan di #8751 bahwa mengekspor kunci dan kemudian mengimpornya nanti tidak akan memberikan akses ke pesan lama. Jika demikian, lalu apa tujuan mengekspor kunci? Perlu ada dokumentasi yang lebih jelas yang memberi tahu pengguna "Jika Anda melakukan ini, Anda akan kehilangan akses ke pesan ini dan itu". Saat ini saya agak enggan untuk keluar di perangkat apa pun karena tidak ada tempat saya dapat menemukan pernyataan eksplisit tentang bagaimana menentukan apa konsekuensinya.

8751 mengatakan mereka tidak seperti kunci GPG karena mereka tidak memberi Anda akses ke pesan mendatang , bukan karena mereka tidak memberi Anda akses ke pesan lama (hanya itu yang mereka lakukan). Akan mengedit masalah dengan asumsi bahwa penjelasannya lebih jelas.

Saya memiliki masalah yang sama, pada Riot versi terbaru 0.9.8 (F-b98798510).
Hari ini saya uninstall dari F-droid, setelah menemukan bahwa Riot dari F-droid tidak menampilkan pesan baru kecuali saya membukanya.
Saya menginstalnya dari Google Play Store, yang menggunakan layanan Google untuk mendorong pesan.

Saya dapat melihat orang-orang yang mengobrol dan pesan mereka tetapi semuanya tidak dapat dibaca, dan menampilkan pesan::
" * Tidak dapat mendekripsi: Perangkat pengirim belum mengirimkan kunci untuk pesan ini kepada kami. *
Minta kembali kunci enkripsi dari perangkat Anda yang lain."

Ketika saya menyentuh "Minta ulang enkripsi ..." pada pesan terakhir saya, itu menunjukkan pesan:
"Permintaan terkirim
Silakan luncurkan Riot di perangkat lain yang dapat mendekripsi pesan sehingga dapat mengirim kunci ke perangkat ini."

Saya pikir Anda melihat ironi dari pesan itu :)

Pokoknya saya mencopot Riot dari Google Play Store.
Menginstal Riot dari F-droid.
Semua pesan tidak dapat dibaca.
Setelah menggunakan "Kunci pemulihan untuk kunci enkripsi", saya dapat melihat beberapa pesan pertama terenkripsi dan terlihat oleh saya.
Tetapi yang terbaru dienkripsi dan tidak dapat dibaca oleh saya, menampilkan pesan ::
"** Tidak dapat mendekripsi: Perangkat pengirim belum mengirim ..."

Bahkan pesan terakhir saya sendiri tidak terbaca oleh saya.
Di ponsel yang sama, dengan versi Riot yang sama dari F-droid, dengan "kunci cadangan" yang sama.
Saya menyentuh lagi "Minta ulang kunci enkripsi ..." tetapi hasilnya sama.
Itu lagi menunjukkan "Permintaan kunci terkirim" di bawah pesan, tetapi saya tidak tahu kepada siapa itu dikirim.
Bukan untukku, meskipun itu adalah pesanku dari ponsel yang sama.

Saya ingin menjadi konstruktif, jadi tolong beri tahu saya jika saya dapat membantu.
Terima kasih atas pekerjaan Anda :)

Saya menghapus Riot dari F-droid dan menginstal Riot dari Google Play Store.
Hasilnya sama.
Kunci cadangan tidak pernah berfungsi, baik di Riot dari F-droid dan dari Google.
Saya mencoba kedua kata sandi, juga karena saya tidak mengerti untuk apa.
Sebagai gantinya, "Frase sandi pemulihan" memberikan hasil yang disebutkan di atas.
Perhatikan bahwa "Frase sandi pemulihan" disebut "Kunci Pemulihan untuk kunci enkripsi" saat menginstal Riot, dan "Frase sandi pemulihan" setelah diinstal.

Saya mengirim pesan ke satu-satunya orang dalam obrolan dan saya mendapat pesan (teks tidak tepat karena berasal dari ingatan saya):
"Tidak dapat mengirim pesan karena obrolan berisi perangkat yang belum diverifikasi."

Jadi saya menyentuh "perangkat" dan saya melihat daftar sembilan perangkat, semuanya belum diverifikasi kecuali yang pertama.
Baris pertama mereka adalah sebagai berikut:
Ponsel (ini satu-satunya dengan kunci hijau)
https://riot.im/app melalui Safari di Linux
Seluler
Seluler
https://riot.im/app/ melalui Firefox di Linux
https://riot.im/app/ melalui Firefox di Linux
Seluler
(baris kosong)
Seluler

Saya mungkin pernah menggunakan Riot sekali melalui Firefox, tetapi tentu saja tidak dengan Safari dan tidak dengan ponsel lain.

Ya, situasi masih belum diperbaiki. Salah satu pengguna saya tidak dapat membaca beberapa pesan di sebuah ruangan - lihat yang terbaru, tidak dapat mendekripsi yang lama dan saya tidak dapat mengiriminya kunci enkripsi secara otomatis. Permintaan kunci perangkatnya yang lain melakukan semacam ini sebagian. Fitur yang sangat buggy, tidak ramah pengguna dan tidak nyaman.

Pembaruan aplikasi terbaru tampaknya telah memunculkan banyak pesan ini selama beberapa hari terakhir:

Saya suka fitur keamanan yang tampaknya telah dijadikan default dengan rilis Element, kecuali fakta bahwa mereka menciptakan masalah kegunaan yang mungkin membuat sangat sulit untuk membuat orang mengadopsinya dan/atau tetap menggunakannya!!

Itu tidak terlihat seperti elemen-web @andrewperry

Saya mengira pesan di tangkapan layar ini dikirim dari desktop Mac yang saya pahami membungkus elemen-web, tetapi saya dengan bebas mengakui bahwa saya lebih fokus pada topik utas ini daripada faktanya pada proyek elemen-web. Memeriksa sumber pesan yang saya lihat sekarang berasal dari aplikasi iOS, saya minta maaf karena melaporkan dalam proyek yang salah.

@andrewperry hanya ingin menyebutkan solusi sampai diperbaiki. Saya keluar dari aplikasi dan masuk lagi yang memicu permintaan kunci enkripsi dan akhirnya saya bisa membaca pesan lagi.

Solusi lain (mengharuskan pengguna yang memiliki kunci untuk memiliki keterampilan baris perintah yang relevan, tetapi sebaliknya cukup mudah) adalah dengan menggunakan ini:

https://github.com/cyphar/matrix-utils