Ricochet: Transfer file

Wah, ini masalah lama. Sudah waktunya untuk menyelesaikan ini. Mari kita bicara tentang transfer file. Ini sebagian meminta umpan balik, sebagian mencoba meyakinkan diri sendiri, dan sebagian lagi braindump, tapi semoga bermanfaat.

UX

Saya melihat dua jenis kasus penggunaan yang luas untuk transfer file. Pengguna aktif mengirim dan menerima file selama percakapan, dan berharap file tersebut menjadi bagian dari percakapan mereka. File drop adalah untuk minoritas penting pengguna Ricochet yang ingin tetap online dan dapat menerima file kapan saja, bahkan jika mereka tidak langsung aktif.

Seperti kebanyakan aplikasi perpesanan, kami ingin melakukan transfer file sebaris sebagai bagian dari percakapan , dan mereka tidak harus menggunakan aplikasi lain (termasuk browser).

Seret dan lepas file ke dalam percakapan adalah cara biasa untuk mengirim file. Diperdebatkan, mungkin mudah untuk secara tidak sengaja mengirim file dengan cara ini. Itu dapat dikurangi dengan memasukkan file ke dalam kotak hitungan mundur sebelum mengirim . Harus ada metode UI lain yang

File yang ditawarkan harus kedaluwarsa setelah waktu yang cukup untuk mengasumsikan bahwa pengguna mungkin telah lupa.

Model ancaman Ricochet melarang penyimpanan data percakapan (termasuk file) secara otomatis. Model ancaman juga melihat kontak sebagai musuh eksploitasi potensial, jadi kami ingin mengurangi serangkaian tindakan yang dapat dipicu oleh kontak tanpa persetujuan pengguna. Ini menunjukkan bahwa kita harus meminta penerimaan eksplisit secara default untuk transfer file. Pengguna harus secara eksplisit memilih tempat untuk menyimpan setiap file, kecuali mereka mengonfigurasi lokasi default. Ini baik-baik saja dengan kasus penggunaan pengguna aktif, tetapi untuk file drop kita akan memerlukan opsi untuk menyimpan file secara otomatis (yang juga bisa per-kontak).

Penawaran atau transfer aktif harus mudah terlihat oleh kedua belah pihak. Selain menunjukkan kemajuan transfer dalam percakapan , harus ada kemajuan di header percakapan (tab transfer?) dan/atau status transfer global di suatu tempat. Ini sangat penting karena percakapan dapat berlanjut saat transfer sedang berlangsung. Ketika transfer selesai, itu harus dipindahkan ke akhir percakapan.

Transfer yang telah selesai dibuka dengan mengklik , dengan peringatan yang mirip dengan peringatan browser.

Tor telah dikenal tidak dapat diandalkan, jadi kemampuan untuk melanjutkan akan menjadi penting. Kita harus menyambung kembali dan melanjutkan secara otomatis bila memungkinkan. Jika terlalu banyak waktu telah berlalu, atau salah satu klien telah kehilangan riwayatnya, melanjutkan masih dapat dilakukan dengan menyimpan file yang sudah ada tidak lengkap .

UX masa depan

Menampilkan gambar sebaris dengan percakapan adalah fitur perpesanan standar. Ini mudah dilakukan setelah kami memiliki transfer file, kecuali bahwa saya tidak mempercayai dekoder gambar . Setelah kami menemukan dekoder yang kuat dan aman memori, atau sandboxing gaya seccomp lintas platform, ini layak dilakukan.

Seseorang menunjukkan bahwa kita bisa prefetch file, setidaknya dengan membangun koneksi dan buffering sampai beberapa batas di memori, untuk membuat proses transfer tampaknya lebih cepat.

Akan lebih baik untuk mengizinkan mentransfer kumpulan file atau seluruh folder hingga batas yang wajar.

Memiliki cara untuk secara otomatis memverifikasi hash dari file yang diunduh dengan server pengirim akan bagus.

Protokol

koneksi

