Mailing List Archive

On Fri, 21 Jan 2000, Werner Koch wrote:

> Hi,
>
> there was quite a long thread about how to feed the passphrase to gpg
> in a shell script.
>
> What most folks want to do is to take the passphrase from a file and
> feed it to gpg. If you think you gain more security from this than
> simply removing the secret key protection entirely from the secret
> keyring, you are wrong. If someone has access to the secret keyring
> he will also have access to the file or script which contains the
> passphrase. It does not increase security by requiring an attacker to
> look at 2 files on your system. Make your system immune against all
> ways to gain root access and to your account and you are done.
> Because this is not really possible, do at least the best to detect
> intrusion and revoke the keys as soon as you have a reason to believe
> someone got access to the secret keyring or the passphrase file (if
> you still believe this last one is needed).
>
> Doing tricky stuff to feed the passphrase to gpg is futile and only
> makes the code more complex and error prone.
>
> There are two scenarios I can see for that --passphrase-fd makes sense:
>
> * You have an interactive program which asks for the passphrase and
> then feeds it down a pipe to gpg. And here we don't wont files or
> any other buffering mechanisms. (see Mutt)
>
> * You have a daemon or a special kernel service which stores that
> passphrase for you in RAM after asking the operator on startup for
> it.

How does either of your two options deal with a process started on a
regular basis by cron? No daemon to store the passphrase in ram with, and
impossible to make interactive input.

>
> Remember, the weakest link determines the overall security: So
> 1024/128 bit keys are much more than needed on todays networked
> operating systems. There are so many published (and unpublished)
> exploits for all OSes - and this not only for MS-Windows but also
> for all Unices; maybe OpenBSD does the best job to avoid them, but
> the probability that there are ways to become root on OpenBSD is still
> *much* higher than to calculate the DL for a 1024 bit key.
>
> To increase the security you need OSes designed with security in mind
> (e.g. EROS, VSTa projects).
>
>
> Well, these are just my 2 cents,
>
>
> Werner
>
>
>

----------------------------------------------------------------------------
Chuck Robey | Interests include C & Java programming, FreeBSD,
chuckr@picnic.mat.net | electronics, communications, and signal processing.

New Year's Resolution: I will not sphroxify gullible people into looking up
fictitious words in the dictionary.
----------------------------------------------------------------------------

On Fri, 21 Jan 2000, Chuck Robey wrote:

> How does either of your two options deal with a process started on a
> regular basis by cron? No daemon to store the passphrase in ram with, and
> impossible to make interactive input.

Use unprotected keys. Encrypting something and storing the key on
the same medium remembers if of DVDs :0)

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

Boycott Amazon! - http://www.gnu.org/philosophy/amazon.html

On Fri, 21 Jan 2000, Werner Koch wrote:

> On Fri, 21 Jan 2000, Chuck Robey wrote:
>
> > How does either of your two options deal with a process started on a
> > regular basis by cron? No daemon to store the passphrase in ram with, and
> > impossible to make interactive input.
>
> Use unprotected keys. Encrypting something and storing the key on
> the same medium remembers if of DVDs :0)

Uhh. I'm not the crypto-whiz you are. I understand (I think) the DVD
story. Can you tell me why needing crypto signatures on output of a cron
job equates to the DVD story? No sarcasm here, I really don't know.

>
>

----------------------------------------------------------------------------
Chuck Robey | Interests include C & Java programming, FreeBSD,
chuckr@picnic.mat.net | electronics, communications, and signal processing.

New Year's Resolution: I will not sphroxify gullible people into looking up
fictitious words in the dictionary.
----------------------------------------------------------------------------

>>>>> "CR" == Chuck Robey <chuckr@picnic.mat.net> writes:

WK> Use unprotected keys. Encrypting something and storing the key
WK> on the same medium remembers if of DVDs :0)

CR> Uhh. I'm not the crypto-whiz you are. I understand (I think)
CR> the DVD story. Can you tell me why needing crypto signatures
CR> on output of a cron job equates to the DVD story? No sarcasm
CR> here, I really don't know.

