Hi, (I asked Chris to send this to the list, so just copying some my short notes that I replied in private mail before.) On 16/08/18 17:52, Christoph Anton Mitterer wrote: > 1) Is there any current known bug in LUKS2 / AEAD of cryptsetup/dm- > crypt/dm-integrity? > I read about the limitations of the GCM mode with the small nonces > (more on that below)... but apart from that... even though it's still > experimental... do you think I can use it and be safe (in terms of the > crypto)? There are many bugs, but most them are implementation things that are not related to security. LUKS2 as on-disk format should be ok but AEAD is still something I would better see to be analysed by some other people. > 2) I was reading through the release notes and parts of them kinda were > written as if MAC-then-Encrypt would be done wich has all kinds of > security issues as we know from TLS... Is this correct or does it use > Encrypt-Then-MAC? Everything is encrypt-then-MAC (both for native AEAD and combined mode), it is mentioned in the paper https://arxiv.org/abs/1807.00309 > 3) --sector-size > Does this also change the crypto block size? I vaguely think to > remember that some loooooong time ago when XTS was introduced, someone > said it wouldn't be safe to use with block sizes >512? > Or does this just set how many 512bit crypto blocks are written/read at > once to the underlying device? It is mainly about the crypto block. Limitation for XTS block is I think at most 2^20 AES blocks, we have maximum 4096 bytes sector size (because of the 4k page size), so this is not a problem. It should map to atomic unit of the device. With dm-integrity journal you can use this even for smaller sector, without journal you can get partial sector update on fail. (IIRC mentioned it in the paper above as well.) (You can set larger sector size even without authenticated encryption. And sometimes it helps a lot in the performance sense. If it is "safe" really depends on hw - with native 4k sectors it should be...) > 4) --integrity-no-journal > Manpage says it would be safe to use if journaling is done on a > different layer. > I assume this could be layers above OR below dm-crypt? > So what about e.g ext* filesystems with journaling or btrfs with CoW > enabled... are these safe to use without a dm-integrity journal? > Has the answer to this question been coordinated with the respective > filesystem developers? It should be above dm-crypt. But this is more complicated - you need to think what underlying dm-integrity is doing (store data + auth and IV tags to another sector. If a write is corrupted, you can corrupt even other sectors that shares metadata sector with tags...) TBH this need better analysis. Better ask on dm-devel list, I am sume Mikulas (as author of dm-integrity journaling code) can answer better. > 5) integritysetup options not provided in cryptsetup > integritysetup has a number of options not provided in cryptsetup, > e.g.: > --journal-size, --interleave-sectors, --journal-watermark, --journal- > commit-time, --tag-size, --journal-* > > How does cryptsetup choose these values? It is in the API structure, but we did not provide these option on commandline yet. So you get only defaults here. I think it need to be/will be implemented one day. > 6) v2.0.0-ReleaseNotes.gz side node > These release notes say: > FDE authenticated encryption is not a replacement for filesystem > layer > authenticated encryption. The goal is to provide at least something > because > data integrity protection is often completely ignored in today > systems. > Does the note that FDE AE is not a repleacement for fs lvl AE really > just refer to the "authentication/integrity protection part"? > Or does it also refer to the encrpytion part... cause I've always > assumed block layer disk encryption would be rather saver than just > plain filesystem level encryption (like there is e.g. for ext). > > Do I loose anything in terms of encryption security when I use the AE > as well? I mean it's ok if the integrity protection is not perfect,... > but I wouldn't want to loose anything in the encryption security > compared to what we have now. I would say both the algorithms (encryption, integrity) are the same for filesystem layer. What I meant is that with FDE we are missing a data context - you have one key for everything, one user can decrypt all data etc. You perhaps do not want this on multi-user system. My threat model does not protect to data replay (you can revert sectors from old copy). Filesystem usually have better approach (ZFS uses Merkle tree IIRC) and per-file integrity. I think filesystem can do better work here - but nobody merged this to mainline kernel yet. And seems encryption in fs (ext4 etc) is just doing what dmcrypt had 10 years ago... > 7) Are we going to see SHA3 anytime soon in dm-crypt/cryptsetup? E.g. > for HMAC in integritry... or for --hash? Kernel should support whatever hash/hmac is there. I perhaps limited this with fixed list of algorithms in userspace. (SHA3 has strange name like sha3-256, I think we had to fix the code to support it). But it will be terribly slow. Anyway, this should be supported in next release (2.1). Kernel interface should be ok already (I hope :) so you can play with dmsetup :) > 8) Something more important for me: > a) Which algos are already safe to use for encryption/integrity? > In the release notes you basically list these three: > * aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the > authentication tag. > * aes-gcm-random (native AEAD mode) > DO NOT USE in production! The GCM mode uses only 96-bit nonce, > * ChaCha20 with Poly1305 authenticator (according to RFC7539) > > But in another place it also says that Chacha20-poly1305 is affacted by > the small nonce: > > NOTE: Currently available authenticated modes (GCM, Chacha20- > poly1305) > in kernel have too small 96-bit nonces that are problematic with > randomly generated IVs (the collison probability is not negligible). > For the GCM, nonce collision is a fatal problem. > > b) So is only aes-xts-plain64 / with hmac-sha* safe to use? Or is even > that safe to use at all? It depends, what you expect. It is "safe" but I would better use random IV (so every write will regenerate IV). > c) Can I also use serpent-xts-plain64 / hmac-sha512 and will that be > safe? It will work, and definitely it will be "better" than without integrity protection but what is safe really depends on what you really expects. > d) Which key sizes (--key-size) would I need to use? > For aes-xts-plain64 I always used --key-size 512, which I think results > in AES256, right? With 256 bit for AES and the other 256 for XTS? It is the same as without authentication - XTS mode has 2 keys, so 512 => AES256, 256 => AES128. > But for AEAD with HMAC I'd need another key, right? What's --key-size > then? Or is it still 512 and crypsetup selects they auth key based on > the auth-algo? > And how would one need to set it for SERPENT? Yes. For AEAD modes, there is only one key (integrity is an integral part). For composed modes (XTS + HMAC etc) code internally calculates size of integrity key and adds it to the encryption key (keys are independent). So with this command cryptsetup luksFormat --type luks2 /dev/sdb -c aes-xts-plain64 --integrity hmac-sha512 --key-size 512 you will see Keyslots: 0: luks2 Key: 1024 bits (HMAC(sha512) => additional 512 bits) But for now, only some combinations are hardcoded. I will make this more configurable in 2.1. > e) Is there anything better in the meantime than: > [aes|serpent]-xts-plain64 > and > hmac-sha512 > ? I bet for AEGIS and MORUS in 4.18, see below. > 9) Authenticated encryption do not set encryption for dm-integrity > journal. > > Just wondered why this isn't a security problem? Isn't all data written > to the journal... and if this isn't encrypted...? Data are always encrypted. (dm-integrity journal handles encrypted sectors). Journal metadata are not encrypted yet. The problem here is that you can see particular pattern (which sectors are in journal) and that the metadata of journal are not encrypted. Attacker can mangle journal so journal reply can corrupt your data - but this corruption will be detected by AEAD later on read. > 10) We plan to use AEGIS and MORUS, as CAESAR finalists. > Are these then safer than aes-xts-plain64 / hmac-*? > I stumbled over a paper which shows that these algos fail pretty bad if > a nonce is reused: > https://eprint.iacr.org/2017/1137.pdf Nonce must not be reused here. That's why we use random IV - with 128bit nonce the probability of collision is negligible even if you write lot of sectors. With 96bit nonce you can get collision quite "soon". See Ondrej's master thesis - he described this very well https://is.muni.cz/th/qvh3t > 11) The persistent settings stored with --persistent... > Are these encrypted/integrity protected? Otherwise an attack could > trick a user into e.g. using TRIM even though he doesn't because of > security concerns. These are not encrypted, it is stored in LUKS header in JSON. Actually no change here - today it is stored in crypttab in not encrypted initramfs. You can trick user already today - bu modyfing crypttab. or binaries in initramdisk. You need to sign everything if you want to be safe (Qubes OS signs even LUKS header IIRC.) > Last but not least: > > > 12) Next to normal disk encryption (and in the future integrity > protection) like on a laptop,... I'd like to "abuse" cryptsetup/dm- > crypt for now to encrypt plain files, i.e. very large (~20GiB) dar > files that are backups of all my personal data and which I want to > write to tape. > Since this will be long term archival,... I'd like to > - triple encrypt with different algos (AES, SERPENT, <something else>) > - use a recent password hashing algo (Argon2*) I think I read your mail on some crypto list. Not sure if I can help here. (I agree with the comment there that the big problem is to remember passphrases after 20 years :-) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
