Re: [Fed-Talk] File encryption for Mac
Re: [Fed-Talk] File encryption for Mac
- Subject: Re: [Fed-Talk] File encryption for Mac
- From: "Timothy J. Miller" <email@hidden>
- Date: Mon, 19 Sep 2005 12:58:38 -0500
Michael Pike wrote:
So my thought is that the
encryption is only as strong as the OS X Keychain.
When I change my passphrase, it does NOT change the key used to
encrypt the AES128 volumes. The issue I have with this is if someone
manages to get my encrypted disk image, they could brute force attack
it, without fear of the key changing. I typically change my
passphrases on a regular basis, just to find the AES128 decryption key
never changes, which I do not like.
Correct on both counts. Not cycling the bulk key periodically is a
weakness. It's not much of one, however, given the current status of
attacks against AES.
Republican representative requesting back doors for all encryption
modules. Seems to me any "standard" would encompass such a
technology.
There's a big difference between a backdoor in the *algorithm* and a
back door in the *cryptosystem*. The AES *algorithm* has no back door.
Rijndael was publicly developed and vetted during the competition.
The OS X FileVault *cryptosystem* may have a back door. In fact, it
*does* have a back door--the Master Password. But you (or your IT
department) get to set that, so that's not what you mean.
Whether or not an additional backdoor exists--say, by encrypting the
bulk key under a key owned by the NSA--can only be shown by a code
review or by stepping through FileVault key generation to see if it's
stored anywhere else than in the Keychain and under the master password.
How good are you at PPC assembler? ;)
FIPS requirements mandate certain criteria for generating "random
keys". Apple is currently not certified with FIPS because they do not
"meet" this "standard" - this is DESPITE the fact that Apple's random
number generator is actually superior in technology than the FIPS
standards mandate. Makes me wonder why a standard would be imposed,
and a vendor denied FIPS compliance even though their cryptographic
technology is superior to what is being mandated.
You'll have to ask NIST, frankly. 140-2 annex C lists no approved
non-deterministic RNGs. I didn't participate in RNG commenting, so I
have no idea why this is. It may simply be that non-deterministic RNGs
are difficult or impossible to formally validate, and FIPS compliance is
*all* about validation.
Of course, it's entirely possible (and preferable) to use a
deterministic RNG with a non-deterministic seed, so I don't see a
difference either way.
Also, please note that AES128 is the standard for "non-classified
information", aka, "anything of national security cannot use it".
That tells me someone in the government must feel AES128 is not all
that secure. If it's approved for classified data, then I'll trust
it.
CNSSP-15 allows the use of AES128 and AES256 for classifications up to
SECRET. Above that, you start to get into really complex requirements
for key generation, storage and handling, but you *can* use AES256.
See: http://www.nsa.gov/ia/industry/crypto_suite_b.cfm?MenuID=10.2.7
-- Tim
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden