> It was my understanding that the HMAC key needed to be secret even > when used for verification. (Otherwise people could forge an HMAC.)
Correct. >From what you wrote, I understand you're using crypto for files. When one thinks of the H(filecontent) as the 'sector number' and the file itself as the content stored in that indexed sector, you're right smack in area of disc encryption systems. I assume you've checked out the systems used there, e.g. ESSIV, TrueCrypt, etc.etc.. This list's archive is littered with concepts and subsequent ample and dire warnings against rolling your own crypto systems (that's including mixing crypto components into something new and improved), so I'll consider that water under the bridge. Heck, sometimes we need something 'custom' so better make sure it's as solid as we can make it. Regarding IV: when you are going to encrypt the file data, a chaining mode is indeed advised. CBC is the classic choice but as you mentioned before it requires no recurrence of the IV (unique IVs), but it /also/ requires /unpredictable/ IVs to have a chance to work. CBC mode is not an authenticating mode, so you'll need a MAC to go with that at least, otherwise edits to the ciphertext can simply pass into the decrypted plaintext undetected, which would be a bit embarrassing. What I see in most of those disc crypto designs is that IVs are mostly generated using H(Key) constructs, i.e. hashes of keys instead of keys directly; you're using a supposedly independent key, which should be fine as well, as that's the other choice going around a lot. Nevertheless, have your design reviewed by a few professional cryptoanalysts anyhow. I have not been trained for that. I don't see any glaring issues in your crypto design. Meanwhile you have another threat vector lingering there: you are worried about your keyfile for the HMAC, for one. Which means you perceive a possible threat originating from the system you're running on, at least from folks who can run a local or remote 'ps' on your critical box. 'critical' because the box carries secret key data on disc and in RAM. That means you have a threat vector going straight through your operating system's access control (those darn rwxrwxrwx bits on UNIX) plus another threat vector going 'around' your OS ACL and only memory protection to guard against it: when I can run ps, I can run another binary, which can dump all RAM content for me [*], unless the box has serious memory protection features preventing me from doing just that, and that leaves out 'dd'-ing the disc with your keyfile on it and cold boot attacks and what have we; I don't need your keyfile if I can get at it's equivalent in RAM or rip the disc it's sitting on. And there's no crypto countermeasures in there for those attackers there, is it? Is that okay with you? 'yes' is an acceptable answer; it's just that you need to consider /all/ threat vectors, rank them (level of risk: occurrence probability, severity of impact, amount of effort available to prevent them), and list the ones you don't want to mind about: every system has it's conditions and limitations that way. Listing threat protection as 'Operating System only' is okay, as long as it's listed. Sounds to me like you did, but I'm doublechecking here. [*] yes, yes, yes, guest can run ps but not 'install' his own binaries, let alone compile his evil gadgets. And no 'dd' for that evil s.o.b., ever! Absolutely. Meanwhile, allow me to write files and fiddle their x bit for me, and with a bit of extra effort I can transfer my evil binary onto your box and take it from there. Which means your admin has to be extra special careful with the evil dudes on there. Note that by worrying about your keyfile(s) like that, using that 'secure' word, you're implying that you are running your crypto system in an 'environment considered hostile' and that's a /very/ large can of worms you opened right there. Because 'secure' is weighted against your maximum effort, not your minimum (which is letting others, such as the OS, cope). So either it's not an issue your system will protect against, really (i.e. a threat vector listed as 'not protected against beyond the ability of the operating system' -- one human error is enough to get at the goodies), or you need to sit back and rethink the system. Given that you intend to apply the full cryptographic strength available today against attackers who can read those backup files, the question to pose to yourself is: against whom do you want to protect? How much? I.e. where are your attackers? How can they touch you? And which ones do you ignore == list as the responsibility of other systems/parts, such as 'the operating system' or 'the firewall'? Which are viable choices. Basic approach is that you're aware of all your systems conditions and limitations, threat-wise. That's also why, in designs such as yours (backups secured against unauthorized access) firewalls and other components play an important role in protection against threats. Compare your current design description with TrueCrypt, which also provides cryptographically secured data storage, which one can use for backups; TrueCrypt protects your data against being stolen outside the realm of your secure environments where you access the data. (Note the use of 'environment' instead of merely 'machine'.) When the data is stolen while you [have the ability to] access it (think TrueCrypted USB stick plugged into your machine and you having run the TrueCrypt driver and entered your passphrase to access the data a while ago), chances are high that your keys are stolen along with it - because you can expect your system to be compromised that much. If you wish to create a system which surpasses the ability of TrueCrypt and its brethren, you'll need to do more than they do. The first action there is to make sure you run your crypto in a secure environment. (Thought exercise: why is it bloody dangerous to go into an internet shop and log into your https, thus safely TLS/SSL crypto protected, webmail or worse: your bank account? Even when you're the owner and sole root/admin of said shop, there's no windows, Faraday mesh around you and your machines in all 6 directions, no equipment or gadgets anywhere that you haven't explicitly approved and nobody is currently in the house but you? Answer that and suddenly 'access control' and 'secure' in one sentence are only good for a snigger. Bloody customers, eh. Next, turn around and have a look: any similarities between this scenario and yours? There's one, at least.) On Fri, Oct 2, 2009 at 2:21 AM, Michael D. Adams <mdmko...@gmail.com> wrote: > On Thu, Oct 1, 2009 at 4:37 PM, Kyle Hamilton <aerow...@gmail.com> wrote: >> The question becomes more one of: Why does the OP need to keep the >> HMAC computation key secret? Is the OP using the same key for HMAC >> calculation as for symmetric encryption? (If so, why? If not, why >> does the OP need to keep the verification key secret?) > > I'm not using the same key for HMAC as for symmetric encryption. > > > But you ask a fair question (i.e. Why keep the key secret?) and I'll > try to answer. I'm not using an HMAC for message authentication, but > for a more indirect purpose. (I apologize in advance for the length, > explaining "why" requires a little context.) > > I am working with a backup system where the files are stored and > referenced by their hash (similar to how git stores it's data). I > would like to make it be able to store those files in encrypted form. > In order for this system to work, we want two different encryptions of > the same file with the same key to produce the exact same result. > This rules out using a random initialization vector (IV). > > With the exception of SIV (which isn't yet widely implemented), my > understanding is that reusing an IV for two different messages opens > up avenues of crypto-analytical attack. Thus we want to use a > different IV for each file, but use the same IV when the file contents > are the same (*). The obvious choice is to use a cryptographic hash > of the file's contents as the IV. It will be the same when the file > contents are the same, but different when the file contents are > different. > > Now that works great except for one thing. For simplicity of > implementation, we would like to store that calculated IV in clear > text as a header at the front of the encrypted file and then just use > one of the block-cipher modes that remains secure even when the IV is > known to the attacker. However, storing the IV in the clear opens up > a dictionary attack if the attacker can easily compute the hash used > to compute the IV (**). > > To get around this, I was planning on using a secret key with an HMAC > (so the attacker couldn't compute his own hashes), but passing that > key on the command leaks that secret key. > > To summarize: > > I would have done this: let IV = Hash(file) in concatenate(IV, > encrypt(IV, Key2, file)). > Except that sending IV in the clear opens a dictionary attack on the > contents of file. > > So to fix that I was going to do this: let IV = HMAC(Key1, file) in > concatenate(IV, encrypt(IV, Key2, file)). > Except that doesn't gain anything over the previous one if Key1 isn't > kept secret. > > So now what I'm thinking is to do this: let IV = > encrypt(one-block-mode(***), Key1, Hash(file)) in concatenate(IV, > encrypt(IV, Key2, file)). > > Again, sorry for the length, but I hope that de-mystifies some of why > I want to keep the key secret. > > (*) Yes, this would open up a dictionary attack if the attacker could > use the backup system as an encryption oracle. Fortunately, due to > external factors, in our situation the attacker can't inject arbitrary > data into the backup system and thus can't use it as an oracle. > > (**) This is the same dictionary attack as in "(*)" except that now > the attacker is attacking the IV and doesn't need to use the backup > system as an oracle. He can just run the hash algorithm himself. > > (***) We don't need a block-cipher mode here (it's basically ECB mode) > if we ensure that the hash length matches the cipher block length. > > Michael D. Adams > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
