[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...
	TvE

Florian Forster wrote:
> Hi,
> 
> 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
> header.
> 
> 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
> prone.
> 
> Regards,
> -octo



More information about the collectd mailing list