2 mention TPM as an alternative to a smartcard (thanks CodesInChaos)
source | link

No, that would not make sense.

A delay between attempts makes sense for online uses of passwords, for example to authenticate into a system. It makes sense when you have to go through a software “gateway” in order to access the system. After an incorrect attempt, the gateway can delay or block further attempts from the same origin. The delay works because the only way to reach the system is part of the system itself.

A delay between attempts doesn't make sense for offline uses of passwords, for example to decrypt some data. It's impossible to implement because the way to reach the system is not part of the system itself, so the adversary can implement their own password checker. Furthermore the encrypted data can be replicated, allowing the adversary to make many attempts in parallel (as many as they're willing to spend on hardware). If the attacker wants to make 1000 copies of the data and attempt to decrypt them on 1000 computers as fast as these computers will go, nothing can prevent them.

You can slow down the adversary by making the password verification intrinsically slow. An encrypted volume uses a key which itself is encrypted with another key which in turn is derived from a password. (Some badly-designed systems excluded.) The derivation of the password from a key, if done correctly, is a key stretching function which is intrinsically slow — the fastest known way to derive the key from a potential password requires a large amount of computation. In a well-designed system, you can tune the amount of computation; for example, with LUKS, that's the -i parameter to `cryptsetup luks. A larger parameter makes verifying the password slower, both for you and for the adversary.

Credit cards can afford to use a 4-digit PIN because they're an online system: depending on the card technology, either the PIN typed by the user is sent to the bank for verification (so the bank's servers implement the 3-failures-and-you're-out policy by recording the card as compromised), or verified by the chip on the card (so the chip on the card implements the 3-failures-and-you're-out policy by storing a “card is compromised” flag in its persistent memory).

You can encrypt your data with a key stored in a smartcard, instead of using a key derived from a password. This lets you have a very short password (e.g. a 4-digit PIN) that isn't ridiculously easy to break. It has downsides, however. You need to have the card with you when you want to access your data. You need to have a card reader available where you want to access your data. You need to back up your key somewhere, in case you lose the card or it fails. If your computer has a TPM chip, this can serve the same purpose as the smartcard, with the difference that the card can be carried between computers (useful for removable drives or remote volumes) whereas the TPM is tied to a motherboard (more convenient if the encrypted volume is on an internal drive).

No, that would not make sense.

A delay between attempts makes sense for online uses of passwords, for example to authenticate into a system. It makes sense when you have to go through a software “gateway” in order to access the system. After an incorrect attempt, the gateway can delay or block further attempts from the same origin. The delay works because the only way to reach the system is part of the system itself.

A delay between attempts doesn't make sense for offline uses of passwords, for example to decrypt some data. It's impossible to implement because the way to reach the system is not part of the system itself, so the adversary can implement their own password checker. Furthermore the encrypted data can be replicated, allowing the adversary to make many attempts in parallel (as many as they're willing to spend on hardware). If the attacker wants to make 1000 copies of the data and attempt to decrypt them on 1000 computers as fast as these computers will go, nothing can prevent them.

You can slow down the adversary by making the password verification intrinsically slow. An encrypted volume uses a key which itself is encrypted with another key which in turn is derived from a password. (Some badly-designed systems excluded.) The derivation of the password from a key, if done correctly, is a key stretching function which is intrinsically slow — the fastest known way to derive the key from a potential password requires a large amount of computation. In a well-designed system, you can tune the amount of computation; for example, with LUKS, that's the -i parameter to `cryptsetup luks. A larger parameter makes verifying the password slower, both for you and for the adversary.

Credit cards can afford to use a 4-digit PIN because they're an online system: depending on the card technology, either the PIN typed by the user is sent to the bank for verification (so the bank's servers implement the 3-failures-and-you're-out policy by recording the card as compromised), or verified by the chip on the card (so the chip on the card implements the 3-failures-and-you're-out policy by storing a “card is compromised” flag in its persistent memory).

You can encrypt your data with a key stored in a smartcard, instead of using a key derived from a password. This lets you have a very short password (e.g. a 4-digit PIN) that isn't ridiculously easy to break. It has downsides, however. You need to have the card with you when you want to access your data. You need to have a card reader available where you want to access your data. You need to back up your key somewhere, in case you lose the card or it fails.

