Hi, I'll try to answer some questions here, but I should probably write some blog about it later. The whole idea of dm-integrity was to show that we NEED data integrity protection. Waiting for superior solution in fs does not not work. It has limits - but unlike as many proposed solutions in academic paper, it is in mainline kernel. But my combined academic/practical planned approach was one thing, and the reality is slightly different now. The basic idea was that we have two uses for dm-integrity - authenticated sector encryption (but without sector replay protection) (dm-integrity just provides additional space for sector authentication tag processed in dm-crypt above it; => cryptsetup/LUKS2 controls it) - non-cryptographic data integrity protection (dm-integrity standalone, data checksums are calculated in dm-integrity; => integritysetup controls it) The reality is that dm-integrity itself can use own cryptography like keyed HASH checksums (HMAC) but in the beginning this was not intended use (but Mikulas as author of this part convinced me and we support it in integritysetup). So my suggestion is - if you do not need encryption (confidentiality protection), and all you need is to check for hw/random failures, just use dm-integrity/integritysetup with some fast checksum - default is CRC32C and it works quite fine. Do not mess with slow hashes or even HMAC etc until you have some valid threat model where it helps to protect <something>. On 24/05/2020 13:45, asmqb7 wrote: > Approaching the dm-integrity/integritysetup documentation with a > (presently) poor/untrustworthy fundamental understanding of > cryptography, I'm not currently able to conclusively evaluate the > significance and semantic impact of the choices available for the > --integrity, --integrity-key-file and --integrity-key-size parameters. > Instead of copy-pasting random commands I've found on the Internet > that just happen to work, I don't want to proceed until I > comprehensively (if not fundamentally) understand the options > available and what scenarios each might be appropriate for. As said above, if you want only detection of random data corruption, do not use these. Just use non-cryptographic checksum like crc32. ... > *** HMAC-SHA* key configuration > > - Tracing from integritysetup.c through dm-integrity.c to > hmac_setkey() in /crypto/hmac.c in the kernel reveals that the > keyfiles used by dm-integrity appear to be used as initialization > seeds for the HMAC function. My current working theory/assumption for > why the the user is allowed/required to supply this data is that the > uniqueness and secrecy associated with a user-specifiable HMAC seed > holds defensive cryptographic value. Is this view correct, and are > there any non-secrecy-related reasons I might want to specify my own > HMAC seed value? It is just keyed-hash, so nobody without the key can calculate or change data integrity tag. Think about it as your secret key, it must be protected. > - What pathological issues might arise from providing HMAC seed values > of all-0x00, all-0xFF, 0x00..0x63, a repeating pattern, etc? Could > such highly-deterministic, low/zero-entropy keyfiles be considered > universally sane defaults, including for the purposes of automated > system installation, in scenarios where good data integrity is > strictly the only consideration? (I would be particularly partial to > all-0x00, because then I could do --integrity-key-file=/dev/zero.) Do not do that. If you do not need HMAC do not use it all. In this case just use plain hash (--integrity sha256 for example; note you need to set it in each open command - this is a misconception though). But as said above, crc32 is usually ok, it takes only 4 additional bytes and it is faster. It really depends what are you trying to protect - if all you need is to detect random bit/byte change, using cryptographic hashes is overkill. > - Apparently correct key lengths are 32 for SHA256 (256/8) and 64 for > SHA512 (512/8). Do I understand correctly that longer keys will be > truncated, while shorter keys will be zero-padded (specifically > -suffixed)? In integritysetup, you can set key size as you want, HMAC padding is done by the kernel crypto inside the kernel. See kernel crypto API doc (it is basically rfc2104 padding). > *** Integrity algorithm selection > > I was curious if the "crc32c" and "hmac-sha256" options noted in the > manpage (as of May 2020) represented the full list of algorithms > accepted by the integritysetup For algorithms, integritysetup should accept all algorithms available in running kernel. There is actually no dynamic listing of all variants. (Note, for LUKS2 we hardcode and allow only some algorithms, but integritysetup is just direct interface to dm-integrity/crypto API.) > - CRC32 (which is weaker than CRC32C) and "crct10dif" (T.10 DIF CRC16, > basically half of CRC32) are probably universally unsuitable; Why? CRC32C just use different polynomial IIRC and we set is as default because it is hw accelerated on Intel CPUs. crc10dif is meant for HW that allows native data integrity fields (512 + 8) bytes sectors drives. Do not us it outside of this context (despite it probably works). Again, I think you need to define what (against what/who) are you want to protect, and also avoid over-engineering it. If you really need cryptographic hash, I would say stay with SHA256. But this is for different discussion. (SHA1 could be disabled later, many others are terribly slow etc.) If not keyed, collisions do not matter (attacker can recalculate it anyway). [I'll stop here, nobody reads so long mails :] Anyway, we will check the error message reports later, there should be more sensible checking and error reporting than just syslog messages. Thanks for these comments! Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