Data file tidak dapat dikirim melalui koneksi protokol utama Ricochet. Meskipun kami mengemas data, karena properti buffering untuk aliran Tor, sejumlah besar data akan berada dalam antrian saat membanjiri koneksi layanan tersembunyi. Hal ini menyebabkan latensi yang ekstrem (seringkali 30 detik atau lebih) untuk streaming tersebut. Bentuk kontrol kecepatan lainnya akan berdampak terlalu besar pada kecepatan transfer.

Jawaban sederhananya adalah membuka koneksi tambahan ke layanan rekan. Koneksi ini akan dimultipleks oleh Tor ke sirkuit yang sama, tetapi perilaku buffering jauh lebih baik. Dalam pengujian biasa tampaknya tidak ada dampak signifikan pada latensi pesan saat membanjiri data ke aliran lain di sirkuit yang sama.

Kami juga dapat menggunakan opsi isolasi sirkuit untuk memaksa Tor membangun sirkuit baru untuk transfer. Tidak jelas apakah ini akan berguna untuk throughput atau latensi, dan tidak jelas apakah membangun sirkuit konkuren tambahan akan memiliki anonimitas signifikan atau dampak analisis lalu lintas.

Protokol Ricochet tidak mengizinkan lebih dari satu koneksi terotentikasi per kontak, karena akan menjadi ambigu koneksi mana yang harus digunakan dan dapat melanggar harapan pada pemesanan pesan. Jika koneksi tambahan menggunakan protokol Ricochet, mereka perlu mengautentikasi secara berbeda untuk menunjukkan bahwa koneksi hanya digunakan untuk transfer data.

Karena transfer data terjadi melalui koneksi sekunder, kami tidak diharuskan untuk mengemas data dengan protokol Ricochet. Ada baiknya memikirkan opsi di sini.

Opsi 1: Protokol Ricochet yang Dimodifikasi

Pemikiran awal saya adalah menggunakan protokol Ricochet untuk transfer data file pada koneksi tambahan. Ini tidak sepenuhnya mudah.

Manfaat:

• Dapat dengan mudah mengirim file kecil sebaris melalui koneksi protokol
• Lebih konsisten dengan protokol yang ada
• Tidak ada permukaan serangan parser/server baru

Kelemahan:

• Hanya ada satu koneksi utama, jadi otentikasi akhirnya menjadi aneh
• Kecuali jika kami membuat modifikasi protokol yang lebih dalam, data harus dipecah menjadi potongan maksimal 65kb dengan header
• Desain dan implementasi protokol sulit dilakukan dengan benar

Ada beberapa pekerjaan lama tentang tampilannya dari cabang WIP di FileTransferChannel.proto dan FileTransferDataChannel.proto .

Opsi 2: HTTP (preferensi saya saat ini)

Klien Ricochet dapat menawarkan file melalui HTTP, menggunakan server internal sederhana dan URL unik, mirip dengan OnionShare . Server tersebut dapat berada di port yang berbeda (mungkin secara acak) dari layanan tersembunyi yang sama, pada layanan ephemeral baru, atau bahkan berbagi port yang sama menggunakan deteksi protokol.

Manfaat:

• Implementasi yang lebih kuat/standar/bukti masa depan
• Kompatibilitas mundur penerima: dapat mundur secara alami untuk menampilkan URL
• Mungkin bagi penerima untuk mengunduh menggunakan browser & alat lainnya
• Dapat digunakan untuk menawarkan file ke non-kontak juga

Kelemahan:

• Bahkan klien dan server HTTP yang sangat minim adalah permukaan serangan protokol baru untuk kontak
• Tidak jelas implementasi C++/Qt apa yang cukup aman untuk digunakan

Implementasi server/klien

Tidak perlu klien HTTP yang 100% lengkap fitur dan kompatibel dengan perilaku di Ricochet, karena kasus penggunaan di sini sangat minim. Untuk menjaga potensi bug serendah mungkin, saya akan membatasi implementasi pada fitur yang kami _butuhkan_, dan tidak menggunakan (misalnya) opsi penyandian transfer terpotong atau opsi esoterik. Kita bahkan bisa memaksa Connection: close jika itu membantu. Ini akhirnya menjadi sejumlah kecil kode yang terpapar jaringan, dan umumnya masih kompatibel dengan klien dan server lain.

