On 12/10/2019 5:43 AM, Jeffrey E Altman wrote: > On 12/10/2019 4:47 AM, Harald Barth wrote:
>> [...] I'd rather have something on the rx level to prevent this >> happening, so what can be done? > > Stop using rxkad. Proper integrity protection is provided by rxgk > which AuriStorFS sites have deployed for many years now. > > Jeffrey Altman To provide a bit more detail on what you can expect with rxkad. The rx packet header has a security class specific field (aka cksum) which is used by rxkad to store a checksum of the packet header fields. This checksum never protects any of the packet's data payload. When rxkad operates in "auth" mode, the connection's key is used to perform an encrypt operation of zero bytes of data. No data integrity protection is provided. When rxkad operates in "crypt" mode, the connection's key is used to encrypt the entire data payload. A 32-bit integer data checksum field is prepended to the encrypted data payload in the packet; but as observed this field has always been set to zero and is never checked by the receiver. In summary, rxkad only ever provides integrity protection for the rx packet header and never provides integrity protection for the data payload. For comparison, rxgk auth mode provides integrity protection by constructing and verifying an rfc3961 get_mic operation on each packet's data payload. https://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-11#section-8.7.2 and rxgk crypt provides for both integrity protection and data privacy by use of an rfc3961 encrypt operation. https://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-11#section-8.7.3 Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
