Messages in this thread | | | Date | Sat, 25 Sep 2004 06:07:10 +0200 | From | Andrea Arcangeli <> | Subject | Re: mlock(1) |
| |
On Fri, Sep 24, 2004 at 11:29:58PM -0400, Valdis.Kletnieks@vt.edu wrote: > loop-AES stuff does and forces a minimim 20-char passphrase) - there's going to > be all too many blocks in the swsusp area that are "known plaintext" and easily
well, it's not a filesystem with superblock at fixed location for example, the data location and contents is mostly random, or certainly not a "known plaintext". Brute forcing cryptoloop is probably a joke compared to brute forcing cryptoswap. But I sure agree a more secure method is welcome (if it exists ;)
My point is simply that if the hashed key is stored in a known location (and it has to, or the resume procedure couldn't find it either), the same brute force plaintext attack would work on the hashed key too (perhaps slower). Or am I missing something about crypto here? Is it the induced slowdown what provides higher protection? the algorithm is one way anyways, so it's not that the hash is the one that prevents reversing it from the plaintext. Brute force is still against the passphrase and nothing else, hence the same complexity (though slower with an additional hash to compute plus lots more bits of key for each brute-force try).
with GPG and SSH the real powerful thing is that the attacker has no access to your .gnupg and .ssh directory with the private secret keys, but if he had access, brute forcing it shouldn't be more difficult than brute forcing a single passphrase, if the private key is known the only unknown bits that provides security are the ones of your passphrase. But again, I may be missing something about crypto here, corrections welcome so I can learn too ;).
> So in order to make it at all secure, we really need to save on the disk > a key with O(128 bits) of entropy, perturbed by enough bits that are *not* > to be found anywhere on the machine so that it isn't a slam-dunk for an attacker.
if they're "not to be found anywhere", how can resume find them? ;)
> Do any of the crypto experts lurking have ideas/opinions on just how many > bits we need to store externally (be it in a USB dongle, a thumbprint, a > passphrase, whatever)?
I think as many as we can, since I'm afraid it's the only protection we get. But here we've the huge advantage of not having known plaintext in known places on disk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |