Well, I think this is really not bug - I'll try to explain why it is so slow here.
Note "Iterations" value for keyslots: > Key Slot 0: ENABLED > Iterations: 165980 > Key Slot 1: ENABLED > Iterations: 435577 The # of iteration is calculated during luksFormat on the machine where it is formatted/added new key (there is internal benchmark and it calculates selected hash + PBKDF2 per second). The calculated value is then used in keyslot, so on the same machine keyslot should be opened in cca 1 second (depends on system load). 1) If you move such disk to other machine, it can calculate significantly longer time (or quicker)! 2) The slots are scanned in sequence, beginning from slot 0. So opening passphrase in slot 1 includes time to decrypt slot 0. (The time for successful and unsuccessful attempt is the same). So, for 1) - you can specify iteration time manually (using -i paramater) if you know that device will be used on slow machine. (You can also add new keyslot with the same passphrase with lower iteration count and then delete old keyslot - so it is fixable even for old LUKS devices). for 2) there should be option to specify which slot to use (if you know that you want always open keyslot 1). (seems that it doesn't work for CLI now, if you want that please report bug upstream and I'll try to fix that for luksOpen.) Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
