Establish And Maintain Public Key

[dnwiebe]

There's a business requirement to allow a Node to keep the same public key over a shutdown/startup cycle.

We'll do this by having a newly-installed Node pick its own key pair and store it in the database; then assume it on startup each time. (Another card (GH-623) will allow the user to specify --new-public-key on or --new-public-key off on the command line; but that's not this card.)

• CryptDEReal has two important fields:
  encryption_secret_key
signing_secret_key
  You should be able to reconstitute an entire CryptDEReal from just these two fields.

• These two fields should be stored in the CONFIG table in the database. Since they're really different parts of the same data object, there's a good argument for storing both fields in the same row. Suggestion: Get the binary data from each secret key, Base64-encode it into a string, and store both strings in the VALUE column of the CONFIG table, separated by some character that's not used in the Base64 encoding, like space or comma.

• Be sure to save these fields as encrypted: they're secret keys.

• This will require a database migration. Migrate from version 10 to version 11, adding a row to the CONFIG table. Look at migration_0_to_1.rs for an example.

• Add From<String> and Into<String> methods to CryptDE and implement them in both CryptDEReal and CryptDENull. Add a pair of methods to PersistentConfiguration for reading and writing CryptDEs to the database, using the new From and Into implementations.

• Definitely write the main CryptDE to the database. You can probably get away without writing the alias CryptDE to the database. The alias CryptDE shouldn't need to maintain its value between Node runs, only between the time a request is sent and the time the response arrives.

• The main CryptDE is established in ActorSystemFactoryTools, by the cryptdes() method. You'll want to modify this method to take BootstrapperConfig and PersistentConfiguration references and call the new PersistentConfiguration::cryptde() method with the database password (if any) from the BootstrapperConfig. If it returns Some(cryptde), use that one. If it returns None, generate a new one with CryptDEReal::default() and call PersistentConfiguration::set_cryptde() with it.

• Edge cases:

  • Maybe BootstrapperConfig::db_password_opt is None. In that case, always generate a new public key, because you can't read or write an encrypted value without a password.

[dnwiebe]

Test Plan

1. Brand-New Database:
   1. Install MASQ in a brand-new environment.
   2. Start up the Node without specifying a password. Note the public key in the Node Descriptor at the beginning of the log.
   3. Shut down the Node.
   4. Start the Node back up, examine the new Node's Node Descriptor and verify that it's different from the first one.
   5. Shut down the Node.
   6. Start the Node back up, but this time specify --db-password password (or some other password, your choice) on the command line. Note the public key and verify that it's different from the first two.
   7. Shut down the Node.
   8. Start the Node back up, again specifying --db-password password (or whatever) on the command line. Note the public key and verify that this time it's the same as it was in Step vi.
   9. Shut down the Node.
   10. Start the Node back up, this time neglecting to specify --db-password, and observe that the public key in the log is a completely new never-before-seen value.
2. Existing Database:
   1. Find an existing database from an installation of MASQ older than this card, so that we can demonstrate updating the database schema to add the configuration record for recording the public key. Note that this test will update your old database; so if you want to keep an old-version database, make a copy of the environment and run this test on the copy.
   2. Start up the Node with --db-password password on the command line. Make a note of the public key in the log.
   3. Shut down the Node.
   4. Start up the Node again, again with --db-password password on the command line. Observe that the public key is the same as it was in Step ii.

And that's it! If you got here without any problems, it works.

[kauri-hero]

QA has completed - ready to merge!! 👍🏻