Question about encryption without RSA

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

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

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.

Here is how it works

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.

1 Like

Thanks for the clarifications

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

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

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?)

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)?

yes, it shall do the same.

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

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?

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.

1 Like

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…

This is very true. The simpler the solution – the more likely it will be used successfully :slight_smile:. 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 :slight_smile:

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.

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.

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

1 Like

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 :wink:

2 Likes

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.

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.

1 Like

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.

2 Likes

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!

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.