Hello,

On Jan/09/2008, Dan Langille wrote:

>>> My wish is this process:
>>> -Generate public+private key in a secure computer
>>> -Copy the public key to bacula-fd computer
>>> -Copy the private key to some other place
>>
>> The file daemon configuration code currently requires that at least one 
>> private key be present -- changing this would be a relatively small patch.
>> The crypto implementation shouldn't make (m)any assumptions about key 
>> availability, so I believe the config change should be sufficient.
>>
>> If you've any interest in tackling this, I can provide some pointers, 
>> otherwise I can try to get around to it sometime next week.
>
> I had a couple of thoughts about this tonight...
>
> I was thinking about off site backups and what best practice would be: 
> encrypt them.  If you are sending your backups off-site for safe keeping, 
> they are outside your control, and you'll probably want to encrypt them on 
> the tape.
>
> If you are encrypting at the FD, you'll want the public key there, but 
> probably not the private key.  You might want the same key pair used on all 
> clients, but the master key kept somewhere secure.

Yes... but I'm not sure that "the same key pair used on all clients". At
least, please, don't force it :-)

> Then I thought, if you want to do that, why not just encrypt at the SD 
> instead of the FD.  If you're a big company and you want to encrypt, why 
> not do it all in one place?  Why bother distributing the same key 
> everywhere?  Or multiple keys for that matter?

Imagine that you want to offer backup service to external offices. You
need the cyphered data (to backup) but you would not want the private
key. You need to receive this already cyphered without any way to
decrypt it.

The best approach for this (IMHO, with my limited knowlegdes) would be
to generated to public/private key in a customers trusted computer and
only get the public key to crypt.  So, we would never have access to the
private key.

I'm thinking how to guarantee the backup and disallowing myself to
decrypt the data (for legal reasons, trust reasons, etc.)

> Landon: given what you know now, would encrypting at the SD be similar in 
> scope to encrypting at the FD?

I feel that this is very different (SD is on server, FD on client, if I
remember correctly the Bacula nomenclature)

Thank you very much for your attention,

-- 
Carles Pina i Estany            GPG id: 0x8CBDAE64
        http://pinux.info       Manresa - Barcelona

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to