5 ms·

Good luck with people like me. As ypu know, luks per default allows over 8 megabytes of key, so, i just make a dev/urandom file that is up to the byte filling t

Good luck with people like me. As ypu know, luks per default allows over 8 megabytes of key, so, i just make a dev/urandom file that is up to the byte filling the top default keysize, which means a password of over 8 million characters, of which none or very few at best are found via the keyboard. I use at the minimum 8 million chars on all my luks devices. And I've set the key stretching to take above 15 mins to unlock, even with the right password, so good luck with John the ripper.

newnewpdro 7y ago
Where are you storing that? Is it then encrypted with a passphrase?
unixhero 7y ago
How do you modify the to e required between attempts?
- unixhero 7y ago
  *time
dharmab 7y ago
Either the key is stored unencrypted on a physical device, which can likely be seized by an attackers who has access to the ciphertext, or is encrypted with a passphrase. This isn't doing anything the master key and passphrase isn't already doing. (The key you input is not the key used to encrypt the data.)
- acqq 7y ago
  The advantage of using a long key (generated randomly) is that bruteforcing of the material protected with the key is impossible, which does matter in some scenarios: specifically, if one trusts the container format, knows that the container will be accessible to the potential attackers who can try to brute force it, but also knows that the rest (the long key used) won’t be accessible to the said attackers. Which can be a reasonable scenario. Whoever uses a password manager should use reasonably long keys generated randomly. The real problem, like always, is key management. And knowing what is “overkill” for a given scenario, i.e. where reasonability ends. 8 MB is really something that should have some additional reasons than just protection from brute forcing the key.
corndoge 7y ago
Seems like a nice practical setup
loeg 7y ago
I have to assume this is a joke. If it isn't, well. There's not a lot of reason to use more than 32 bytes from /dev/urandom. The extra 7.97 MB of key aren't doing you any favors, nor is 15 minutes of unlock time helping — zero seconds would be fine for this use.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]

newnewpdro 7y ago

Where are you storing that? Is it then encrypted with a passphrase?

unixhero 7y ago

How do you modify the to e required between attempts?

unixhero 7y ago
*time

dharmab 7y ago

Either the key is stored unencrypted on a physical device, which can likely be seized by an attackers who has access to the ciphertext, or is encrypted with a passphrase. This isn't doing anything the master key and passphrase isn't already doing. (The key you input is not the key used to encrypt the data.)

acqq 7y ago
The advantage of using a long key (generated randomly) is that bruteforcing of the material protected with the key is impossible, which does matter in some scenarios: specifically, if one trusts the container format, knows that the container will be accessible to the potential attackers who can try to brute force it, but also knows that the rest (the long key used) won’t be accessible to the said attackers. Which can be a reasonable scenario. Whoever uses a password manager should use reasonably long keys generated randomly. The real problem, like always, is key management. And knowing what is “overkill” for a given scenario, i.e. where reasonability ends. 8 MB is really something that should have some additional reasons than just protection from brute forcing the key.

corndoge 7y ago

Seems like a nice practical setup

loeg 7y ago

I have to assume this is a joke. If it isn't, well. There's not a lot of reason to use more than 32 bytes from /dev/urandom. The extra 7.97 MB of key aren't doing you any favors, nor is 15 minutes of unlock time helping — zero seconds would be fine for this use.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]