Re-Encryption possible

OttoDeploy
1

Hi, sorry to ask that stupid question, but is re-encryption of databases now possible? At least on Install/Replace? That would be a gamechanger for us.

Many thanks
Tobias

2

Hi Tobias,

Thank you for reaching out! This is actually not a stupid question at all - it’s a great one. I’m happy to confirm that database re-encryption is indeed possible now.

Could you share a bit more about how you’re planning to use this feature in your scenario?

Todd

4

We are an SBA Partner and it would be perfect for the first install to use otto and just reencrypt the customers DB with its own encryption key. That way we can use otto from the very first install up to all the updates later on.

5

Hello,

Thank you for that information. I just wanted to make sure you didn’t have a use case we hadn’t considered yet.

Encrypting with a different key on Install/Replace is the part we need to add. It is on our road map for early next year.

Thank you

Todd

1 Like
6

Many many thanks!! You are awesome :heart:

7

Hey! I’m confused about this subject, is it still pending? I feel like I remember doing an “install” with two different encryption password and the destination being completely okay and having the new client encryption password.

But if I do that now, it has the weirdest state where following migrations with the same left-right different encryption passwords as the install fails with the error “wrong encryption password”, if I close and reopen the file on OttoFMS or FMS console, I have to input the good new file password to open it, but if I download the file and try to open it offline, only the old source password works.

I’m pretty confused, should I still not use install in our case ? (Every client has a different generated encryption password).

8

Hey Marc-Andre,

Currently OttoFMS does not re-encrypt files as part of a deployment. If you want to re-encrypt a file with a new encryption password you should use the “Encrypt” option from the OttoFMS UI.

So for your flow it would probably be:

  1. create a newly encrypted version of the file with a new encryption key
  2. run the deployment to move the file from that server to your destination.

-Kyle

9

Perfect, thank you for the confirmation!

10

Is this no longer being worked on? Because You said its on the roadmap for early 2025?
Can we use the encrypt function of the ottofms ui to encrypt multiple databases in one go?

Thanks,
Tobias

11

Hey Tobias,

Priorities changed a fair bit this year due to some other goals, so this has not made it to the top of the list yet.

You cannot re-encrypt multiple files at once at this time.

-Kyle

12

Ok, thanks. Patiently hoping this will make the cut in a future release :slight_smile:

13

Any update on this? Would love to have this feature

14

No update on this at the moment. Thanks for checking in

15

Hi kyle,

just wanted to check if there is any news on this. We think of migrating most of our servers to linux but we do have a whole lot of tools in place that take care of the encrypting part of the first deployment and it is all based on windows.
So if you could add that as part of otto I would be soooo thankful :slight_smile:

Also when you add this please consider these additional features:
• when migrating a non-encrypted DB to an encrypted version (existing installation) Otto should first encrypt the DB with a temporary key and then migrate automatically.
• re-encryption using the GUI should work for multiple Databases

Many thanks, Tobias

16

Hey Tobias,

What is your use case for having a non-encrypted source file and an encrypted destination file? it seems like this could be solved by simply encrypting the source. This feature is not a high priority for us at the moment. I’m working on some multi-file features in the UI that should help, but the encryption as part of a deployment is a pretty large change to that process and is quite complex for the migration operations especially.

-Kyle

17

What is your use case for having a non-encrypted source file and an encrypted destination file? it seems like this could be solved by simply encrypting the source

This is just a fringe use-case where we do have unencrypted DEV files to more easily work with them but this is just reaching for the stars and not essential.

I now have begun to implement our own workflow for this using MBS and PSOS as I understand this is not high on your list and has additional complexities (And requires no ordinary migration account but a full access one).

Thanks and looking forward to the multi-file operations!