<div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>Thanks for all the answers and pointers.<br><br></div>I would like to add some further remarks to my initial question, based on the feedback I got.<br><br></div>I - Design priorities of the system, by decreasing order of importance:<br><br></div><div>1) simplicity (the system is minimalist)<br></div><div>2) speed (the system should be high performance, despite being data intensive)<br></div><div>3) security (if a user choose to encrypt his data, we won't leak them out)<br></div><div><br></div>Interesting article I could find before asking to the list:<br><br></div><div>"On Breaking a Huffman Code"<br></div><div><a href="https://people.csail.mit.edu/rivest/pubs/GMR96.pdf" target="_blank">https://people.csail.mit.edu/rivest/pubs/GMR96.pdf</a><br><br></div><div>So, I was wondering if people did further work in the opposite direction:<br></div><div>design a generic compressor that makes it extremely hard to recover<br></div><div>the data if you don't have access to the Huffman tree (for example).<br></div><br></div>II - Compatibility between executables of the system:<br><br></div><div>there won't be bits in message headers to change the protocol.<br></div><div>I plan to enforce at compile time that the executables of the system<br></div><div>speak a compatible protocol.<br></div><div>The protocol will be:<br></div><div>- either you speak plain text<br></div><div>- either you speak compressed text<br></div><div>  but because of the speed constraint I will support some specific compression algorithms<br></div><div>  like LZ4 or snappy, not bzip2 or xz<br></div><div>- optionally you can sign your message before sending it<br></div><div>- optionally you can encrypt your message before sending it (in that order)<br><br></div><div>I plan the signing key and the encryption key to be two different keys (they are secrets<br></div><div>shared by all members of the distributed system).<br></div><div><br></div><div>If I don't find an established algorithm providing both compression and encryption<br></div><div>at high speed on general data (there is no assumption on what users will transport),<br>then I won't provide one in the system.<br></div><div>I will encrypt the full output of compression (if compression is enabled).<br><br></div><div>I don't care so much about traffic analyzis or message lengths being disclosed.<br></div><div>I just want the user data to be safe, if he chose so.<br></div><div>I won't send dummy traffic, for example, because of the high performance constraint.<br><br></div><div>I expect the users will be computational scientists.<br></div><div>Before publication, it is nice to not disclose your data, so I should provide<br></div><div>the functionality of encryption.<br></div><div><br></div>Regards,<br></div>Francois.<div class="gmail_extra"><br></div></div>