Design Deploy - Gadreel/divconq GitHub Wiki
Crypto Settings
<Clock TimerClass="[class name]" Id="[hex value]" Feed="[hex value]" />
Gateway Servers
Each gateway could use entirely separate crypto settings as the only role here is to secure the config settings. Officially there is no database crypto in Gateways and no domain level crypto in Gateways.
Just for ease of deployment, most likely share the same settings across all Gateways within a given deployment.
Backend Servers
Share the Id
across all deployments. Feed
on the other hand is specific to that Deployment. So for a given deployment the TimerClass
, Id
and Feed
are the same across all backend servers. Each deployment may have its own Feed
as well as its own TimerClass
. These three settings combine to form the crypto for the config settings.
Database and Domain crypto rely on only the Id
from config - the seed (feed) and class come from the database. This makes the domain database portable from one deployment to another - as long as you use the same Id
in both deployments.
TimerClass
There are times when loading the Id
or Feed
from settings is not secure enough - the TimerClass
can be configured for your project to load settings from where ever you like and also to mix up the formula for how Id
and Feed
are used. A hacker familiar with DivConq looking at your settings, when a class is present, will not be able to decrypt without first reversing your timer class.
This helps protect offsite hacking of backups. If your timer class loads a local resource - such as params from a VM instance - then even after your TimerClass
is hacked the local resource is missing. With creative thinking a variety of options can be used to secure the crypto seeds.