♦ AES/SHA-based file synchronizer for cloud transfers and remote storage, cryptographic and transport modules are separate ♦
Sic ego nec sine te,
There's an answer and it's hidden well
From time to time the files accumulate on your drive, the ones you don't need there right now, but wish to save for a future — somewhere.
Perhaps they are of private value, the islands in the sea of memoirs sheltering the bleeding pieces of your heart. Or maybe someone is going to inspect the drive and you don't want them to detect such files (in that case you have to wipe the data, not just delete). Once in a while you simply need some free space. It is possible that the reasons mentioned act in combination.
Thus you use another medium, which may be of various nature, but the common thing is that no one else should be able to read the original content of your files. While this assumption doesn't always hold, the following presupposes it as a question of privacy.
Certain sorts of the mediums provide the privacy almost for free: you copy the files to another drive or disk and conceal it in a hiding place, from the hollow in the wall to the box buried in the ground. In doing so, the data remains the same, and the source of privacy is the indefiniteness of its location. But the walls may collapse, and the boxes are easy to find with metal detector.
Today, though, the prevailing solution is to use the remote storages accessible from almost anywhere on the planet: the clouds. On the one hand, the reliable and stable cloud rids you of the concerns about the intactness of the medium (shifted onto the cloud owners); on the other hand, there are doubts about the privacy (heightened by recent events and revelations), — nothing prevents the cloud owners from examination of your data and/or passing it on to the ones interested in (special services and data miners included).
And you've read about the encryption. The question is how to apply it (and how it should not be applied). There are cloud services with built-in encryption support, third-party applications to create encrypted folders on your drive synchronized with the original ones (the encrypted twins are synced with a cloud then), free open source projects and paid closed clients... It would be nice if you carry out a personal investigation and return here with a comprehension of the state-of-the-art in this field.
You may even find out something according to your needs so nicely that you'll feel no need to read the following. See also Kin.
Speaking of Naamari, the principal flaws we tried to amend were:
(0. Closed source.)
1. Join of cryptographic and transport modules.
2. Replication of folder structure and names on a cloud.
3. Inflexibility of synchronization.
Naamari works with four locations. The first is a folder on your drive where the original/decrypted files are placed. The second is the folder containing the directory structure and the names of the files placed into the storage (but not their content). The third and the fourth are the storages themselves: local and remote ones. The former is a folder-on-your-drive again, while the latter is a cloud (folder too, the root for your account). In storages, there are no directories, the files have pseudo-random names (to get rid of the 2nd issue), and their content is encrypted.
The en/decryption is controlled by the keys, calculated from the so-called protokeys (the 160-byte file on your drive) and the passphrase you enter at the beginning of every session.
To amend the 1st issue, Naamari consists of two independent modules/applications. The main module, «Naamari» itself, is a cryptographic one, it has a full access to all locations but fourth since it doesn't touch a network. Naamari's completely offline. With this module you move the files between original and encrypted forms, between the «open» folder of your drive and the local storage. All operations are specified manually, — the price you pay to avoid the 3rd issue (folders are processed recursively, it's not that manual). The operations which don't affect the remote storage are performed here entirely; if you want to do anything that changes the remote storage, such actions are assigned with Naamari.
But Naamari module only assigns and doesn't perform these. Instead, to each encrypted file in the local storage it adds another small file, the descriptor, which, ahem, describes the local and remote versions of that file, as well as the action assigned. To execute that action is the work of the transport module — «Naamari-lautta». It reads descriptors and calls the full-fledged console client of (hypothetically any if it has advanced enough API) cloud, so the latter does the job. In turn, the job may be of three types: upload, download, remove. Basically, Naamari-lautta is simply a wrapper for a generic client application, it knows nothing about the crypto-stuff at all. It accesses only the local and the remote storages.
Current Naamari release includes files with command line syntax for:
Two modules intersect at the local storage with encrypted files and descriptors, so you can move the local storage folder from one computer to another. The cycle goes like this: you run Naamari on the «internal» desktop PC, disconnected from the network, then copy local storage folder to the intermediate data carrier (DVD-RW, flash drive, ...), get it to the «external» laptop or phone with Naamari-lautta installed, and finally, run the transport module to upload the new (versions of the) files on the cloud and download other files from the cloud. Updated local storage then moves to the carrier and returns to the PC. Next iteration, please. By the way, any of «internal» and «external» machines (or both of them) may be virtual.
This division, although slowing down and «manualling» the data transfers, is supposed to facilitate the compliance to security requirements, — in particular, those concerning wiping of memory/drive/cache, — and diminish the possibility of security violations (something any clever adversary looks forward to).
As long as the file remains referenced in the second folder (with directory structure and names), you can delete local version and then get back the remote one, which becomes local, or vice versa. This way the files not needed at present don't occupy the space on a local drive, and if they were wiped accurately (along with protokey and the 2nd folder), the «overseer» should not be able to get them.
With Naamari module alone you are able to work with local storage: create and modify it, add new files and remove unnecessary ones. The copies of the storage may be put on carriers like (rewritable) compact disks, flash drives, streamers etc., which play the role of your own cloud. In such circumstances, nevertheless, we recommend to use Naamari-lautta: it can work with «mounted» filesystems, that is, local folders, by calling system's copy/remove routines. See the manual, Naamari-lautta syntax.
The release for Windows, which you get from Download page, is portable in that you don't install it to your system, just unpack and run. Linux users have to compile the sources for now; there should be no problems, since Naamari and Naamari-lautta projects don't have «external» dependencies, that is, headers and libraries outside of «standard» Qt and Go compiler packages (of course, you need to install these packages first). Before you start, please read the manual from Manual folder. For the time being, you may read it in English, Russian, and Ukrainian. Haven't we mentioned (and haven't you seen above) that Naamari is a purely console application?.. The manual describes its command-line syntax and other things you should know.
Don't skip the «Nuances» item of the manual, where the buzzwords «encryption», «hash» and «salt» are concretized. For the sake of accessibility, it is duplicated here, at Specs page.
WARNING. This project hasn't been examined by any expert group yet.
Thus the remarks and suggestions are extremely welcome, to say nothing of reports about bugs and malfunctions. See the Contacts page.
The detection of cryptographic holes is welcome even more extremely. One has been revealed already by external review. Moreover, we have the entire Breaks page dedicated to these. Also, there is a Challenge which may be of interest to you...
Uh-oh, your precious confidence approaches zero level as you read this... well, read the specs, grab the source and be happy to make something providing the functionality yourself.
P.S. All in all, you will not trust it and you will not use it... for a time being. It has too many flaws of its own: signs of an amateurish stuff, unreliable origin, console interface, immaturity, absence of tests and audits... something we know well. And something extremely dangerous when you're dealing with cryptology in quest of security. Perhaps you will only try it — with non-sensible data, from a virtual machine — to see how it works.
Perhaps for all of you, it is a question of concept more than that of usability or deployment. Should the thing we need to accomplish these tasks have such features, and such structure? The separation of cryptographic and transport applications, the set of commands, the encryption scheme, and so on. The answers depend on your priorities and experience, different from ours, and all of us can benefit by this divergence.
Copyright © 2014–2020 Sunkware
〈VisitIPs is watching you〉