I think you missed the point. It's not that you don't need GPG from
cron jobs, it's that if you -are- using GPG from cron jobs, you
shouldn't have a passphrase on the key that's used.

I'm not a crypto-whiz, either, but I think I can make an analogy.

It's not any good having a great big padlock on your door if you hide
the key under the doormat. It's a false sense of security to hide the
key, because it's trivial to find it. So, instead, leave the key in
the lock, and don't let people get near the door.

Leaving the key in the lock is -better- than putting it under the mat,
because it will make you nervous and more conscious about who you let
near the door, and what you keep behind it.

Does that make sense? I guess what I'm trying to say is that having
the GPG key and the passphrase stored in the same place is essentially
equivalent to having no passphrase at all. So, don't kid yourself and
go to the trouble of having a passphrase.

~ESP

Chuck Robey <chuckr@picnic.mat.net> writes:

> Uhh. I'm not the crypto-whiz you are. I understand (I think) the DVD
> story. Can you tell me why needing crypto signatures on output of a cron
> job equates to the DVD story? No sarcasm here, I really don't know.

You don't quite have the equivalence. It's not needing crypto
signatures on cron output. It's storing a decryption key where people
can get at it.

You want to have gpg sign things automatically, without any
interaction, right? To do this, you think that you need to have a key
protected by a passphrase, and that somehow (say, by getting it from a
file), your cron job will give the passphrase to gpg. Werner's saying
that's absolutely no more protection than having a key without a
passphrase.

What's protecting the file you keep your password in from being
viewed? Probably, unix file permissions, difficulty in logging into
the machine, etc. What's protecting a key without a passphrase from
being stolen? Exactly the same thing. So you aren't losing any
security by just getting rid of the passphrase.

A passphrase normally provides protection for a key because if you get
the key, you don't get the passphrase. It's in someone's head
somewhere. If someone breaks into my computer and gets my secret
keyring, they can't use it because they'd have to come to my cube and
rough me up a bit. But if the passphrase is stored on the same
machine as the key, there's nothing stopping them.

The analogy to DVDs is that they have a Content Scrambling System (or
whatever it's called)... but the key is stored on the DVD itself.
That's why it's been broken.

--
Alan Shutko <ats@acm.org> - In a variety of flavors!
Old golfers never die, they just loose their BALLS

On 21 Jan 2000, ESP wrote:

> >>>>> "CR" == Chuck Robey <chuckr@picnic.mat.net> writes:
>
> WK> Use unprotected keys. Encrypting something and storing the key
> WK> on the same medium remembers if of DVDs :0)
>
> CR> Uhh. I'm not the crypto-whiz you are. I understand (I think)
> CR> the DVD story. Can you tell me why needing crypto signatures
> CR> on output of a cron job equates to the DVD story? No sarcasm
> CR> here, I really don't know.
>
> I think you missed the point. It's not that you don't need GPG from
> cron jobs, it's that if you -are- using GPG from cron jobs, you
> shouldn't have a passphrase on the key that's used.
>
> I'm not a crypto-whiz, either, but I think I can make an analogy.
>
> It's not any good having a great big padlock on your door if you hide
> the key under the doormat. It's a false sense of security to hide the
> key, because it's trivial to find it. So, instead, leave the key in
> the lock, and don't let people get near the door.
>
> Leaving the key in the lock is -better- than putting it under the mat,
> because it will make you nervous and more conscious about who you let
> near the door, and what you keep behind it.
>
> Does that make sense? I guess what I'm trying to say is that having
> the GPG key and the passphrase stored in the same place is essentially
> equivalent to having no passphrase at all. So, don't kid yourself and
> go to the trouble of having a passphrase.