No, that would not make sense.

A delay between attempts makes sense for online uses of passwords, for example to authenticate into a system. It makes sense when you have to go through a software “gateway” in order to access the system. After an incorrect attempt, the gateway can delay or block further attempts from the same origin. The delay works because the only way to reach the system is part of the system itself.

A delay between attempts doesn't make sense for offline uses of passwords, for example to decrypt some data. It's impossible to implement because the way to reach the system is not part of the system itself, so the adversary can implement their own password checker. Furthermore the encrypted data can be replicated, allowing the adversary to make many attempts in parallel (as many as they're willing to spend on hardware). If the attacker wants to make 1000 copies of the data and attempt to decrypt them on 1000 computers as fast as these computers will go, nothing can prevent them.

You can slow down the adversary by making the password verification intrinsically slow. An encrypted volume uses a key which itself is encrypted with another key which in turn is derived from a password. (Some badly-designed systems excluded.) The derivation of the password from a key, if done correctly, is a key stretching function which is intrinsically slow — the fastest known way to derive the key from a potential password requires a large amount of computation. In a well-designed system, you can tune the amount of computation; for example, with LUKS, that's the -i parameter to `cryptsetup luks. A larger parameter makes verifying the password slower, both for you and for the adversary.

Credit cards can afford to use a 4-digit PIN because they're an online system: depending on the card technology, either the PIN typed by the user is sent to the bank for verification (so the bank's servers implement the 3-failures-and-you're-out policy by recording the card as compromised), or verified by the chip on the card (so the chip on the card implements the 3-failures-and-you're-out policy by storing a “card is compromised” flag in its persistent memory).

You can encrypt your data with a key stored in a smartcard, instead of using a key derived from a password. This lets you have a very short password (e.g. a 4-digit PIN) that isn't ridiculously easy to break. It has downsides, however. You need to have the card with you when you want to access your data. You need to have a card reader available where you want to access your data. You need to back up your key somewhere, in case you lose the card or it fails. If your computer has a TPM chip, this can serve the same purpose as the smartcard, with the difference that the card can be carried between computers (useful for removable drives or remote volumes) whereas the TPM is tied to a motherboard (more convenient if the encrypted volume is on an internal drive).

1
source | link

No, that would not make sense.

A delay between attempts makes sense for online uses of passwords, for example to authenticate into a system. It makes sense when you have to go through a software “gateway” in order to access the system. After an incorrect attempt, the gateway can delay or block further attempts from the same origin. The delay works because the only way to reach the system is part of the system itself.

A delay between attempts doesn't make sense for offline uses of passwords, for example to decrypt some data. It's impossible to implement because the way to reach the system is not part of the system itself, so the adversary can implement their own password checker. Furthermore the encrypted data can be replicated, allowing the adversary to make many attempts in parallel (as many as they're willing to spend on hardware). If the attacker wants to make 1000 copies of the data and attempt to decrypt them on 1000 computers as fast as these computers will go, nothing can prevent them.

You can slow down the adversary by making the password verification intrinsically slow. An encrypted volume uses a key which itself is encrypted with another key which in turn is derived from a password. (Some badly-designed systems excluded.) The derivation of the password from a key, if done correctly, is a key stretching function which is intrinsically slow — the fastest known way to derive the key from a potential password requires a large amount of computation. In a well-designed system, you can tune the amount of computation; for example, with LUKS, that's the -i parameter to `cryptsetup luks. A larger parameter makes verifying the password slower, both for you and for the adversary.

Credit cards can afford to use a 4-digit PIN because they're an online system: depending on the card technology, either the PIN typed by the user is sent to the bank for verification (so the bank's servers implement the 3-failures-and-you're-out policy by recording the card as compromised), or verified by the chip on the card (so the chip on the card implements the 3-failures-and-you're-out policy by storing a “card is compromised” flag in its persistent memory).

You can encrypt your data with a key stored in a smartcard, instead of using a key derived from a password. This lets you have a very short password (e.g. a 4-digit PIN) that isn't ridiculously easy to break. It has downsides, however. You need to have the card with you when you want to access your data. You need to have a card reader available where you want to access your data. You need to back up your key somewhere, in case you lose the card or it fails.