`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 <[email protected]> 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 <[email protected]> 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 [email protected] >> Automated List Manager [email protected] >> > > > > -- > Met vriendelijke groeten / Best regards, > > Ger Hobbelt > > -------------------------------------------------- > web: http://www.hobbelt.com/ > http://www.hebbut.net/ > mail: [email protected] > mobile: +31-6-11 120 978 > -------------------------------------------------- > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [email protected] > Automated List Manager [email protected] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
