Question about encryption without RSA

[klayhamn]

So I went over the documentation as well as the forum and there’s still something fundamental I don’t fully understand about if/how the data itself is encrypted:

• Is the data encrypted at all, by default, when I supply a password to the storage?
• I read somewhere that it’s only used to encrypt the config file - so that means only the config is encrypted, and the data is not? or - is the data encrypted by a randomly generated key that’s stored in the config (that’s my current understanding)?
• how does it all relate to the RSA key that i can (optionally) provide? does this come INSTEAD of the password for the storage? in addition? and - is this used in any way to encrypt the data itself, or only to bolster the protection of the config file…?
• What’s the role of the “encryption password” in the main settings in the UI (that aren’t associated with any particular storage)?

Sorry if these questions are silly or were already addressed, but despite trying to get a full comprehensive picture of everything i’m still a bit unsure what’s the situation

Thanks

[saspus]

@klayhamn

Is the data encrypted at all, by default, when I supply a password to the storage?

When you initialize target with -e flag the data is encrypted.

@klayhamn

data encrypted by a randomly generated key that’s stored in the config

Yes. If you lose config file your data turns to pumpkin. Maybe make a copy of it somewhere safe, if your storage does not provide data integrity guarantees.

@klayhamn

how does it all relate to the RSA key

Here is how it works

New feature: RSA encryption

Starting from version 2.3.0, you can initialize a storage with an RSA public key. Backups can be created as usual, but to restore files you’ll need to provide the corresponding private key. Duplicacy with RSA Encryption Initialization To initialize a new encrypted storage with the RSA encryption enabled, run the following command: $ duplicacy init -e -key public.pem repository_id storage_url The RSA encryption can be only enabled if the storage is encrypted (by the -e option). The RSA p…

@klayhamn

What’s the role of the “encryption password” in the main settings in the UI

It protects configuration and access to credentials for the app. Backup tools defeat your OS security and file permissions, have access not only to entire local dataset but also the whole version history. A password is the least such a program should ask before granting anyone access to essentially everything.

[klayhamn]

Thanks for the clarifications

@saspus

When you initialize target with -e flag the data is encrypted.

I actually plan to just use the GUI since CLI’s make me anxious but I guess that putting in the password is the equivalent?

@saspus

Yes. If you lose config file your data turns to pumpkin. Maybe make a copy of it somewhere safe, if your storage does not provide data integrity guarantees.

Hmm, that seems redundant (and cumbersome) - since my plan is to just back it up to Wasabi as the “cloud” location (and they do seem to provide a bunch of integrity guarantees, just like S3, etc. although unlike S3 they don’t automatically copy the data to multiple regions) , and otherwise keep it backed up in a local NAS

@saspus

A password is the least such a program should ask before granting anyone access to essentially everything.

Hmm, i guess, but i think in the web UI it’s just loaded by default somehow (i.e. i didn’t have to re-input it when re-opening the software?)

@saspus

Here is how it works

OK, so it just bolsters the encryption beyond just a single password, but is otherwise equivalent, right? in other words, it’s not qualitatively different than if two passwords were used (with one of them being quite long)? Or am i missing something fundamental about how it differs from a regular password (other than being long)?

[saspus]

@klayhamn

but I guess that putting in the password is the equivalent?

yes, it shall do the same.

@klayhamn

that seems redundant (and cumbersome)

Yes, it shall be OK. That file is written once and never changed, so probability for it getting lost is small. If backing up to HDD I woudl worry about it, but with cloud services, such as wasabi and aws it’s fine. It was more to illustrate a point that keys to the kingdom are in that file, losing it results in loss of data

@klayhamn

Hmm, i guess, but i think in the web UI it’s just loaded by default somehow

I may be wrong (Not using web ui myself) but I think it decrypts the configuration once and then saves the credentials in the keychain, so you won’t need to input the password manually.

Here is more: Why is there a Master Password?

@klayhamn

it’s not qualitatively different

It is.

With a password you need to provide this key (a password) to encrypt data during backup and you need the same key to decrypt data when restoring.

With RSA – you have a set of two keys, public and private. To backup you provide a public key, and keep private key elsewhere safe, it is only needed for restore, so it does not need to be on that machine at all. This allows interesting scenarios where you can have multiple machines securely backup to the same encrypted datastore, and if any machine is compromised – your backup is still protected. Nobody can get access to your data without the secret key.

[klayhamn]

@saspus

It is.

With a password you need to provide this key (a password) to encrypt data during backup and you need the same key to decrypt data when restoring.

With RSA – you have a set of two keys, public and private. To backup you provide a public key, and keep private key elsewhere safe, it is only needed for restore, so it does not need to be on that machine at all. This allows interesting scenarios where you can have multiple machines securely backup to the same encrypted datastore, and if any machine is compromised – your backup is still protected. Nobody can get access to your data without the secret key.

ah I see, that’s indeed an interesting point, though - i feel like for personal circumstances (i.e. not a business/office etc.) i am more likely to end up locking myself out of my data by losing my RSA key

