What About Custom Crypto Implementations and Crypto Algorithm Upgrades?

Not everyone are content with the default cryptography algorithm implementations. I for one think that all public key cryptography algorithms are fundamentally flawed, because

y=encrypt(x) is a reverse function of the

The moment one of them is public, like it is the case with the public key encryption systems, the deriving of the other is only a matter of mathematical ingenuity.

Given that Windows and Mac and probably many other systems can be hacked anyway, the keys/passwords of MaidSafe users can be obtained by intruders, not that much is gained by using a proper, symmetric encryption algorithm. Secondly, the proof of the one-time pad
(due to the 2-links-per-post limit I can not post a proper link, but
h t t p s ://archive.is/Bwnk1 )
says only that a clear-text can not be DERIVED from ciphertext, but the proof does not exclude a solution, where a set of cleartext candidates is generated and assigned a probability or “amount” that each cleartext candidate MIGHT PARTIALLY MATCH with the actual clear-text. The fact that a kill-list contains 20 names in stead of 1 name is not that much of a problem, because in practice the “collateral damage” has always been acceptable.

A solution might be that more security conscious people might want their data to be distributed only to those nodes that use a specific crypto-algorithm, crypto-plugin. A precautionary measure might be to use the MaidSafe only as a non-anonymous distributed storage space, where only pre-encrypted files are uploaded. If MaidSafe is accessed from Tor exit nodes and only pre-encrypted files are stored to the MaidSafe, then the MaidSafe is a really useful application, at least till state/supermafia actors start to abuse the public crypto of the MaidSafe and start to corrupt/delete blobs from the MaidSafe.

A counter-measure might be that a same chunk of data is encrypted with different sets of keys, so that the state/supermafia actors do not know, which ciphertext blobs they have to corrupt/delete to apply censorship. That is to say, simply storing the same ciphertext blob to different nodes in the network is not enough, the blobs must also differ from each other, including from metadata point of view, id est blob size. For example, the GNU Privacy Guide does not hide the size of the cleartext, because otherwise it would have to add a random amount of padding/noise to the cleartext container.

Your thoughts on that?

Thank You.

1 Like

Hi and welcome to the forum.

It seems that a solution to your security concerns is that a file storage APP is written that performs an encryption of your file before storing it in SAFE’s encrypted storage. Job done.

Can you provide a practical solution you think would provide this level of security you want without gutting SAFE’s encryption system. Remember that it is not the nodes that encrypt your data, but your own machine before it is even handed over to the SAFE network.

Kind of yes and no.

I do have my own strength-first-speed-last style of encryption software that is a modification of the one-time-pad ready for download for years, but what I have found out about my software is that it has one critical security flaw: the ciphertext contains an ecryption key ID and each encryption key of the current mmmv_crypt_t1 implementation has only one ID per key. That metadata RUINS ANONYMITY.

The flaw can be fixed easily by generating thousands of ID-s for each key and at the decryption side there should be a key management program that reads the ID-s of all keys to a 2-column-SQLite table that makes it really fast to find the relation:

key_ID -> keyfile_path_on_disk

but that’s about a week of work, probably 2 weeks, may be a month as sub-tasks emerge and I have to fix/upgrade/publish my Kibuvits Ruby Library (KRL) before taking on that task. I’ll probably get the KRL back in line relatively quickly, probably within a month, but, I have to earn a living somehow and unless any of my client projects requires it, that work gets postponed.

Secondly, my encryption algorithm is slow-as-hell not because it is written in Ruby (Ruby certainly contributes to the slowness, but it is not the main reason), but because due to the strength-first-and-all-the-rest-second approach the encryption algorithm totally neglects the memory access ANTIPATTERN, which is that random pieces of the encryption/decryption key are randomly picked from a key that does not fit into the CPU-cache. That kind of memory access pattern makes the algorithm terribly slow regardless of the programming language that it is implemented in. But, the slow-as-hell approach is a conscious choice and it used in the name of security. The slowness itself does not strengthen the encryption algorithm, the slowness is only a side effect, but the random selection of the pieces of the key does reduce the risk that some particular part of the key “wears out” much more than other parts of the key.

A total opposite to the memory access anti-pattern can be found from a string concatenation implementation that can also speed up (10-fold, depending on data) multiplications of integers, because from memory allocation and access point of view

10 * 10 * 10 = 1000

is very similar to string concatenation. That comes very practical, when calculating factorials. Memory access pattern based optimization techniques are programming language agnostic, just like the algorithmic complexity based optimizations are programming language agnostic.

My knowledge of memory access patterns based optimization techniques originates from one of my “previous lives”, when I worked years by writing speed-optimized C++ for image processing/image analysis. My C++ is currently, spring 2017, very rusty, but the fact that the demos are all in interpreted languages, not system programming languages, does not mean that I do not know the system programming side. As a matter of fact I believe that in some cases a smartly written Ruby/PHP/JavaScript/Python can probably outperform C++/C# at the very same datasets. Please do not believe me, please try out the string concatenation Ruby/PHP demos and try to outperform it in C++ with the dumb A+B+C+…+Cn style code. My Ruby/PHP will probably win, if the dataset is “big enough”, just like it is the case with algorithmic complexity.

By the way, You may port the string concat function to Your Rust. The sample implementations of the watershed string concatenation algorithm are umder MIT. You may find that algorithm extremely helpful, when concatenating bitstreams, re-assembling the pieces of files, at the decryption/readout step of the MaidSafe.

From code style point of view the difference is:

//old and naive:

//smarter option that uses the watershed concatenation:
ar<<chunk_1    //inserts chunk_1 to ar

I actually have a Ruby generalization of the watershed concatenation, like “template style code”, which You may use for experimentation. At the old KRL it’s called: x_apply_binary_operator_t1, at class Kibuvits_ix. The watershed concatenation algorithm is useful only, when the concatenation result takes considerably more memory than any of the roughly equally sized concatenatable pieces.

So, coming back to the idea, can I solve it without requiring changes to the MaidSafe: I have an idea, how to alleviate the situation, but it is a matter of philosophy, whether a “Safe” is actually a proper safe that can withstand its main attackers or a “Safe” is only “better-than-the-current-alternatives”. In my opinion the “minimum-viable-product” approach is inappropriate for the case of the MaidSafe project. Actually, I’ve seen the trend of reverting to some “minimum-viable-product” also at other projects, interestingly often in the case of projects that are mainly developed by Americans or Brits. For example, the GNU Net seems to take a kind of sloppy approach, which I summarize as: “The small hashes will (have to) do, because user comfort trumps the resilience to state actors.” It seems to me that it really is a culture thing: which is more important, happiness of users and end user comfort or the fact that the device/product/software really does the job even if user comfort is brought as a victim to the technical strengths of the product. It is a fact that remembering and writing/entering passwords/pins is an uncomfortable burden, but bank cards just would not work without that burden, as is also the case with all online accounts, with the exception of ssh-key based systems, which just have a different kind of burden in the form of setting up the ssh keys.

Thank You for reading my comment.

P.S. It’s not for me to say, how others should do their software development. Just like everybody, I also have subjective opinions.