Kompres dan kemudian enkripsi, atau sebaliknya?

88

Saya menulis sistem VPN yang mengenkripsi (AES256) lalu lintasnya di internet (Mengapa menulis sendiri ketika ada 1.000.001 orang lain di luar sana? Nah, tambang adalah yang khusus untuk tugas tertentu yang tidak ada yang cocok).

Pada dasarnya saya ingin menjalankan pemikiran saya melewati Anda untuk memastikan saya melakukan ini dalam urutan yang benar.

Saat ini paket hanya dienkripsi sebelum dikirim keluar, tetapi saya ingin menambahkan beberapa tingkat kompresi untuk mengoptimalkan sedikit tranfer data. Bukan kompresi yang berat - Saya tidak ingin memaksimalkan CPU setiap saat, tetapi saya ingin memastikan kompresi akan seefisien mungkin.

Jadi, pemikiran saya adalah, saya harus mengompres paket sebelum mengenkripsi karena paket yang tidak terenkripsi akan dikompres lebih baik daripada yang dienkripsi? Atau sebaliknya?

Saya mungkin akan menggunakan zlib untuk kompresi.

Baca lebih lanjut di blog Pengguna Super .

encryption compression

— Majenko
sumber

4

Menulis sebagai "pemrograman"? Akan lebih cocok untuk Stack Overflow.

— Suma

4

Jika saya bertanya tentang pemrogramannya, ya, tapi saya tidak. Ini adalah kompres umum kemudian mengenkripsi atau mengenkripsi kemudian kompres pertanyaan yang dapat diterapkan untuk hanya bekerja dengan file biasa jika Anda inginkan. Sisi pemrograman hanyalah konteks mengapa saya mengajukan pertanyaan.

— Majenko

Lihat juga: stackoverflow.com/questions/4676095 stackoverflow.com/questions/4399812

— BlueRaja - Danny Pflughoeft

Mungkin pertanyaan terbaik untuk security.stackexchange.com

— Jeff Ferland

1

Mereka tahu tentang kompresi di sana, kan?

— Majenko

176

Jika enkripsi dilakukan dengan benar maka hasilnya pada dasarnya adalah data acak. Sebagian besar skema kompresi bekerja dengan menemukan pola dalam data Anda yang dapat difaktorkan, dan berkat enkripsi sekarang tidak ada; data benar-benar tidak bisa dimampatkan.

Kompres sebelum Anda mengenkripsi.

— Tuan Alpha
sumber

41

Lebih penting: kompresi menambah entropi. Menambahkan entropi baik untuk enkripsi Anda (lebih sulit untuk diatasi dengan serangan plaintext yang dikenal).

— Olli

8

Juga, mengenkripsi sumber daya biaya, mengenkripsi file yang lebih kecil akan membutuhkan lebih sedikit sumber daya. Jadi kompres sebelum dienkripsi.

— GAT Diambil

9

@ Olli - belum tentu jika skema kompresi menambahkan teks yang dikenal. Dalam kasus terburuk bayangkan jika meletakkan header 512byte yang diketahui di bagian depan data dan Anda menggunakan enkripsi mode blok.

— Martin Beckett

26

Saya tidak yakin mengapa komentar @ Olli akan terangkat, karena itu salah; tidak hanya itu secara signifikan kurang penting, untuk enkripsi setengah layak pun seharusnya tidak penting sama sekali . Artinya, kekuatan enkripsi harus sama sekali tidak terkait dengan entropi pesan.

— BlueRaja - Danny Pflughoeft

8

Jika Anda mengompres sama sekali, itu hanya dapat benar-benar dilakukan sebelum mengenkripsi pesan, tetapi ingatlah, ini dapat membocorkan informasi tentang 'kompresibilitas' dari pesan asli, jadi Anda akan ingin mempertimbangkan apakah ada konsekuensi pada sisi ini saluran. Pertimbangkan file berukuran tetap yang semuanya 0s atau pesan. Semua file 0 akan menghasilkan payload yang lebih kecil di bawah skema kompresi yang masuk akal. Namun sepertinya tidak akan ada masalah dalam kasus penggunaan khusus ini.

— Edward KMETT

22

Kompres sebelum enkripsi. Data terkompresi dapat sangat bervariasi untuk perubahan kecil dalam data sumber, sehingga membuatnya sangat sulit untuk melakukan pembacaan sandi diferensial.

Juga, seperti yang ditunjukkan oleh Mr.Alpha, jika Anda mengenkripsi dulu, hasilnya sangat sulit untuk dikompres.

— Juancho
sumber

12

Baiklah, ini benar, tetapi telah diposting 2 jam sebelum Anda memposting ... Entropy

— Konerak

3

Bahkan jika itu tergantung pada kasus penggunaan khusus, saya akan menyarankan Encrypt-then-Compress. Kalau tidak, seorang penyerang bisa membocorkan informasi dari jumlah blok terenkripsi.