my passwords at least I remember (and have them backed up on hidden pieces of paper)

but the private key would likely have to be stored on a USB drive or something similar and i have bad experience with those getting destroyed in various ways…

[saspus]

@klayhamn

i am more likely to end up locking myself out of my data by losing my RSA key

This is very true. The simpler the solution – the more likely it will be used successfully . I’d argue that for most users even the single encryption password may be too much. It’s easy to use though, and people are already used to passwords,so why not. With RSA and keys now you have to manage files, and that’s whole new ordeal, and indeed too much of a commitment.

Personally I treat all keys and passwords the same way and just cram them into a password manager. I just looked, I have over 800 items there. So from the security and “losing password” perspective adding one more password vs two keys makes no difference. In fact, RSA keys are text files, the content of which can be thought of a very long passwords.

The password manager datastore itself is replicated to the multiple computers, and to the cloud (it’s Apple Keychain and, diminishingly, 1Password), so losing it all at once is extremely unlikely. The master password for 1Password on the other hand is just in my head. I never change it, so by now it’s probably also in the spinal cord – my fingers type it out mindlessly

Perhaps I shall write it down somewhere… but where?.. Or I’ll just wait until 1password is not needed anymore. Passwords are on the way out as a thing anyway. Looking forward to that.

@klayhamn

my passwords at least I remember (and have them backed up on hidden pieces of paper)

Please don’t. (I mean, don’t remember passwords. Writing on a pice of paper, laminating, and storing in somewhere safe is OK). Passwords for multiple services that are easy to remember will not be strong enough (unless you are using somethign like Diceware, but that’s a lot to remember :)). Consider using password manager. There are a bunch of different ones on the market.

@klayhamn

but the private key would likely have to be stored on a USB drive or something similar and i have bad experience with those getting destroyed in various ways…

You are right. I would not trust USB flash drive to keep data for an hour. The only safe place for it would be in a password manager replicated to multiple destinations. Or maybe write it to those 1000 year BlueRay M-Disks. But then again, in this case – there is little difference between storing an 50 character password vs two keys, in terms of work involved. That key file is a just a text file, it’s content can be considered as just another password

[sevimo]

There are also other potential complications with using RSA, e.g. you won’t be able to copy even bit-identical storage without supplying private key unless you use 3rd party tools.

By default, you already get chunking and symmetric encryption, so in all likelihood, you don’t need RSA encryption. If you really did, you’d be absolutely certain by now. If you’re not, you don’t need it

[saspus]

@sevimo

There are also other potential complications

This is not specific to RSA – today to do copy, you need to provide the password. Which shall not be needed. Definitely for bit-identical storage, and probably for all other types.

Copy shall not try to decrypt. It shall copy chunks. That’s the idea. Otherwise, it defeats the most useful scenario. This will probably require to distinguish metadata chunks from other chunks, and this is useful for yet another feature – archival storage support.

[sevimo]

@saspus

This is not specific to RSA – today to do copy, you need to provide the password.

Sure, but for symmetric encryption the password is needed for pretty much every single command, so the need for that password is not unexpected (though indeed is not needed in most copy cases). In RSA case, private key is only expected to be utilized for restores, so exposing it for bit-identical copy op is unexpected.

[Droolio]

@saspus

Copy shall not try to decrypt. It shall copy chunks. That’s the idea. Otherwise, it defeats the most useful scenario. This will probably require to distinguish metadata chunks from other chunks, and this is useful for yet another feature – archival storage support.

Hmm, apparently metadata isn’t encrypted with RSA (last paragraph):

RSA encryption only applies to file chunks, not metadata chunks. Therefore, the file names, timestamps, permissions, attributes, etc are not protected by the RSA public key (but still protected by the storage password).

Without having looked at the code, I suspect the issue is that it encrypts with the regular encryption key first, and then with RSA - which would necessitate a reverse procedure, and having the private key at hand.

If it was done the other way around, non-bit-identical copy should be possible without decrypting all the way.

[JBow87]

@saspus

With a password you need to provide this key (a password) to encrypt data during backup and you need the same key to decrypt data when restoring.

Hi there, I’m late to the party here but I need some clarity on this:

I’ve encrypted my primary initialized storage to a B2 bucket, but when I restore a password-encrypted (not RSA, just default encryption PW), I am not asked to enter any credentials and the restore goes off without ever prompting for the pw.

To be clear, upon creation of said backup directory, I am supplying an encryption password (not RSA), but I am not using the “-e” option; my backup should still be encrypted, no?

I also have my master PW set and unsaved. Any thoughts on what is going on?

Thanks for your help!

[Revan335]

@saspus

When you initialize target with -e flag the data is encrypted.

The same with the WebUI?
With only the Password is only the Config File Encrypted and not the Data?

It would be good if this is better explained in the WebUI, because with Password Protected and the lock it is assumed that the backup is also complete/encrypted.