Perilaku server dan format URL

Saya lebih suka menempatkan server HTTP pada port acak di bawah layanan tersembunyi yang sama. Membawa layanan baru terkadang lambat atau tidak dapat diandalkan, dan melibatkan banyak sirkuit baru dan aktivitas jaringan yang dapat dibedakan. Ini juga berarti kita dapat meminta nama host .onion yang sama, yang mencegah rekan-rekan untuk dapat memaksa koneksi ke .onion sewenang-wenang.

Jika server selalu berjalan, kontak dan non-kontak dapat ditemukan kapan saja, meskipun hal ini tidak berarti apa-apa. Jika server hanya aktif saat ada penawaran file aktif, status tersebut mungkin dapat dideteksi oleh kontak atau non-kontak yang dapat mempelajari port tersebut.

Tidak ada gunanya atau perlu mencoba menyamar sebagai apa pun selain klien Ricochet. Semua permintaan yang dibuat dengan baik yang bukan permintaan file yang valid harus ditolak dengan kesalahan 404 umum.

Saya mengusulkan yang berikut untuk URL unduhan:

http://[address].onion:[port]/ricochet/fetch/[uniqid]/[filename]

[address] must be the contact's ricochet connection address
[uniqid] is a large (>=128bit) random identifier
[filename] is the URL-encoded original name of the file

Only HTTP is permitted, no HTTPS. We do not want to require a TLS
implementation, and .onion makes it unnecessary.

Clients may refuse transfer URLs without a /ricochet/fetch/ prefix.

URL file terkait dengan transfer tertentu dan dimaksudkan untuk satu kali penggunaan. Permintaan rentang harus didukung untuk memungkinkan melanjutkan, dan mungkin diizinkan untuk mengunduh paralel. Server harus berhenti menawarkan URL setelah mereka yakin penerima memiliki salinan lengkap.

Protokol penawaran file

Kami dapat mengemas penawaran file ke dalam pesan obrolan yang diperluas:

message ChatMessage {
    required string message_text = 1;
    optional uint32 message_id = 2;
    optional int64 time_delta = 3;

    // Indicates a file transfer offer. message_text must begin with a valid
    // file transfer URL, terminated by the first whitespace or end of message.
    // The rest of message_text, if any, should be displayed as a user message
    // along with the file. 
    optional FileInfo file_info = 4;
}

message FileInfo {
    // required
    optional string file_name = 1;
    optional uint64 file_size = 2;
    // optional
    optional string content_type = 3;
}

message ChatAcknowledge {
    optional uint32 message_id = 1;
    optional bool accepted = 2 [default = true];
    optional bool file_received = 3;
    optional bool file_refused = 4;
}

Pengakuan pesan ini juga mengakui tawaran file. URL dapat segera diakses untuk mengunduh file. Selain mengakui pesan secara normal, penerima harus mengirim tambahan ChatAcknowledge ketika transfer telah selesai atau jika ditolak, dengan bidang yang sesuai. Pengirim harus siap untuk mempertimbangkan transfer yang diselesaikan hanya berdasarkan data yang ditransfer dan tidak bergantung pada ChatAcknowledge , untuk mendukung klien lama atau pengunduh alternatif.

Ini memiliki properti rapi yang sepenuhnya kompatibel dengan klien yang tidak menerapkan transfer file; pengguna akan melihat URL, dan dapat mengunduhnya di browser. Ini tidak terlalu berarti, meskipun.

XXX Tidak ada cara yang ditentukan di sini bagi pengirim untuk menunjukkan pembatalan

Langkah selanjutnya

Saya ingin melanjutkan ini dengan cukup cepat, jadi saya akan bertujuan untuk menetapkan protokol dan keputusan UX utama segera.

Sudah ada sebagian besar kode yang ditulis, tetapi perlu beberapa perbaikan dan akan membutuhkan perubahan berdasarkan keputusan di sini.

Ada pikiran?

