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.
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 onor--new-public-key offon the command line; but that's not this card.)CryptDERealhas two important fields:encryption_secret_keysigning_secret_keyYou should be able to reconstitute an entire
CryptDERealfrom just these two fields.These two fields should be stored in the
CONFIGtable 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 theVALUEcolumn of theCONFIGtable, 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
CONFIGtable. Look atmigration_0_to_1.rsfor an example.Add
From<String>andInto<String>methods toCryptDEand implement them in bothCryptDERealandCryptDENull. Add a pair of methods toPersistentConfigurationfor reading and writingCryptDEs to the database, using the newFromandIntoimplementations.Definitely write the main
CryptDEto the database. You can probably get away without writing the aliasCryptDEto the database. The aliasCryptDEshouldn'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
CryptDEis established inActorSystemFactoryTools, by thecryptdes()method. You'll want to modify this method to takeBootstrapperConfigandPersistentConfigurationreferences and call the newPersistentConfiguration::cryptde()method with the database password (if any) from theBootstrapperConfig. If it returnsSome(cryptde), use that one. If it returns None, generate a new one withCryptDEReal::default()and callPersistentConfiguration::set_cryptde()with it.Edge cases:
BootstrapperConfig::db_password_optisNone. In that case, always generate a new public key, because you can't read or write an encrypted value without a password.