Questions regarding cryptographic aspects

kernelsanders · May 17, 2024, 7:13pm

Hello,

I have a few questions about the cryptographic aspects of Duplicati, which I couldn’t find answers to in the official documentation. I apologize if I overlooked relevant articles.

As clarified in a previous thread, Duplicati encrypts not the files themselves, but the .zip files containing the data chunks.

Does Duplicati use different encryption keys for the generated .zip archives (dlist.zip, dblock.zip, and dindex.zip)?

For simplicity, I will further refer to the keys in plural, regardless of the answer to the first question.

Where and how does Duplicati store the encryption keys?
Are the encryption keys themselves encrypted with a key-encryption key?
Does Duplicati derive the keys from the user-defined password using a key derivation function, or are the keys generated by a cryptographically secure pseudorandom number generator? What is used as a salt input?
Does Duplicati utilize a dedicated MAC key for the integrity of files?

I am looking forward to your replies!

Jojo-1000 · May 17, 2024, 8:09pm

As explained in the previous thread, the encryption is fully handled by the SharpAESCrypt library. It uses the AES Crypt file format (V2). This documentation might be interesting to you:

There seems to be a separate session key for each file, stored at the beginning of the encrypted data. There is also a SHA-256 hash for the data. Only the backup password is used as the basis for encryption, although there seems to be some kind of key derivation implemented in the library.

For the other questions, please look at the source code of the library. There does not seem to be much documentation about this.
SetupHelper might be a good place to start:

github.com

kenkendk/sharpaescrypt/blob/master/Source/SharpAESCrypt.cs#L753


      
              }

              return retAlgoType;

          }

          

          /// <summary>

          /// Initialize the setup

          /// </summary>

          /// <param name="mode">The mode to prepare for</param>

          /// <param name="password">The password used to encrypt or decrypt</param>

          /// <param name="iv">The IV used, set to null if encrypting</param>

          public SetupHelper(OperationMode mode, string password, byte[] iv)

          {

              // Check for AES-implementation to use and save that type for subsequent calls.

              if (m_useSymmetricAlgorithmType == null)

                  m_useSymmetricAlgorithmType = resolveCryptoAlgorithm(CRYPT_ALGORITHMS, out m_crypt);

              else

                  m_crypt = (SymmetricAlgorithm) Activator.CreateInstance(m_useSymmetricAlgorithmType);

          

              //Not sure how to insert this with the CRYPT_ALGORITHM string

              m_crypt.Padding = PaddingMode.None;

              m_crypt.Mode = CipherMode.CBC;

kernelsanders · May 17, 2024, 8:18pm

It’s embarassing, but I have to admit that only now I start to understand what is meant by “fully handled” by the cryptographic library. So in short, Duplicati users input their password and everything else is fully handled either by SharpAESCrypt or GPG. Sorry for being so daft.

ts678 · May 17, 2024, 9:31pm

If you want the answers, some probably are in the AES Crypt forum already. For others you could ask.

Allow the use of stronger key derivation functions is one such example, and there are probably others…

If you search for key encryption key talk, note, they have a keyfile ability, and SharpAESCrypt doesn’t.

No. The same passphrase to SharpAESCrypt.exe will work with any of them.

I don’t think it does that. It stores passphrases for jobs in its server database.

Using as a library in a project shows at least some of the SharpAESCrypt library interface. Simple.

https://github.com/duplicati/duplicati/blob/master/Duplicati/Library/Interface/IEncryption.cs
shows the Duplicati usage which looks equally simple. Password/passphrase goes into the library.

I linked one of their KDF answers, but here’s one that also also covers random numbers for the IV:

AES Crypt key generation

I’m going to stop there, and I might have already gone too far. I am not a cryptographer, and details
about the cryptographic design are probably best found in answers from the AES Crypt developer.

Beware, though that they have a product containing cryptography, but Duplicati made a bigger one.
You will find product to product differences, even though the file format and crypto are likely similar.

ts678 · May 18, 2024, 10:16am

I don’t know how far your key storage question meant to go, but the passphrase story is complex, due to.
Different ways to make a Duplicati backup. The server database is used by the Server – basically in GUI.

CommandLine (like most of them) can have passphrase given as an option on terminal or script, like this:

passphrase

Supply a passphrase that Duplicati will use to encrypt the backup volumes, making them unreadable without the passphrase. This variable can also be supplied through the environment variable PASSPHRASE

If a passphrase is needed and is not supplied, the user is prompted to type it (obscured by * for privacy), which means that where it is stored is up to the user, similarly to the above case where an environment variable is set – somehow – from whatever storage the user wants. Another way to set any option is with
Scripts writing new options to their output. For CommandLine, parameters-file can store the passphrase.

kenkendk · May 18, 2024, 1:25pm

Yes, exactly. The idea is to not have any self-rolled crypto in the project.

The SharpAESCrypt library is written by me, so you could argue it is kind-of hand-rolled, but it is based on the AESCrypt specs and file-format compatible. This was needed as AESCrypt did not have binaries for all platforms at that time.

Yes and no. The is a different file-encryption-key created for each encrypted volume, but it is derived from the same passphrase, as @Jojo-1000 points out.

As explained by @ts678 “it depends” on what interface you use. If you use the CLI, the user is responsible for providing the passphrase and can provide this in various ways.

While you can technically use the same for the GUI based aproach, most users will likely let Duplicati handle the passphrase. In this scenario, the passphrase is stored inside the Duplicati-server.sqlite database along with other credentials. Up until now, this database has been encrypted with RC4 encryption where supported (which is mostly just on Windows). The password to this database can be changed but most likely very few people have changed it.

For the .NET8 releases we have updated to the newest SQLite binaries, which do not support RC4, so for some time, the database will not be encrypted, but encryption with a known password is very close to having no encryption in terms of security analysis.

The plan has been to offload the passphrase and other sensitive information into the OS keychain, but this has not been implemented so far.

That is the responsibility of the SharpAESCrypt library, but in short, a random IV is generated, the passphrase is used to derive an encryption key. The random IV and key are used to encrypt the session iv+key that is used for encrypting the file.
There is HMAC-SHA256 built in to the AESCrypt format.