* Who is concerned by security (devices or the bus)?
If security is a concern of devices, several different security modes can be
used in the same time on the bus. (A device may accept several modes, with
several keys, for accepting messages, and for sending messages.)
If security is a concern of the bus, only one security mode is used for
all devices.
For simplicity, the proposal tested here assumes a security at the bus level.


* Two layers
- A "security" layer: binary, with public data and a ciphered payload.
- An "application" layer: json, the usual xAAL format, the ciphered payload.


* The security layer:
- big endian (network order)

- version (16 bits):
. major: unsigned 8bits
. minor: unsigned 8bits

- targets_nb: unsigned 16bits

- targets:
. targets_nb x 128bits (uuid)

- public nonce:
. seconds since Epoch (unsigned 32bits), the timestamp
. micro seconds (unsigned 32bits)


* The application layer, the payload
- json
- The usual xAAL format except: version, targets, cipher, signature, timestamp
  (Already provided by the security layer)


Note about changes in the API between this release and the non-ciphering
release: The "bus" object is feeded with a list of wanted targets (uuid in
binary format). So, the "bus layer" is about to filter wanted messages
before decript.


Note that the "additionnal data" passed to crypto_aead_chacha20poly1305_(en/de)crypt
are composed of version+n+targets. The nonce is public, present in messages
but is already taked into account by ciphering methods. So, the nonce is not
part of the "additionnal data".


Note about using such a timestamp as the ciphering nonce:
- The "millennum bug" soon after Sun Feb  7 07:28:15 2106
- Coding micro seconds (10^-6) requires 20 bits
  Coding seconds since Epoch (00:00:00 1970-01-01 UTC): today it uses 31 bits.
  Most of them are static. In one hour (3600s), 12 bits are changing.
  As a result, the entropy of such a nonce is only of 32bits!
- However, the receiver can "check" the nonce (and reject old timestamp)


Cons:
There is a fussy separation between the two proposed layers: xAAL adresses
are used both within the security layer (targets, in a binat form), and
within the application layer (source, in a textual form).
The library tested here rebuild a json list of targets adresses in the
textual form in order to present it to applications...