RFD 169 Encrypted kernel crash dump about rfd HOT 7 OPEN

You have an HMAC but only over the first N bytes to reject bad keys. Using a cipher without some sort of packet integrity may enable self-healing block-splicing attacks. Now ChaCha20 isn't CBC, it's CTR, BUT even CTR-mode ciphers need some sort of integrity protection. In SSL, ChaCha20 is paired with Poly1305. Poly1305 has ChaCha20 properties, as it comes from DJB as well.

from rfd.

Is the concern that the dump might be tampered with? We're definitely not trying to make the dump tamperproof -- we're trying to prevent it from being seen in cleartext by the attacker.

from rfd.

from rfd.

If tamper-proofing is not a concern, that needs to be documented as such. Others will notice encryption-with-no-integrity and get their reflexes triggered. Please be ready to address it. I may even be missing reasons why it's important beyond tamper-resistance, but I'm pretty sure you don't have to worry about it for tampering reasons (at least in the short-and-medium-term).

from rfd.

(there is currently no way to disable dump encryption once enabled).

I don't follow this sentence. If I enable encrypted dump on my machine with dumpadm -k ..., I can never disable it in the future? I understand that once a particular core is encrypted the only way I'm reading it is by decrypting it with the correct key; but it seems you are saying that once you enable encrypted dump on a box there is no going back. That is, I can't later disable encrypted dump for future crashes. If that's the case, I don't understand the reasoning.

Also, what about changing the key? I imagine you can just rerun dumpadm -k? If so, might want to call that out explicitly.

from rfd.

I have updated the RFD to address @danmcd's concerns (calling out that this is not to prevent tampering) as well as to change the implementation to allow for spontaneous upgrades.

from rfd.

@rzezeski: There is no way to disable encryption without rebooting -- I'll clarify both the RFD and the docs.

from rfd.