> On Mar 14, 2017, at 12:54 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Tue, Mar 14, 2017 at 12:32:10PM -0700, Russ Allbery wrote:
>> "Henry B (Hank) Hotz, CISSP" <hbh...@oxy.edu> writes:
>>> Shut down all daemons on the master.
>>> hprop --decrypt --stdout | hpropd --stdin
>>> Restart all daemons.
>> You probably also want to shut down incremental propagation while you do
>> this.  I think this should force a full resync when the slaves reconnect,
>> but it would be a good idea to thoroughly test the replication behavior in
>> a test realm before doing this in a production realm.  I forget how it
>> deals with a complete database reload; I think it's supposed to do
>> something sane, but that would be the component that I would worry about.
> Good point, but actually restarting the daemons does not force a full
> resync.  You have to remove the iprop log file (on the master and/or the
> slaves -- either works) to force a full resync.

True. iprop will do a full download if the slave wants changes from a version 
older than the master has a record of.

ipropd-master is a daemon, so I stand by my original statement. ;-)
>> Note that you will need to manually copy the new master key to the slaves
>> before they'll be able to replicate.  Also don't forget to keep the old
>> master key around for the length of your backup retention so that you
>> don't invalidate your backups.
> If you're not storing the master key on a different disk anyways, and
> maybe even if you are, I would recommend just not encrypting the HDB at
> all.  As with MIT, only the principals' keys are encrypted, which leaves
> you subject to cut-n-paste attacks by, e.g., your backups operator.
> You should separately encrypt the backups/dumps.

Probably, but encrypting the key material separately doesn’t seem like a bad 

> Even if we could put the master key in a hardware token, that would not
> be sufficient to make the keys that much more secure.

Off-topic, but I agree. A lot of people are deploying HSMs believing they will 
solve problems they won’t.

> The only case that KDB/HDB encryption gets you more security is where
> it's easier to steal the disks than the whole system, and you either
> store the master key on a disk that's inside the system or you type it
> in when the daemons start.  With modern kit that's just not the case, so
> you might as well not encrypt the KDB/HDB.  (MIT doesn't give you the
> option; Heimdal does.)
> Nico
> -- 

Personal email.  hbh...@oxy.edu

Reply via email to