It's not possible, you need our software to restore data that was encrypted by it.

Why is not possible? I don't see any technical limitation. I just need to be able to use the PBKDF with the same salt and I should be able to generate the AES256 key that was used to encrypt the data.

Joey, that's not information we share in any way as it pertains to internal encryption methodologies. If you need to decrypt an encrypted backup outside of CloudBerry, then you may want to look into AWS KMS encryption which is managed by AWS and controlled by you. There is KMS encryption support in standalone CloudBerry Backup.

Ok.

Making internal encryption methodologies public does not make them less secure, though.

I just caught the "standalone" before CloudBerry Backup. I am working with CloudBerry Managed Backup, as we plan to offer a backup service internally.

I hope you can revisit your decision not to share these details, as the solution might not meet Government of Canada's security requirements as it is, and we have might have to move to another solution for backup/archiving data.

Thank you for always answering my questions!

Would you mind explaining in a bit more detail why the Canadian Government needs to be able to decrypt files outside the software / services that encrypt them? Is there a Canadian regulation driving this? Any information would be helpful when I bring this requirement to the team. KMS Support for Managed Backup is currently under discussion.

In the meantime, you have our Client-Side Encryption (AWS-256 which requires CloudBerry to decrypt) as well as Server-Side Encryption options offered on may cloud services (encryption-at-rest).

I look forward to your reply.

Thanks.

There are two related issues at play here. The first deals with end-of-service/disaster data recovery. In the event that we choose to stop using CloudBerry, then repatriating the data is simple: we use the client. However, if, for any reason, the CloudBerry servers themselves become unavailable, it is impossible for us to repatriate the data, even though it stills exists in the cloud storage.

Second, we require control of the client-side encryption keys, which CloudBerry does not at this moment provide. We do control the passphrase used to generate the key, but we have no way of generating the encryption key ourselves.

That is indeed what we are using in the meantime.

Thanks for responding,

Is there an update to this response? We are thinking of the same consequence if something were to happen to CloudBerry in 30 years from now. Maybe the product line is dropped and we can't get the client installed somewhere. What happens to all of our long term backups that were encrypted?

Jeff, it's an interesting question without an easy answer.

The backups are in a proprietary format. Any program that needs to restore these files would have to come from MSP360. I realize that some files may be backed up in whole, and you could make the case that a backup of a file that contains the entire file could theoretically be decrypted and decompressed using some technology outside of MSP360. In order to do that we would likely have to use either some open standard / open source method (like a ZIP files) or provide source code to the community. Unfortunately, that's not how the product is engineered. But even that option would not work with block-level backups, filename encryption, or any new backup formats that we are working on (wink wink) to improve the product.

I suppose we could say that should the company ever go out of business we would make available a version of the product that could be used to restore files. And I'm certain we would do that if this doomsday scenario ever played out (despite our growth and having no plans to go away).

I've been in the backup and disaster recovery space for a long time and the companies I've worked for have made restoring easy, despite them having proprietary formats. And it's more than backup and disaster recovery. You're trusting many SaaS companies with your data for hosted applications like O365/G Suite, Salesforce, password managers, private / public clouds, BDR, etc.

One thing you can do is restore any important files, if needed, and then encrypt them yourself and copy them to cloud storage using a product like MSP360 Explorer. Stick them in low-cost, archive storage or on a hard drive you own and keep them for the long haul. Managing this could be prone to its own issues though.

What have you seen, if anything, from other products that helped relieve you of these concerns?

Thanks for the reply. We have only used MSP360's CloudBerry since it works so well and didn't think about this scenario until recently. I think your option for encrypting with another product and then sending it is a viable option that we will have to weigh in if we wanted to circumvent this risk. Or we can wait and see if there is any inclination that the product will no longer be supported, we would then restore and then re-encrypt. We will most likely go with the latter so thanks for your response.