Kami berasumsi pengguna mengirim pesan ke server dan penyerang dengan kemungkinan untuk menambahkan teks ke pesan pengguna sebelum mengirim (via javascript misalnya). Pengguna ingin mengirim beberapa data masuk akal ke server dan penyerang ingin mendapatkan data ini. Jadi dia bisa mencoba menambahkan pesan berbeda ke data yang dikirim pengguna ke server. Kemudian pengguna memampatkan pesannya dan teks yang ditambahkan dari penyerang. Kami menganggap kompresi DEFLATE LZ77, sehingga fungsinya mengganti informasi yang sama dengan pointer ke tampilan pertama. Jadi jika penyerang dapat mereproduksi lubang teks, fungsi kompresi mengurangi ukuran teks biasa ke ukuran asli dan pointer. Dan setelah enkripsi, penyerang dapat menghitung jumlah blok sandi, sehingga ia dapat melihat, apakah data yang ditambahkannya sama dengan data yang dikirim pengguna ke server. Bahkan jika kasus ini kedengarannya sedikit dibangun, itu adalah masalah keamanan yang serius di TLS. Ide ini digunakan oleh serangan yang disebut CRIME untuk membocorkan cookie dalam koneksi TLS untuk mencuri sesi.

sumber: http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf

— Tobias Braun
sumber

2

Pandangan saya adalah bahwa ketika Anda mengompres pesan, Anda memproyeksikannya ke dimensi yang lebih rendah dan karenanya ada lebih sedikit bit, yang berarti bahwa pesan terkompresi (dengan anggapan kompresi lossless) memiliki informasi yang sama dalam bit yang lebih sedikit (yang Anda hilangkan adalah mubazir! ) Jadi Anda memiliki lebih banyak informasi per bit dan akibatnya lebih banyak entropi per bit, tetapi total entropi yang sama seperti yang Anda miliki sebelumnya ketika pesan tidak dikompresi. Sekarang, keacakan adalah masalah lain dan di situlah pola dalam kompresi dapat melempar kunci pas monyet.

— Prof.
sumber

1

Kompresi harus dilakukan sebelum enkripsi. seorang pengguna tidak ingin menghabiskan waktu menunggu transfer data, tetapi ia membutuhkannya untuk segera dilakukan tanpa membuang waktu.

— sqlchild
sumber

1

Kompresi sebelum enkripsi seperti yang telah ditunjukkan sebelumnya. Kompresi mencari struktur yang dapat dikompres. Enkripsi mengacak data untuk menghindari struktur yang terdeteksi. Dengan mengompresi terlebih dahulu, Anda jauh lebih mungkin memiliki file yang lebih kecil dan dengan demikian lebih sedikit payload untuk ditransfer. Enkripsi akan melakukan pekerjaannya terlepas dari apakah itu dikompresi atau tidak dan, sekali lagi seperti yang ditunjukkan sebelumnya, kemungkinan akan lebih sulit untuk melakukan pembacaan sandi diferensial pada file terkompresi.

— Selalu belajar
sumber

Ini tampaknya merupakan pengulangan dari jawaban yang diterima dan yang kedua. Setiap jawaban harus menyumbangkan solusi baru yang substantif untuk pertanyaan itu.

— fixer1234

0

Kompresi mengurangi entropi informasi. Kompresi maksimum membuat entropi minimum. Untuk data yang dienkripsi sempurna (noise), maksimum dan minimum entropi adalah sama.

— AbiusX
sumber

2

Tunggu, bukankah kamu memiliki itu mundur? Saya pikir entropi meningkat ketika redundansi menurun. Oleh karena itu kompresi harus meningkatkan entropi.

— Zan Lynx

Tidak, kurang entropi = lebih banyak pola. Keacakan memiliki sebagian besar entropi.

— AbiusX

1

Tetapi ini adalah entropi informasi, jadi ini semua tentang makna. Keacakan tidak berarti apa-apa sehingga tidak berlaku. Sebuah kalimat bahasa Inggris dapat memiliki huruf yang diubah dan masih berarti hal yang sama sehingga memiliki entropi yang rendah. Kalimat bahasa Inggris terkompresi mungkin tidak dapat dibaca jika sedikit perubahan sehingga memiliki paling banyak. Atau begitulah menurut saya.

— Zan Lynx

Entropi bukan tentang akal dan kemampuan untuk membaca atau memahami, semua tentang pola. File terkompresi penuh dengan pola.

— AbiusX

1

@ AmusX: Benar. Pola. Dan semakin sedikit polanya, semakin banyak entropi. Yang berarti bahwa kompresi yang menggantikan semua pola berulang dengan satu salinan meningkatkan entropi.

— Zan Lynx