On Wed 2015-02-18 16:24:51 -0500, goupille wrote:
> we received complaints from a user about the persistence
> encryption. basically, I don't really know what I'm talking about, so
> that's a resumee of that user's remarks (without the bad words) :
>
> AES : the fact that moderns hardware are shipping dedicated AES
> modules is a risk (potentiality of unknown features in those
> modules). the user proposes to use Serpent instead (which is less
> subject to that threat)
I would love to see something better than AES, but i have no way of
knowing whether SERPENT is better or worse than AES.
I agree that the hardware AES modules seem like ripe targets for
modification and compromise by powerful adversaries, though.
> SHA1 : using SHA1 today is very bad, SHA512 should be the default
SHA1 is bad in other contexts. For key derivation (PBKDF2 [0]), and
anti-forensic splitting [1] (which are the ways it's used in the
persistence volume), it is fine. The goal for key derivation is to
derive a high-entropy key from the user's passphrase in a way that
requires a lot of cycles for each guess. The goal for anti-forensic
splitting is to diffuse material among several blocks.
[0]
https://en.wikipedia.org/wiki/PBKDF2
[1]
http://clemens.endorphin.org/AFsplitter
SHA-512 is only marginally more effort than SHA1; Doubling the number of
iterations would be more effective than switching digests.
I don't know enough about AF splitting to know how choice of digest
affects it.
> keysize: with a keysize of 256 in XTS method the real keysize to
> factor against is already only 128 (if the everything else in the
> implementation is robust).
sure, that's why aes128 encryption in xts mode uses 256-bit keys, and
aes256 encryption in xts mode uses 512-bit keys.
> he seems to think that AES-128 is not safe at all against a government
> and doesn't trust so much AES-256. since there is no "significant
> performance hit", and due to XTS, the default keysize should be 512
> bits.
saying "i don't trust AES" doesn't automatically lead to "i trust
SERPENT". We're in an awkward spot here to make this decision. This is
not the kind of decision we should be expecting users to make, though.
> iteration time: it is low for slow systems, and Tails is aimed to work
> on relatively slow systems it should be increased
iteration time only has a cost during boot (persistence unlock). I
agree that spending extra cycles at boot is worthwhile.
--dkg
