Re: Secure Command Line MAC Computation
(OT) just kidding. * Michael S. Zick wrote on Thu, Oct 01, 2009 at 16:44 -0500: Everbody in the same room should be sufficiently security qualified to see anything typed within that room. cheating pupils in school exams probably won't agree, neither will people who are writing love letter SMS in the subway. In some installations, the red lights on the walls and ceilings flash and the screens are all blanked if someone with less than a certain minimum security qualification level is allowed entry. And if that unqualified person unblanks a screen and types ps -f : simple, shoot them. Isn't it safer to make `ps -f' have no effect even in this case? Or in general, if some big treat or risk can be reduced a lot for a cheap prive, why not simply do it... Saves ammo. :-) (I was one of the guys that carried the gun in the room for years.) I assume those rooms had no windows. Wasn't the gun smoke an issue after shooting someone? So not using cat also is not only healthier for the typing guy but also for the others in the room - second hand smoke is a real killer! SCNR :-) oki, Steffen About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu October 1 2009, Michael S. Zick wrote: On Thu October 1 2009, Michael D. Adams wrote: On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt g...@hobbelt.com wrote: A note about your mention of 'security leak': when you are worried about adversaries who can run 'ps -l' on your machine, then you're essentially worried about adversaries with plenty of access to your machine, so they'll quite probably be able to 'cat' that keyfile Any normal user on a Linux machine would be able to see 'ps -f'. But to 'cat' the keyfile or coredump the app, they would need to either (1) have root access, or (2) have cracked the machine. In my mind there is a large leap between 'normal users could get this secret info' and 'user's with root access could get this secret info'. I'll stick by this part of my post: Misplaced security barrier - - - - - Other than those operational procedures, you should at least write your own application that does not disclose what you want hidden. Which might be anything from a small script to tons of compiled code. The actual solution depends on your situation, the principle remains. The question remains, what do I mean by Misplaced Security Barrier? (And I will avoid the artifact of second hand smoke this time.) If it is only the file data that needs protecting; then an example might be similar to the GIT utility with a Truecrypt volume for the data store. That puts the security barrier at the Truecrypt boundary. From the content of the other posts, that will not give you the solution you are seeking. Considering a generalized Content Identification Filesystem - where the content ID is a replacement or substitute for the pathname/filename - A flat file system where only a secure hash of the content is the access token, rather than its storage location expressed as a pathname/filename. Just to give the above puff of smoke a bit body, consider - In a medical records system the information access token might be the patents name and social security number - something you don't want 'published'. So you have substituted a secure hash of that information for the access token. But from the original post, I read that you don't want that secure hash 'published'. You want the 'security barrier' between the keyboard clerk and the access token. Just like you don't want the keyboard clerk to type the name number (I.E: 'non-published'); you don't want the keyboard clerk to type the secure hash (which would, in this example, also 'publish' it). Here, you want your security barrier between the 'published' and 'non-published' at the clerk's input part of the system. (to protect any traces of what the clerk types from others - by any means, system or physical snooping.) Which gets you to the second part of my post - you'll have to write something. I.E: hide the transition from 'published' to 'non-published' inside of code and then protect that code and its execution. Mike Mike Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
Michael D. Adams mdmko...@gmail.com writes: On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt g...@hobbelt.com wrote: A note about your mention of 'security leak': when you are worried about adversaries who can run 'ps -l' on your machine, then you're essentially worried about adversaries with plenty of access to your machine, so they'll quite probably be able to 'cat' that keyfile Any normal user on a Linux machine would be able to see 'ps -f'. But to 'cat' the keyfile or coredump the app, they would need to either (1) have root access, or (2) have cracked the machine. In my mind there is a large leap between 'normal users could get this secret info' and 'user's with root access could get this secret info'. To get a bit off-topic from this: This is a problem that people run into on a pretty regular basis, that ps reveals information they don't really want it to reveal. I have run into it myself with the environment, where an environment variable was the only straightforward channel I could find to communicate a secret between a Web server and a CGI program. Apart from tradition, is there an inherent reason that ps has to reveal things like command-line arguments and the environment to all users? Modern Linux systems get it from proc files, which by tradition have permissions which allow access to this information, but whose permissions could be more restrictive with a small kernel change. IIRC, other Unix systems use a setuid ps that reads the process's memory directly, so changing ps to not reveal the information would be sufficient. It seems that some flexibility is possible; I notice the Linux system I'm on right now doesn't allow access to the environment via ps, while the Solaris machines I used several years back did. Scott. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Secure Command Line MAC Computation
How would I securely compute a MAC for a file? The obvious way (below) has a security leak as it puts the key on the command line which other users could easily observe with ps -f. $ openssl dgst -sha1 -hmac key file I would have thought that something like openssl enc has with -pass file:keyfile would be available, but I haven't been able to find an equivalent for openssl dgst (even the 1.0beta's -macopt flag doesn't do this). Am I missing something here? What is the proper way to compute a MAC on the command line? Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
;-) Of course, you always could go an use shell backquoting, e.g. dgst -hmac `cat keyfile` ... assuming the 'keyfile' is in the proper format already. A note about your mention of 'security leak': when you are worried about adversaries who can run 'ps -l' on your machine, then you're essentially worried about adversaries with plenty of access to your machine, so they'll quite probably be able to 'cat' that keyfile (proper access control (ACL) being the only thing keeping them from doing so) and/or coredumping your running [OpenSSL] app so they can get at the key in RAM through the core file at their leasure. The other kind of 'adversary' that's to consider when using a screen (with or without commandline) is the observant individual nearby or far away, who can read what you type or see what is visible on your screen (keys and passphrases which are not 'starred out'). If the latter blurb has you going 'whoa! over the top!' then no worries; just a friendly reminder. threat analysis can quickly make you go 'oh sh*t' and it's never simple. You asked about 'how do I /securely/ ...' (emphasis mine) so I thought a little nudge would be good. In some environments some words carry more meaning than a simple 'lunch'. (Why do I get these goosebumps now while my brain delivers the quite unwanted words 'politically correct' in my neocortex? eek!) When your purpose is to have the command run in a 'any viewer cannot directly glean key from screen or tasklist while I run this' the `cat file` backquoting will suffice. Otherwise, I'd say it's the 'proper way' to calculate a [H]MAC. On Thu, Oct 1, 2009 at 9:20 PM, Michael D. Adams mdmko...@gmail.com wrote: How would I securely compute a MAC for a file? The obvious way (below) has a security leak as it puts the key on the command line which other users could easily observe with ps -f. $ openssl dgst -sha1 -hmac key file I would have thought that something like openssl enc has with -pass file:keyfile would be available, but I haven't been able to find an equivalent for openssl dgst (even the 1.0beta's -macopt flag doesn't do this). Am I missing something here? What is the proper way to compute a MAC on the command line? 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
Hello, owner-openssl-us...@openssl.org wrote on 10/01/2009 10:24:11 PM: Ger Hobbelt g...@hobbelt.com Sent by: owner-openssl-us...@openssl.org ;-) Of course, you always could go an use shell backquoting, e.g. dgst -hmac `cat keyfile` ... assuming the 'keyfile' is in the proper format already. admin# echo 100 /tmp/p.txt admin# sleep `cat /tmp/p.txt` [1] 21988 admin# ps -ef | grep sleep | grep -v grep root 21988 3150 0 22:29 pts/000:00:00 sleep 100 Best regards, -- Marek Marcola marek.marc...@malkom.pl __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
`cat keyfile` is processed by the shell, not by OpenSSL. That means that the backquotes are processed and stripped before the OpenSSL process ever sees it, which means that the shell is going to execute the cat and then will execute the dgst with the commandline including the contents of the cat. Which means that the ps problem actually still exists: $ openssl dgst -hmac `cat keyfile` -sha1 file - $ openssl dgst -hmac 'whatever keyfile contains' -sha1 file Other than that, I agree with your analysis. (Note that keyfile can be a binary file in this method, and the shell won't get confused, since it just puts the output of the cat into a single **argv. This expands the number of possible hmac keys from the union of possibility and the effect of the shell's metacharacter modification to the union of possibility. But, remember that you need to *not* include a newline at the end of the file, unless the newline is part of the key.) 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?) -Kyle H On Thu, Oct 1, 2009 at 1:24 PM, Ger Hobbelt g...@hobbelt.com wrote: ;-) Of course, you always could go an use shell backquoting, e.g. dgst -hmac `cat keyfile` ... assuming the 'keyfile' is in the proper format already. A note about your mention of 'security leak': when you are worried about adversaries who can run 'ps -l' on your machine, then you're essentially worried about adversaries with plenty of access to your machine, so they'll quite probably be able to 'cat' that keyfile (proper access control (ACL) being the only thing keeping them from doing so) and/or coredumping your running [OpenSSL] app so they can get at the key in RAM through the core file at their leasure. The other kind of 'adversary' that's to consider when using a screen (with or without commandline) is the observant individual nearby or far away, who can read what you type or see what is visible on your screen (keys and passphrases which are not 'starred out'). If the latter blurb has you going 'whoa! over the top!' then no worries; just a friendly reminder. threat analysis can quickly make you go 'oh sh*t' and it's never simple. You asked about 'how do I /securely/ ...' (emphasis mine) so I thought a little nudge would be good. In some environments some words carry more meaning than a simple 'lunch'. (Why do I get these goosebumps now while my brain delivers the quite unwanted words 'politically correct' in my neocortex? eek!) When your purpose is to have the command run in a 'any viewer cannot directly glean key from screen or tasklist while I run this' the `cat file` backquoting will suffice. Otherwise, I'd say it's the 'proper way' to calculate a [H]MAC. On Thu, Oct 1, 2009 at 9:20 PM, Michael D. Adams mdmko...@gmail.com wrote: How would I securely compute a MAC for a file? The obvious way (below) has a security leak as it puts the key on the command line which other users could easily observe with ps -f. $ openssl dgst -sha1 -hmac key file I would have thought that something like openssl enc has with -pass file:keyfile would be available, but I haven't been able to find an equivalent for openssl dgst (even the 1.0beta's -macopt flag doesn't do this). Am I missing something here? What is the proper way to compute a MAC on the command line? 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-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 01, 2009, Michael D. Adams wrote: How would I securely compute a MAC for a file? The obvious way (below) has a security leak as it puts the key on the command line which other users could easily observe with ps -f. $ openssl dgst -sha1 -hmac key file I would have thought that something like openssl enc has with -pass file:keyfile would be available, but I haven't been able to find an equivalent for openssl dgst (even the 1.0beta's -macopt flag doesn't do this). Am I missing something here? What is the proper way to compute a MAC on the command line? Well the openssl utility is a test utility and if you really want something secure you should write a custom program. Writing one for hmac shouldn't take more than a few lines. For 1.0.0 MAC support is included which treats it as a signature algorithm where the key just happens to be an unstructured stream of bytes. You can even use pseudo pem files which can be generated. For example: openssl genpkey -algorihm hmac -pkeyopt key:hello -out hmac.pem openssl sha1 -sign hmac.pem -hex somefilename The actual key is just the base64 encoded MAC key with headers included. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt g...@hobbelt.com wrote: A note about your mention of 'security leak': when you are worried about adversaries who can run 'ps -l' on your machine, then you're essentially worried about adversaries with plenty of access to your machine, so they'll quite probably be able to 'cat' that keyfile Any normal user on a Linux machine would be able to see 'ps -f'. But to 'cat' the keyfile or coredump the app, they would need to either (1) have root access, or (2) have cracked the machine. In my mind there is a large leap between 'normal users could get this secret info' and 'user's with root access could get this secret info'. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu October 1 2009, Michael D. Adams wrote: On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt g...@hobbelt.com wrote: A note about your mention of 'security leak': when you are worried about adversaries who can run 'ps -l' on your machine, then you're essentially worried about adversaries with plenty of access to your machine, so they'll quite probably be able to 'cat' that keyfile Any normal user on a Linux machine would be able to see 'ps -f'. But to 'cat' the keyfile or coredump the app, they would need to either (1) have root access, or (2) have cracked the machine. In my mind there is a large leap between 'normal users could get this secret info' and 'user's with root access could get this secret info'. Misplaced security barrier - The user should be sufficiently security qualified to see what they type. Everbody in the same room should be sufficiently security qualified to see anything typed within that room. The room should be sufficiently security qualified to exclude others. In some installations, the red lights on the walls and ceilings flash and the screens are all blanked if someone with less than a certain minimum security qualification level is allowed entry. And if that unqualified person unblanks a screen and types ps -f : simple, shoot them. (I was one of the guys that carried the gun in the room for years.) Other than those operational procedures, you should at least write your own application that does not disclose what you want hidden. Mike Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 10:33 PM, marek.marc...@malkom.pl wrote: admin# echo 100 /tmp/p.txt admin# sleep `cat /tmp/p.txt` [1] 21988 admin# ps -ef | grep sleep | grep -v grep root 21988 3150 0 22:29 pts/0 00:00:00 sleep 100 Dang. Buggerit buggerit buggerit. Yep, you're absolutely right. How long should I keep my foot in my mouth this time? I can't guarantee you I'll learn from the experience but at least it will be one less unintelligent input for the duration. Hm, now I should go and see how I can redeem myself... ... -- 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 5:44 PM, Michael S. Zick open...@morethan.org wrote: Misplaced security barrier - The user should be sufficiently security qualified to see what they type. Everbody in the same room should be sufficiently security qualified to see anything typed within that room. The room should be sufficiently security qualified to exclude others. In some installations, the red lights on the walls and ceilings flash and the screens are all blanked if someone with less than a certain minimum security qualification level is allowed entry. And if that unqualified person unblanks a screen and types ps -f : simple, shoot them. (I was one of the guys that carried the gun in the room for years.) Other than those operational procedures, you should at least write your own application that does not disclose what you want hidden. With ps -f someone else in *another* room can see the command line arguments of programs that I run. You wouldn't chmod a+r your key files now would you? Having key contents appears as a command line argument does effectively that for the duration of the command execution. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
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. It was my understanding that the HMAC key needed to be secret even when used for verification. (Otherwise people could forge an HMAC.) 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
Unsticking foot for 60 seconds - and, yes, this time I checked before I blab. Let's hope I checked enough: On Thu, Oct 1, 2009 at 11:25 PM, Michael D. Adams mdmko...@gmail.com wrote: Any normal user on a Linux machine would be able to see 'ps -f'. But to 'cat' the keyfile or coredump the app, they would need to either for cat I don't need to be root; all it takes is a simple mistake in the file access rights for world or group. I can cat a file with world rights if I know it's path and that can be deduced from the ps output. When I'm in the same group as the owner, same again, but now for group rights, so something like chmod 0400 keyfile would be mandatory when creating it. and, yup, coredumping and such takes more effort. Was just thinking out loud. The point of my original blurb was to hint that going keyfile is not improving security all that much, at least not in arenas where terms like 'cryptographic strength' etc. come into play as well; generating a MAC is using crypto, so you're landed in that arena at least implicitly. Crypto folks tend to regard the word 'security' differently than others, at least we're I am; it's like regular people 'thanking them' versus a navy captain 'thanking them' (at least that's the literal translation for it from Dutch; don't know the precise US or English military lingo for this) - /exact/ same words, /quite/ different impact. (Hint: in the latter case you won't get a handshake, once there's time you'll get a salute, but it might take a while. There might be medals for you, though.) Alas, enough of this already. One bloody word, such a mess. At least now I know why PC popped into my brain back then. Simple words. Big messes. From a pure usage perspective, having the test tools support a commandline format for keys where you can say things like 'literal:mykey' or 'file:keyfile' to the same command option is a nice idea to have throughout. Hm, maybe a patch for that can appease my lordship(s) ;-) Sticking foot back in... -- 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
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
