[collectd] Authentication/Encryption for the network plugin.
Thorsten von Eicken
tve at voneicken.com
Mon Apr 13 16:26:32 CEST 2009
Just to throw yet another interesting consideration into the mix: how
about key rotation? In a unidirectional protocol I believe it requires
some external "control channel" which is outside of collectd most
likely. But it would be good if the receiver had the capability to
recognize packets that use different keys. This way the receiver can be
prepped with new keys and the senders can switch to a new key in a
loosely coupled manner.
I'll ask some more crypto-oriented folks than me about what's out there
that we could copy...
Florian Forster wrote:
> On Sun, Apr 12, 2009 at 08:41:17PM +0200, Florian Forster wrote:
>> Encryption is done without initialization vector (IV) and AES is set
>> up to work in cipher-block chaining mode (CBC). When talking with
>> Sebastian yesterday we realized that this allows for known plaintext
>> attacks if you have the network plugin set up to forward data using
>> encryption. So I will probably add a 16 byte IV and possibly rearrange
>> the parts a bit.
> actually, I didn't think enough. Using an IV doesn't help against known
> plaintext attacks. While the use of an IV doesn't prevent an attacker to
> use known plaintext attacks, it should prevent chosen plaintext attacks
> on the cypher itself, so it's probably a good thing nonetheless.
> Currently, the use of an IV is implemented using this layout:
> !T!L! IV !l! Hash ! Padding !
> IV == initialization vector (16 bytes)
> The part marked with ‘^’ is encrypted. Maybe we could improve the
> situation by using no IV and simply encrypt the ‘IV’ field in the
> We should think about using a different mode of operation, though:
> Output feedback mode (OFB) doesn't require input data to be a multiple
> of 16 bytes long, so we could avoid all that padding business. It
> results in some opaque buffer length calculations and feels quite error
More information about the collectd