Ini terlihat bagus bagi saya. Saya setuju bahwa arah server HTTP terasa seperti yang benar.

Beberapa pemikiran - tanpa urutan atau prioritas tertentu:

• Tanpa otentikasi klien pada unduhan, apakah ada vektor serangan yang perlu diperhatikan? Saya tidak bisa memikirkan apa pun yang akan menjadi penting untuk model ancaman ... tetapi sebagai catatan, berikut adalah beberapa hal yang terlintas dalam pikiran saya:
  
  
  
  • Apakah ada potensi serangan tipe DoS/slowloris di mana penyerang mendapatkan korban untuk menyajikan file dan kemudian penyerang itu sendiri, atau dengan banyak orang yang semuanya membuka dan mengisi kumpulan koneksi?
  
  
  • Apakah ada serangan atribusi di mana penyerang meminta seseorang untuk menyajikan file dan mereka kemudian dapat membuktikan kepada orang lain bahwa mereka melakukannya?
  
  
• Nama File & Jenis Konten cenderung rentan terhadap masalah unicode yang sama yang diidentifikasi di #338
• Klien harus menolak Pengalihan HTTP dan upaya lain untuk membajak aliran HTTP.
• Saya pikir saya akan berpendapat bahwa URL yang tidak valid seharusnya memicu penutupan koneksi, daripada 404.

Ini memiliki properti rapi yang sepenuhnya kompatibel dengan klien yang tidak menerapkan transfer file; pengguna akan melihat URL, dan dapat mengunduhnya di browser.

• Ini membuka beberapa vektor serangan yang disebutkan di atas yang dapat dihindari oleh klien http yang memantul, tetapi browser tidak bisa. Sudah ada peringatan tentang membuka tautan, tetapi saya ingin tahu apakah pengiriman pesan dan status fitur yang didukung dari transfer file mungkin membuka celah untuk phishing.

• Tanpa otentikasi klien pada unduhan, apakah ada vektor serangan yang perlu diperhatikan? Saya tidak bisa memikirkan apa pun yang akan menjadi penting untuk model ancaman ... tetapi sebagai catatan, berikut adalah beberapa hal yang terlintas dalam pikiran saya:

Nah, ada otentikasi dengan menggunakan URL unik untuk penerima dan file. Kekhawatirannya adalah bahwa itu dapat ditransfer: otentikasi ini tidak mengidentifikasi penerima kepada siapa pun selain pengirim (dan itu secara non-kriptografis), dan tidak mengandung rahasia apa pun yang mungkin ingin dilindungi oleh penerima.

• Apakah ada potensi serangan tipe DoS/slowloris di mana penyerang mendapatkan korban untuk menyajikan file dan kemudian penyerang itu sendiri, atau dengan banyak orang yang semuanya membuka dan mengisi kumpulan koneksi?

Saya pikir tidak ada opsi DoS, selama kami membatasi jumlah koneksi per file yang ditawarkan. Karena tujuannya adalah untuk berbagi satu file dengan satu orang satu kali (memungkinkan resume dan masalah lainnya), kami dapat bersikap tegas tentang hal itu. Ini juga bisa menjadi ide yang baik untuk mengatur kecepatan transfer minimum, untuk kegunaan juga.

• Apakah ada serangan atribusi di mana penyerang meminta seseorang untuk menyajikan file dan mereka kemudian dapat membuktikan kepada orang lain bahwa mereka melakukannya?

Menarik! Saya suka serangan ini. Ada pertahanan yang lemah dengan mengubah otentikasi klien, tetapi mereka benar-benar hanya mencegah berbagi URL. Saya juga suka jika URL ini tidak mengidentifikasi penerima yang dituju selain dari pengirim yang membuatnya.

Untuk benar-benar menghapus atribusi kriptografi, kita harus menyajikan file pada layanan ephemeral. Saya tidak yakin apakah itu juga memerlukan satu layanan singkat per _contact_. Secara teknis, Bob dapat meyakinkan Alice untuk mengirim file berbahaya, Bob membagikan alamatnya dengan Carol, dan kemudian Carol secara terpisah dapat meminta Alice untuk mengirim file berbahaya, sehingga Carol dapat mengonfirmasi bahwa URL berbahaya tersebut berasal dari Alice.

