This is... more complicated than it sounds.

AES256 bit encryption is not practical to break in any meaningful way. Now the fact the key is symmetric means that if you're sharing data with a third party then both the sender and receiver need to have a copy of the key, and so there's now two places where the key can be *stolen*. And that's a theoretical weakness. Which is why high security requires a "secure encryption device" (e.g. a Hardware Security Module - HSM) to store keys.

In comparison, many asymmetric keys are theoretically weaker; RSA2048 uses 2048 bit keys, but is only the equivalent strength of 112 bits of symmetric encryption; RSA4096 is only 128bits. (More modern elliptical curve based asymmetric systems can use smaller keys but have other challenges). 112 bits is still very strong, though, and is the minimum size allowed for protecting of credit card data (for example). This method does have advantages when sending to third parties; the person encrypting the data doesn't need the decryption key, so there's only one place where the decryption key can be stolen.

So what does this mean for programs like `rclone`

where, typically, the same program is used to encrypt and decrypt? With both asymmetric encryption we would need access to all the keys, and so the risk of theft is pretty equivalent and the key size would be smaller. There's no real advantage to asymmetric encryption in this case.

Indeed, there may be other *disadvantages*. In particular asymmetric encryption is a lot slower than symmetric. This is so bad that we don't normally encrypt large chunks of data this way. If we wanted to use asymmetric encryption (because we are sharing with a third party) then what normally happens is we generate a "one time use" symmetric key (eg AES256), encrypt all the data with that, and *then* protect the symmetric key with asymmetric encryption and store the encrypted key with the encrypted data. Now the receiver can use their half of the key to decrypt the AES key, and then use AES decryption to get the data. Whew, that's a lot of stops! This is kinda the best of both worlds, though; you have fast encryption for the large data set and only use the slow encryption for the small key. Indeed, a variation of this is how TLS works for encryption talking to web sites. I go into some more detail on this at https://www.sweharris.org/post/2019-09-15-rsa-aes/

`rclone`

uses symmetric encryption, as is common for many tools of this type. This means it is not a good tool to *share* encrypted data with third parties, because both parties need to have the same encryption key, but it's perfectly good for encrypting your own data in a cloud service for later retrieval.