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.