Jawaban teraman dari segi atribusi adalah dengan menggunakan layanan singkat yang unik per kontak per sesi. Kekhawatiran saya dengan ini adalah 1) latensi publikasi layanan; 2) _many_ lebih banyak sirkuit yang dibutuhkan; 3) muncul lebih jelas untuk analisis lalu lintas.

Saya pikir saya mungkin baik-baik saja dengan menggunakan satu layanan singkat untuk semua transfer file dalam satu sesi. Setidaknya masih berbeda secara kriptografis, mengurangi semua dampak itu, dan kasus di mana ia gagal dibuat-buat.

• Nama File & Jenis Konten cenderung rentan terhadap masalah unicode yang sama yang diidentifikasi di #338

Jenis konten adalah jenis MIME, jadi tidak ada masalah unicode di sana. Untuk membersihkan nama file, saya telah membuat beberapa aturan sejak lama, yang membutuhkan pemikiran lebih lanjut. Harus sangat berhati-hati di sana.

• Klien harus menolak Pengalihan HTTP dan upaya lain untuk membajak aliran HTTP.

Setuju.

• Saya pikir saya akan berpendapat bahwa URL yang tidak valid seharusnya memicu penutupan koneksi, daripada 404.

Tanpa respon apapun? Hmm. Ini membuatnya sedikit lebih ambigu bagi klien yang memantul untuk mengetahui apakah ada kegagalan jaringan atau jika URL tidak lagi valid. Kalau tidak, saya tidak punya masalah dengan itu, dan saya tidak ingin mengirim apa pun kembali ke klien yang tidak sah.

Ini memiliki properti rapi yang sepenuhnya kompatibel dengan klien yang tidak menerapkan transfer file; pengguna akan melihat URL, dan dapat mengunduhnya di browser.

• Ini membuka beberapa vektor serangan yang disebutkan di atas yang dapat dihindari oleh klien http yang memantul, tetapi browser tidak bisa. Sudah ada peringatan tentang membuka tautan, tetapi saya ingin tahu apakah pengiriman pesan dan status fitur yang didukung dari transfer file mungkin membuka celah untuk phishing.

Tindakan pencegahan di sini harus sama seperti untuk membuka URL apa pun. Saya tidak berpikir ini adalah kasus penggunaan yang layak untuk dirancang -- Saya tidak yakin itu akan tetap digunakan.

Tidak jelas implementasi C++/Qt apa yang cukup aman untuk digunakan

Mungkin sudah terlalu besar untuk kasus penggunaan ini, tetapi ditulis dengan mempertimbangkan keamanan: https://github.com/reyk/httpd

message FileInfo {
    // required
    optional string file_name = 1;
    optional uint64 file_size = 2;
    // optional
    optional string content_type = 3;
}

Saya ingin tahu mengapa Anda ingin menyimpan tipe konten tambahan selain dari ekstensi nama file yang terlihat oleh pengguna? Mungkinkah hal itu menyebabkan kebingungan di sisi penerima baik secara teknis di program mana yang akan dimulai, atau secara non-teknis dalam apa yang diharapkan pengguna?

XXX Tidak ada cara yang ditentukan di sini bagi pengirim untuk menunjukkan pembatalan

Bukankah flag bool file_refused dalam pesan ChatAcknowledge merupakan cara untuk melakukannya? Atau maksudnya setelah file sudah diterima dan saat di tengah transfer?

Saya pikir saya akan berpendapat bahwa URL yang tidak valid seharusnya memicu penutupan koneksi, daripada 404.

👍

Menarik! Saya suka serangan ini. Ada pertahanan yang lemah dengan mengubah otentikasi klien, tetapi mereka benar-benar hanya mencegah berbagi URL. Saya juga suka jika URL ini tidak mengidentifikasi penerima yang dituju selain dari pengirim yang membuatnya.

