Hello Kern,
Thank you. I did not remember to mention about the TLS Authentication. And this is a possibility of verifying the client (peer/FD) before data exchange between daemons.
I thought that Markus was talking about data authenticity and not FD authentication. In the first case, the goal is to assure the source of the data. This can be achieved using a MAC (Message Authentication Code) or pki digital signatures. The TLS Authentication (TLS Verify Peer = yes) used by bacula daemons are intended for entity authentication, which means that they (daemons) are sure that the other entity (the other daemon) they are talking to is who they believe to be.
In the case of a message authentication, in this case a backup data authentication or an entire volume authentication, the only way I see that is treated by the bacula cryptography implementation is when the data sent by the client is also encrypted (a crypto session is created for sending the data encrypted). That means that your data is firstly encrypted and then signed by FD. This assures data confidentiality, integrity and authenticity through the use of pki digital signatures.
I undesrtood that Markus was talking about generating a MAC or a hash+pki signature of the data sent by FD. And I was not able to see this in the bacula crypto open code. Also, in this case, the restore FD that was receiving the data from the first FD must have the public key of the FD that originated the data (in the case of a pki signature) or the symmetric key used in the case of a MAC.
Hope this helps a little more to clarify this thread.
Best regards,
Ana