Anyone trying to brute force your encrypted disk would be running the attack on their computer(s) against your disk headers. System parameters on your OS would be meaningless.
Edit
Per U. Windl's comment I looked more carefully. My original statement above is still correct, however iter-time is not a system parameter as I incorrectly assumed from the name.
iter-time is not exactly time at all, it appears to be iterations defined in what I would consider to be a strange way using time. Instead of a fixed iteration count, it is the number of iterations possible on that specific machine in the defined msec stated by iter-time. So yes the iter-time parameter is time, but it results in differing iteration counts as a function of the speed of that specific machine.
I found Linux-Blog – Dr. Mönchmeyer to be very informative.
A few quotes from the article I found interesting:
...It is the calculation of the Master Key which leads to huge delay
times. The aes-decryption itself is not a major source of the boot
delay time ...
This suggests that brute force pass phrase guessing is slowed, but raw key guessing would not be affected. Realistically raw key guessing would be hopeless anyway.
...One should also take into account that an attacker which got the
encrypted disk under his physical control would try to break LUKS
passwords on much faster machines than yours. So several 10 millions
PBKDF2-iterations per second are certainly possible - meaning multiple
password trials per second. ...
Thanks again to U. Windl for the kick to look further.
man cryptsetup
)? Your--iter-time 10000
would mean that a successful authentication would need more than three hours to succeed. That will definitely slow down any brute force attack, but maybe your laptop battery will be empty before having even authgenticated (unlocked) your LUKS device once.