Dengan mengorbankan kompatibilitas klien, apakah layak untuk mengenkripsi konten file dengan kunci publik penerima atau semacam id sesi?

Saya ingin tahu mengapa Anda ingin menyimpan tipe konten tambahan selain dari ekstensi nama file yang terlihat oleh pengguna? Mungkinkah hal itu menyebabkan kebingungan di sisi penerima baik secara teknis di program mana yang akan dimulai, atau secara non-teknis dalam apa yang diharapkan pengguna?

Hmm. Saya memiliki dua kegunaan dalam pikiran:

1. Saat kami menerapkan gambar sebaris, kami memerlukan cara untuk mengetahui file apa yang merupakan gambar
2. Mungkin menyenangkan dapat menampilkan ikon yang berbeda untuk beberapa jenis file (gambar/, video/, dll)

Mendeteksi ini berdasarkan ekstensi setidaknya sama tidak andalnya dengan memiliki tipe konten (mungkin salah). Anda benar bahwa perlu kehati-hatian pada #2 untuk memastikan bahwa kami tidak menampilkan sesuatu sebagai gambar ketika itu benar-benar akan terbuka sebagai executable. Untuk alasan itu saja, mungkin lebih baik untuk menghapus tipe konten dan hanya mendeteksi dengan ekstensi. Hmm..

XXX Tidak ada cara yang ditentukan di sini bagi pengirim untuk menunjukkan pembatalan

Bukankah tanda bool file_refused dalam pesan ChatAcknowledge merupakan cara untuk melakukannya? Atau maksudnya setelah file sudah diterima dan saat di tengah transfer?

Mengirim ChatAcknowledge hanya valid untuk pesan yang Anda terima -- tidak masuk akal untuk mengakui pesan Anda sendiri. Jadi file_refused menyediakan cara bagi penerima untuk membatalkan, tetapi saya belum mendefinisikan padanan untuk pengirim untuk mengatakan "Saya tidak menawarkan file ini lagi".

Dengan mengorbankan kompatibilitas klien, apakah layak untuk mengenkripsi konten file dengan kunci publik penerima atau semacam id sesi?

Mengenkripsi file tidak menyelesaikan serangan atribusi @s-rah: itu hanya berarti Anda perlu memberikan kunci dekripsi bersama dengan URL. Cara umum mengenkripsi ke kunci publik penerima memiliki masalah yang sama, karena Anda biasanya hanya membungkus kunci enkripsi simetris yang digunakan untuk data file.

Akan lebih berguna untuk meminta penerima menyerahkan kunci pribadi identitasnya untuk menunjukkan bahwa pengirim menawarkan file. Untuk itu, kita hanya perlu mengautentikasi koneksi dengan kunci publik penerima sebelum menyajikan file -- tetapi ini tidak memetakan dengan baik ke HTTP (tidak, tanpa TLS). Itu akan menjadi poin yang mendukung penggunaan protokol lain.

Pendekatan yang sama sekali berbeda adalah membuat penerima meng-host server, dengan pengirim bertindak sebagai klien untuk mengunggah data. Ini bisa bekerja dengan HTTP atau apa pun, tetapi memiliki beberapa kelemahan dalam fleksibilitas. Tidak akan ada masalah atribusi dalam kasus itu.

Saat kami menerapkan gambar sebaris, kami memerlukan cara untuk mengetahui file apa yang merupakan gambar

Saya ingin menyatakan bahwa saya sangat setuju dengan pernyataan Anda sebelumnya: I don't trust image decoders .

tidak masuk akal untuk mengakui pesan Anda sendiri.

Buruk saya, saya membaca "penerima" padahal sebenarnya menyatakan "pengirim" :)

Akan lebih berguna untuk meminta penerima menyerahkan kunci pribadi identitasnya untuk menunjukkan bahwa pengirim menawarkan file. Untuk itu, kita hanya perlu mengautentikasi koneksi dengan kunci publik penerima sebelum menyajikan file -- tetapi ini tidak memetakan dengan baik ke HTTP (tidak, tanpa TLS).

