Crypt Sync Files 1.3 – Syncs, encrypts, and decrypts files between local folders and USB drives. February 9, 2017 The Crypt Sync Files encrypts / decrypts and synchronize files between local folders and USB Drive, memory cards, network drives, folders on Cloud services (Dropbox, etc.).
CryptSync is a simple tool which synchronises two folders, while encrypting everything in the destination.
Point the program at your Documents folder, say, and you could have it create an encrypted folder on an external drive. Then, whenever you save a new file to Documents, it'll be saved in an encrypted form. (CryptSync uses 7-Zip to carry out the encryption, which means you also get file compression thrown in.) And you can set up as many folder pairs as you need.
Perhaps a more interesting use of CryptSync, though, is to encrypt the data you're uploading to services like SkyDrive, DropBox or Google Drive.
To make this work you would create a source folder to hold the unencrypted data, selecting a cloud storage folder as the destination.
Whenever files are copied or saved to your CryptSync source, they'll be encrypted in the cloud storage folder, and uploaded.
And the sync works in both directions, too, so if a file is changed in the cloud storage folder then it'll be decrypted and updated in the source.
This scheme does introduce some obvious complications. In particular, if your cloud files are encrypted then you can no longer access them from any device or browser; you'll need a decryption tool to hand.
But if you're just working on one or two PCs then this shouldn't be an issue, and on balance CryptSync could provide a useful extra layer of protection for your data.
A simple but effective file sync and encryption tool
The crypt remote encrypts and decrypts another remote.
To use it first set up the underlying remote following the configinstructions for that remote. You can also use a local pathnameinstead of a remote which will encrypt and decrypt from that directorywhich might be useful for encrypting onto a USB stick for example.
First check your chosen remote is working - we'll call itremote:path in these docs. Note that anything inside remote:pathwill be encrypted and anything outside won't. This means that if youare using a bucket based remote (eg S3, B2, swift) then you shouldprobably put the bucket in the remote s3:bucket. If you just uses3: then rclone will make encrypted bucket names too (if using filename encryption) which may or may not be what you want.
Now configure crypt using rclone config. We will call this onesecret to differentiate it from the remote.
Important The password is stored in the config file is lightlyobscured so it isn't immediately obvious what it is. It is in no waysecure unless you use config file encryption.
A long passphrase is recommended, or you can use a random one.
The obscured password is created by using AES-CTR with a static key, withthe salt stored verbatim at the beginning of the obscured password. Outline 3 19 1 – view onenote notebooks. Thisstatic key is shared by between all versions of rclone.
If you reconfigure rclone with the same passwords/passphraseselsewhere it will be compatible, but the obscured version will be differentdue to the different salt.
Note that rclone does not encrypt
In normal use, make sure the remote has a : in. If you specify theremote without a : then rclone will use a local directory of thatname. So if you use a remote of /path/to/secret/files then rclonewill encrypt stuff to that directory. If you use a remote of namethen rclone will put files in a directory called name in the currentdirectory.
If you specify the remote as remote:path/to/dir then rclone willstore encrypted files in path/to/dir on the remote. If you are usingfile name encryption, then when you save files tosecret:subdir/subfile this will store them in the unencrypted pathpath/to/dir but the subdir/subpath bit will be encrypted.
Note that unless you want encrypted bucket names (which are difficultto manage because you won't know what directory they represent in webinterfaces etc), you should probably specify a bucket, egremote:secretbucket when using bucket based remotes such as S3,Swift, Hubic, B2, GCS.
To test I made a little directory of files using 'standard' file nameencryption.
Copy these to the remote and list them back
Now see what that looked like when encrypted
Note that this retains the directory structure which means you can do this
If don't use file name encryption then the remote will look like this
Here are some of the features of the file name encryption modes
Off
Standard
Obfuscation
This is a simple 'rotate' of the filename, with each file having a rotdistance based on the filename. We store the distance at the beginningof the filename. So a file called 'hello' may become '53.jgnnq'.
This is not a strong encryption of filenames, but it may stop automatedscanning tools from picking up on filename patterns. As such it's anintermediate between 'off' and 'standard'. The advantage is that itallows for longer path segment names.
There is a possibility with some unicode based filenames that theobfuscation is weak and may map lower case characters to upper caseequivalents. You can not rely on this for strong protection.
Cloud storage systems have various limits on file name length andtotal path length which you are more likely to hit using 'Standard'file name encryption. If you keep your file names to below 156characters in length then you should be OK on all providers.
There may be an even more secure file name encryption mode in thefuture which will address the long file name problem.
Crypt offers the option of encrypting dir names or leaving them intact.There are two options:
True
Encrypts the whole file path including directory namesExample:1/12/123.txt is encrypted top0e52nreeaj0a5ea7s64m4j72s/l42g6771hnv3an9cgc8cr2n1ng/qgm4avr35m5loi1th53ato71v0
False
Only encrypts file names, skips directory namesExample:1/12/123.txt is encrypted to1/12/qgm4avr35m5loi1th53ato71v0
Crypt stores modification times using the underlying remote so supportdepends on that.
Hashes are not stored for crypt. However the data integrity isprotected by an extremely strong crypto authenticator.
Note that you should use the rclone cryptcheck command to check theintegrity of a crypted remote instead of rclone check which can'tcheck the checksums properly.
Here are the standard options specific to crypt (Encrypt/Decrypt a remote).
Remote to encrypt/decrypt.Normally should contain a ':' and a path, eg 'myremote:path/to/dir','myremote:bucket' or maybe 'myremote:' (not recommended).
How to encrypt the filenames.
Option to either encrypt directory names or leave them intact.
NB If filename_encryption is 'off' then this option will do nothing.
Password or pass phrase for encryption.
NB Input to this must be obscured - see rclone obscure.
Password or pass phrase for salt. Optional but recommended.Should be different to the previous password.
NB Input to this must be obscured - see rclone obscure.
Here are the advanced options specific to crypt (Encrypt/Decrypt a remote).
Allow server side operations (eg copy) to work across different crypt configs.
Normally this option is not what you want, but if you have two cryptspointing to the same backend you can use it.
This can be used, for example, to change file name encryption typewithout re-uploading all the data. Just make two crypt backendspointing to two different directories with the single changedparameter and use rclone move to move the files between the cryptremotes.
For all files listed show how the names encrypt.
If this flag is set then for each file that the remote is asked tolist, it will log (at level INFO) a line stating the decrypted filename and the encrypted file name.
This is so you can work out which encrypted names are which decryptednames just in case you need to do something with the encrypted filenames, or for debugging purposes.
Here are the commands specific to the crypt backend.
Run them with
The help below will explain what arguments each command takes.
See the 'rclone backend' command for moreinfo on how to pass options and arguments.
These can be run on a running backend using the rc commandbackend/command.
Encode the given filename(s)
This encodes the filenames given as arguments returning a list ofstrings of the encoded results.
Usage Example:
Decode the given filename(s)
This decodes the filenames given as arguments returning a list ofstrings of the decoded results. It will return an error if any of theinputs are invalid.
Usage Example:
If you wish to backup a crypted remote, it is recommended that you userclone sync on the encrypted files, and make sure the passwords arethe same in the new encrypted remote.
This will have the following advantages
For example, let's say you have your original remote at remote: withthe encrypted version at eremote: with path remote:crypt. Youwould then set up the new remote remote2: and then the encryptedversion eremote2: with path remote2:crypt using the same passwordsas eremote:.
To sync the two remotes you would do
And to check the integrity you would do
Files are encrypted 1:1 source file to destination object. The filehas a header and is divided into chunks.
The initial nonce is generated from the operating systems cryptostrong random number generator. The nonce is incremented for eachchunk read making sure each nonce is unique for each block written.The chance of a nonce being re-used is minuscule. If you wrote anexabyte of data (10¹⁸ bytes) you would have a probability ofapproximately 2×10⁻³² of re-using a nonce. Substance painter 2019 3 3 0.
Each chunk will contain 64kB of data, except for the last one whichmay have less data. The data chunk is in standard NACL secretboxformat. Secretbox uses XSalsa20 and Poly1305 to encrypt andauthenticate messages.
Each chunk contains:
64k chunk size was chosen as the best performing chunk size (theauthenticator takes too much time below this and the performance dropsoff due to cache effects above this). Note that these chunks arebuffered in memory so they can't be too big.
This uses a 32 byte (256 bit key) key derived from the user password.
1 byte file will encrypt to
49 bytes total
1MB (1048576 bytes) file will encrypt to
1049120 bytes total (a 0.05% overhead). This is the overhead for bigfiles.
File names are encrypted segment by segment - the path is broken upinto / separated strings and these are encrypted individually.
File segments are padded using PKCS#7 to a multiple of 16 bytesbefore encryption.
They are then encrypted with EME using AES with 256 bit key. EME(ECB-Mix-ECB) is a wide-block encryption mode presented in the 2003paper 'A Parallelizable Enciphering Mode' by Halevi and Rogaway.
This makes for deterministic encryption which is what we want - thesame filename must encrypt to the same thing otherwise we can't findit on the cloud storage system.
This means that
This uses a 32 byte key (256 bits) and a 16 byte (128 bits) IV both ofwhich are derived from the user password.
After encryption they are written out using a modified version ofstandard base32 encoding as described in RFC4648. The standardencoding is modified in two ways:
base32 is used rather than the more efficient base64 so rclone can beused on case insensitive remotes (eg Windows, Amazon Drive).
Rclone uses scrypt with parameters N=16384, r=8, p=1 with anoptional user supplied salt (password2) to derive the 32+32+16 = 80bytes of key material required. If the user doesn't supply a saltthen rclone uses an internal one.
scrypt makes it impractical to mount a dictionary attack on rcloneencrypted data. For full protection against this you should always usea salt.
0 
Star