That makes sense, yes, thanks (I didn't understand "unprotected"). I am
going to use passphrases because "I was told to", but you make a good
argument, I guess. I was told adding a passphrase in a fairly well hidden
file would *somewhat* increase it's security. Of course, if someone gets
root on my machine, it's all up anyhow.

>
> ~ESP
>
>
>

----------------------------------------------------------------------------
Chuck Robey | Interests include C & Java programming, FreeBSD,
chuckr@picnic.mat.net | electronics, communications, and signal processing.

New Year's Resolution: I will not sphroxify gullible people into looking up
fictitious words in the dictionary.
----------------------------------------------------------------------------

Werner Koch, at 10:52 on Fri, 21 Jan 2000, wrote:

> Doing tricky stuff to feed the passphrase to gpg is futile and only
> makes the code more complex and error prone.

What I think some are wanting to say is that they don't only want 'tricky'
ways to handle passing the passphrase to GnuPG; some languages don't have
all the niceties of finding the numerical fd, and then being able to pass
it down to GnuPG via a fd.

I'm not saying that passphrase-fd is bad. Rather, I think it's a very
good interface given the non-anonymity design of most unixes. However, I
just don't think that there is anything inherently wrong with passing it
in via an argument; it is only a problem if other users on the system can
see the argument list of other users's processes. And this should not be
taken for granted, just because most people use Linux where this is
possible.

Therefore, I think there is no reason _not_ to allow the information to
passed in as an argument. It's the programmer's responsibility to handle
the situation correctly for his environment. I feel that making this
decision for him is a bad thing. There's More Than One Way To Do It
(TMTOWTDI - Perl Motto).

> There are two scenarios I can see for that --passphrase-fd makes sense:

I could create other scenarios. For example, consider an example where
the daemon process only has access to the secrets (passphrase and secret
key) some of the time. What do I mean? Well, consider a scenario where
the passphrase file is mounted over a networked filesystem. The host only
allows clients to connect at certain times; the reasons for this could be
several, including easier control, monitoring, analysis of what is going
on. This also allows for separation of secrets. The secret key's
passphrase file is mounted at certain times, allowing the daemon access to
it. The same could be done with the secret keyfile. This separation of
secrets could actually be useful in somesituation. I'm not saying this
system is currently feasible or secure; I'm only using it to demonstrate
that that there definitely could be situations that you don't think of.
Once again, There's More Than One Way To Do It.


--
Frank Tobin http://www.neverending.org/~ftobin/

"To learn what is good and what is to be valued,
those truths which cannot be shaken or changed." Myst: The Book of Atrus

OpenPGP: 4F86 3BBB A816 6F0A 340F 6003 56FF D10A 260C 4FA3

Frank Tobin <ftobin@uiuc.edu> writes:

> in via an argument; it is only a problem if other users on the system can
> see the argument list of other users's processes. And this should not be
> taken for granted, just because most people use Linux where this is
> possible.

How about, just because most people use things other than FreeBSD,
where this is possible?

Every Unix I've ever worked on lets you see other people's command
line arguments. Apparently, this is no longer the case on recent
FreeBSDs, but what other Unices restrict this info as well?

I suppose you could add a configure option to allow passing the
passphrase in on the command line. Making it a hassle to enable would
make it more likely that the programmer would think about the risks
involved. But allowing it willy-nilly would probably result in a lot
of usage by people who didn't realize that anyone could see it.

--
Alan Shutko <ats@acm.org> - In a variety of flavors!
Bizarreness is the essence of the exotic.

>>>>> "Chuck" == Chuck Robey <chuckr@picnic.mat.net> writes:

Chuck> How does either of your two options deal with a process started
Chuck> on a regular basis by cron? No daemon to store the passphrase
Chuck> in ram with, and impossible to make interactive input.

The trick might be to have the cron daemon itself act as the daemon
storing the passphrase. It would provide the process w/ a FD to read
the passphrase from; the process can then pipe that direct to the gpg
sub-process.

Another option is to have the daemon sleeping in the background, and
use cron to send it a wakeup signal. Again, it has the phrase in RAM
and can pass it to gpg via a pipe.

I've not spent much time (ie more than a few seconds) thinking about
the security issues of these proposals. Obviously of course the RAM
used to store the phrase must be mlock(2)ed (or the equivalent), but
beyond that....

Comments welcome.

-JimC
--
James H. Cloos, Jr. <URL:http://jhcloos.com/public_key> 1024D/ED7DAEA6
<cloos@jhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Save Trees: Get E-Gold! <URL:http://jhcloos.com/go?e-gold>