Kedengarannya menarik, Anda punya contoh protokol lain yang melakukan ini? Atau bagaimana itu bisa diatur? Saya kira kerangka kerja Kebisingan dapat membantu di sini seperti yang tercantum di https://github.com/ricochet-im/ricochet/issues/72#issuecomment -258894126 .

Jika ada yang membutuhkan ini secepatnya, maka Anda harus menggunakan onionshare bersama dengan ricochet.

-----MULAI PESAN YANG DITANDATANGANI PGP-----
Hash: SHA512

John Brooks:

Hanya HTTP yang diizinkan, tidak ada HTTPS. Kami tidak ingin memerlukan TLS
implementasi, dan .onion membuatnya tidak perlu.

Tidak jelas bagi saya apakah ini bagian dari model ancaman Ricochet,
tetapi di lingkungan seperti Whonix, klien Tor dapat membaca konten
lalu lintas .onion tetapi bukan lalu lintas TLS (karena TLS didekripsi dalam a
VM yang berbeda).
-----MULAI TANDA TANGAN PGP-----

iQIcBAEBCgAGBQJYKlGYAAoJELPy0WV4bWVwu/gQAI/7bmPTKwbcsjEntuEjc03j
nQFKDvSMg05FXR9rljFym5E++pr1FEteKb2qAu0Gub9CbkxCWhibBYNQHi1aFgy5
wgO07yom0oJI4JxBXA185TNSJKE7+LnDAqUCT0H1d0yCy5t4TZfFQHJFLdhOjdk+
GD+Lbuv3pH0GIInsK7iAFQlps0bQmI8aNrNAgoiuk3iWI9MqGFZ8BoXZlabMeGnF
O0OeaibMjtvtuvX4mRsgTFZdNzzUmSfmkoYsABHDK/He4rcnUg6LUetVz16YKzuo
i5Oxy+dQZ6FHHICsQq2Ajg35LfW95I27jcm0QBGFZ08tu3Igt7DFqw9Sq1Ydg5Hl
J/HckRIA5pIJJUcOUa4ynFyk2t/hA0fQEjSoy9C66GnH4Fzt6X/Izs0CDkPkZOQ/
+Vo7wYkqyKcInn2uu7sb62lopX7L6QKHMORRiO/5echUMCNCs5fVx7pDenIKvXew
88QcZ/UkR48N9RdKaNC+UdCt3a/vJzQhbzB65cgGuPtvJLhUPFay2IK/szP0/Drw
gPXT+kwbCcBKqbmzkniPysn0Z62wXOlZAfiI/BJ5TqbqILNlhyR9HFSb9MIImiNL
Es+Q3vteUEm6pGVGPnqMZMm2dxVYmP5xx3pHhqq7GjaeGplNEi0ZwTsmSpfCztPB
Y6ksrSAXNDadT0ijrXfu
=TeTg
-----AKHIR TANDA TANGAN PGP-----

Solusi yang mungkin : Setidaknya di Windows dan Linux ada gpg4usb (gpg4usb.org), program GPG mandiri yang menyimpan semua file yang dienkripsi sebagai file teks:

Antarmuka:

Output (buka _data.docx.asc_ di notepad):

Jebakan:

• Memotong? Saya mengirim beberapa bit teks yang SANGAT panjang melalui Ricochet tetapi saya dapat membayangkannya memotongnya di beberapa titik. Mungkin perlu mengirim file dalam potongan.
• File sedikit lebih besar dari aslinya (enkripsi meningkatkan ukuran dan teks kurang efisien daripada biner)
• Hanya sedikit orang yang menggunakan GPG (tidak termasuk @JeremyRand di atas) sehingga beberapa waktu akan menjelaskan cara kerjanya, bertukar kunci, dll.

Pembaruan: Program ini menggunakan versi GPG yang kedaluwarsa, jadi meskipun kemungkinan masih berfungsi sebagai solusi, program ini mungkin tidak berfungsi dengan alat lain yang kompatibel dengan GPG yang baru saja diperbarui.

