Performance measurement of the encryption process

Hello!
For a college project I want to measure and compare the encryption performance (CPU and RAM) of various client-side encryption tools. Currently on my list is Duplicati, Kopia and Cryptomator. A major problem for me is the fact, that while Cryptomator performs only encryption, Duplicati and Kopia also perform deduplication and compression. As I understand, compression can be deactivated. Not deduplication however. Due to time constraints I havent had the chance yet to download and thinker around with these apps, hence this preemptive question. Can you recommend me a method to measure the performance of encryption only? My initial thought was to fork Duplicati and add logging code before and after the encryption process. This might turn out tedious however. Does Duplicati offer such logging by default? Because if I know when encryption starts and end, I can stake out the exact intervall in my performance measurement.

Regards!

Welcome the forum @kernelsanders

C:\Program Files\Duplicati 2>SharpAESCrypt.exe
Usage: SharpAESCrypt e|d[o][1-4] <password> [<fromPath> [<toPath>]]

Use 'e' or 'd' to specify operation: encrypt or decrypt.
Append an 'o' to the operation for optimistic mode. This will skip some tests and leaves partial/invalid files on disk.
Append a single number (up to 4) to the operation to set the number of threads used for crypting. Default is single thread mode (1).

If you ommit the fromPath or toPath, stdin/stdout are used insted, e.g.:
  SharpAESCrypt e 1234 < file.jpg > file.jpg.aes

Abnormal exit will return an errorlevel above 0 (zero):
  4 - Password invalid
  3 - HMAC Mismatch / altered data (also invalid password for version 0 files)
  2 - Missing input stream / input file not found
  1 - Any other cryptographic or IO exception

C:\Program Files\Duplicati 2>

Correct, but backup still uses a .zip file, even if some or all of the files inside the file are uncompressed.
Backup programs do far more than you mention, and I wouldn’t even call them primarily encryption tools.

Not that I’ve ever seen, but maybe its standalone encryption will remove the need, if you stay on this path.

1 Like

Thank you for your elaborate response.
Testing the underlying encryption library itself is something I haven’t thought about. However, I think in my context it would be a flawed approach, since the library itself encrypt a file, but within Duplicati it encrypts whatever Duplicati made out of said file (I think it splits files into chuncks that are then encrypted, correct?).

calling it a encryption tool was indeed false. the broader context of this project is the research of means for encrypting cloud backups on the client-side with open-source tools, which Duplicati and Cryptomator are; despite being “different”.

I gave what you asked (quoting too), although I agree “encryption only” focus misses all else.

This is fine, but a focus on just encryption performance despite extensive other work lost me.

I can’t really advise on what project you should do, but if you have specific questions, just ask.

1 Like

Not entirely. Duplicati packs everything into a compressed files (usually zip) and then encrypts the whole zip file. The encryption performance is directly measurable by encrypting a file of similar size, and you can do that as shown by @ts678 above.

1 Like

@ts678 @kenkendk Thank you for the explanation!

@ts678 @kenkendk

Does Duplicati have more detailed documentation on its encryption process, similar to Cryptomator’s (Security Architecture — Cryptomator 1.7.0 documentation)? I couldn’t find anything comparable in the Duplicati documentation.

I’m asking because I’m confused by the following:

@kenkendk mentioned, “Duplicati packs everything into a compressed files (usually zip) and then encrypts the whole zip file.”

However, the developer documentation on GitHub (Developer documentation · duplicati/duplicati Wiki · GitHub) states: “The encryption and decryption are performed in a file-to-file manner, to avoid leaking any information.”

Isn’t this contradictory?

You need to decide if you really meant encryption, or the whole affair.

Encryption is easy. Click the link at sharpaescrypt, follow to aescrypt.

How so? While I’m not sure if I follow “file-to-file” remark, it sounds a lot like “encrypts the whole zip file”.

You are right, my focus has shifted from the encryption alone to the whole affair, such as key generation, key encryption keys, etc. Thanks for the clarification regarding the zip file aspect.

Thanks for clarifying. Information on the rest is sort of scattered around and high level compared to the Cryptomator “Security Architecture” article, which concentrates on single focus and so can get deeper.

The backup process explained in the manual tries to show things in simplified terms. For technical, see

How the backup process works and How the restore process works, but encryption is just a minor part.

Block-based storage engine starts at high level concepts, then links to a (2014 - so dated) detailed PDF.

The Developer category you are in has other specific topics like on the channel pipeline, file formats, etc

1 Like

It depends a bit on the context when reading it. The “file-to-file” mentioned in the developer documentation should be interpreted as “zip-file to zip-file” as opposed to source-file to source-file.

I have noted that we should produce a description of how the security features are combined and what layers of protection are in.

@kernelsanders A bit later, I have written up the security aspects in a single article: