Hi Michael,

I tried to address each of your questions one after another below. As a general remark, this 1.0.5 is an alpha version, some things will be changed in the upcoming updates, including those that harden the code.

An attacker may want to get individual files saved in the store for any reason. Some of them are explained in the Guide and on the website:

"Just encrypting the file content and its name, without preventing its identification, still jeopardizes security. In case the attacker gets a hold on the ciphertext, they might succeed in decrypting the ciphertext. Alternatively, they might blackmail the data owner despite being unable to decrypt the data. Also, encryption methods considered safe today might become unsafe tomorrow because of the progress in the deciphering techniques. In some cases, the attacker may apply unlimited computing resources thus succeeding in a brute force attack. Ultimately, the attacker may possess a secret algorithm that deciphers the seemingly impregnable encryption scheme. Therefore, having the attacker being able to identify the encrypted data is potentially as dangerous as having the attacker succeeding in stealing cleartext or deciphering encrypted data."

Cryptomove data passwords are usually not kept in memory but only used to generate symmetric encryption keys. The data keys are used only once on the client -- for encryption and decryption, and then discarded unless the client works in 'trust' mode where it does keep the keys in the client memory for each next get/put operation, until the time the user switches the trust mode off. When the trust is off, the user must enter the password(s) for each next get/put kind of operation.

Each server keeps its server password in memory. Currently, that virtual memory is swappable, but in the next version (coming very soon) the key will be stored in the locked physical memory. In addition, plans exist to make sure the daemons are not dumpable or amenable to ptrace() calls (to prevent debuggers and other processes to peek inside). As I have said before, this is an alpha version -- the very first proof of concept, although we are aware of numerous enhancements that must still be applied.

Hello language has an interface to encrypt its network traffic, but that interface is not used in the current Cryptomove version.

Obviously, in general many different technologies can be used to build the same software. Cryptomove is built using Hello because this language allows for a convenient transfer of bulk and individual data as copy parameters in its remote method calls and return values, because it allows for convenient scheduling on multiple threads and for controlled processing of asynchronous events. Other Hello features used in Cryptomove include native interaction with C++ which allows for reuse any system calls and auxiliary C/C++ libraries.

Cryptomove protects against the attack that attempts to find any number of individual files in the store because even stealing the encrypted data poses a security risk as noted in the above quote. Unlike TRueCrypt, Cryptomove does not work on the disk or partition level, but places data parts inside encrypted files within a file system. Advantage of this approach is that the data store owners can employ any file-based management system or policy to store and manage the data, including distribution data policies between different levels of storage, increasing/decreasing store capacity, providing online backup/restore, etc.

Thank you very much for your kind words -- we really tried very hard for this first alpha release to be useful in tryouts. More things are still to come, including those I spelled out above, others mentioned in http://cryptomove.com/news/.

Regarding your last comments about Hello. There are a lot of examples of Hello programs in the Hello User Guide and on the website itself (http://www.amsdec.com/documentation/). The white paper at http://www.amsdec.com/wp-content/uploads/2015/10/hellowhitep... explains the rationale behind developing Hello and its design goals.

When one embeds a C++ code inside a Hello program, the C++ code has read/write access to the surrounding Hello data. Hello has no spelled out memory management policy, but the current runtime uses ref count. You are correct: if one is not careful, one can ruin memory by unsafe embedded C++ code. Still, Hello can prohibit execution of any portion of the embedded C++ code at runtime, also disable embedding C++ code at translation time in protected packages. It seems many 'safe' systems allow for embedding lower level programming languages, say Java allows native C, C allows assembler, etc. -- Hello is not different in this regard. All of them rely on the programmer being careful with the code at hand.

Hope the above helps to clear at least some of your questions.

Best Regards, Boris.