1) Fitur transfer file sangat penting dalam lingkungan kerja yang nyata. Untuk alasan pekerjaan, saya sering mobile dan harus bertukar pesan dan file dengan rekan kerja (jarang gambar, kebanyakan .docx, xls dan jenis file lainnya). Tentu saja kita perlu memastikan ini bergerak di saluran yang aman dan TERSEDIA.
Sangatlah penting (n.1) bahwa file tidak dapat dicegat atau diambil oleh orang lain selain penerima yang dimaksud.
Jadi saya jelas dan sepenuhnya menentang penggunaan URL publik (bahkan jika diacak atau semacamnya) yang terlihat dengan cara apa pun, atau mudah diturunkan (dan dapat ditransfer ke orang lain). Konten percakapan, serta file harus tetap sangat pribadi antara pengirim dan penerima (P2P murni dan tidak berbagi sama sekali).
Jenis "serangan" yang harus Anda pertimbangkan jika menggunakan URL 'publik' berasal dari penerima itu sendiri.

Pikirkan seorang karyawan yang tidak terlalu setia mengetahui mekanisme ini dan meneruskan saluran yang berbeda (bahkan mungkin obrolan IM Ricochet kedua tanpa meninggalkan jejak apa pun...) URL ke pihak ketiga segera setelah dia menerimanya... Pihak ketiga mengunduh file, karyawan mengunduhnya juga dan berpura-pura tidak melakukan kesalahan... Dalam sistem tanpa tautan publik/terlihat/dapat disalin, di mana satu-satunya pilihan yang dia terima di jendela obrolan adalah mengunduh file ke PC-nya atau menolaknya, dia adalah satu-satunya orang (selain pengirim) yang memiliki akses ke file itu dan jika bocor, maka tidak ada alasan untuk itu karena 'URL http publik....

2) Sudahkah Anda melihat solusi obrolan lain yang menawarkan transfer file P2P untuk mendapatkan ide tentang sesuatu yang sudah berfungsi?
Sambil menunggu opsi ini muncul, kami menggunakan di bidang QTox dan memiliki opsi transfer file yang berfungsi dan bagus yang sepenuhnya tertanam di dalam obrolan.
(di masa lalu saya juga menggunakan uVNC dan itu melakukan transfer file dengan mudah melalui terowongan aman p2p)

3) firasat gaya lama saya adalah membuang ide protokol http dan mulai mengerjakan paket file yang efisien ke dalam protokol ricochet yang sudah diaudit, aman, dan tepercaya (dengan modifikasi kecil yang diperlukan dan mungkin lapisan tambahan opsional dari enkripsi sederhana) , seperti yang dijelaskan dalam opsi pertama Anda.
Bahkan hanya dengan membungkus file dengan Mime64+a lite scrambling (dan melakukan sebaliknya pada penerimaan) sudah cukup sebagai pembungkus.
Saya lebih suka keamanan dan kepastian tidak ada risiko file saya jatuh ke tangan pesaing daripada mekanisme transfer yang lebih menarik dan/atau lebih cepat.

4) Jangan lupa kebanyakan orang masih menggunakan email (MIME-64 encoding unencrypted dari file lampiran) untuk mengirim file sekitar... lambat, tidak efisien dan jelas tidak aman.
Kecepatan tertinggi bukanlah bagian penting dari transfer di lingkungan seluler dunia nyata (dan beberapa koneksi seluler yang digunakan dari jarak jauh bahkan tidak mampu mendukung kecepatan tinggi...).
Bagi saya, lebih penting bahwa saya memiliki indikator status transfer ke rekan-rekan saya, untuk memiliki kemungkinan untuk 'menjeda/melanjutkan' pengiriman file yang panjang dan memiliki mekanisme penanganan koneksi yang hilang (yang sering terjadi pada lapangan) dengan transfer yang sedang berlangsung.

Ada aplikasi berbagi file berbasis Tor Hidden Service yang kecil dan ringan bernama Onionize oleh @nogoest (ditulis dalam bahasa Golang).

Saya ingin tahu apakah ada kemungkinan membuat keturunan berbagi file IM + yang bagus;)