On Jan 8, 2008, at 23:26, Dan Langille wrote:
[snip]
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?
Yeah, absolutely. Much easier to maintain keys in one place, on the SD.
Landon: given what you know now, would encrypting at the SD be similar in scope to encrypting at the FD?
I hope it would be considerably less work -- all the existing crypto- specific code should be re-usable, which means most of the work should be in defining and implementing the storage file format. Off the top of my head, I'd suggest something block oriented, rather than one long stream of encrypted data -- that way it's possible to seek/ read to where you want to be without decrypting the whole stream.
Is this something you're interested in tackling?The 'crypto library' (lib/crypto.c) supports serialization and deserialization of necessary data structures (PKE session data, signatures, hashes) using an ASN.1 DER encoding, and is extensible in terms of data structure versioning, and encryption and digest algorithms. Algorithms are specified using standard ASN.1 NIDs, which means it's straight-forward to support anything OpenSSL supports.
The library is implemented using opaque data structures, with a common function naming scheme:
*_new() - create a new instance
*_encode() - serialize an instance
*_decode() - deserialize an instance
*_free() - free an instance
There are five 'modules' defined, implementing the following
functionality:
- crypto_keypair:
Loads x509-encoded public and private keys from disk.
- crypto_session
Implements multi-receipient PKE sessions. Instantiated with a
cipher and a list of public key receiptients, this data
structure encodes the initialization vector, symmetric encyrption
algorithm, and a per-receipient encrypted symmetric session key.
As an example, to create a new encryption session:
CRYPTO_SESSION session = crypto_session_new
(CRYPTO_CIPHER_AES_256_CBC, receipients);
Where receipients is a bacula 'alist' of X509_KEYPAIR instances.
- crypto_cipher:
Implement symmetric encryption support, using the crypto_session to
provide session keys, etc.
- crypto_sign:
Implements multi-signer, multi-algorithm RSA signature creation and
validation.
- crypto_digest:
Implements simple digesting (MD5, SHA256, etc).
I've tried to document the source code using doxygen-style comments,
and I think the API is fairly clean.
-landonf
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
