>Sam Varshavchik writes:
>>alan milligan writes:
>>>I've been looking at this over the last day or so and immediately have
>>>come upon the problem of encrypted private keys and the --no-tty option
>>>being passed via mimegpg.
>>>As an aside, just how does one decrypt a gpg private key so that no pass
>>>phrase is required?
>>Don't use a passphrase. It's a documented option.
>>>More importantly, to do this in a server style environment just does not
>>So tell us what does make sense, then.
>>Perhaps you think it's a much better idea to send the passphrase, in
>>cleartext, over the network?
>>>If I am a Courier user am I supposed to meekly place my decrypted private
>>>key upon a server to which anyone with root access can then effectively
>>>masquerade as myself (and not just as my Unix user)??????
>>That same someone, with root access, can trivially install a trojaned
>>version of GnuPG that covertly records your passphrase, instead.
>>There's a very nice looking T-shirt available for sale from Thinkgeek. It
>>carries a logo: "Bow before me, for I am root."
>>>Requiring any form of private key to be stored on the server seems to me
>>>to compromise the entire asynchronous encryption model.
>>How does storing a private key on a reasonably hack-proof server is more
>>secure than transmitting your private key, or a passphrase, in cleartext
>>over the network?
>>>Ideally, the encryption/decryption should be done using private key
>>>information stored upon the client machine. Dose anyone have any
>>>thoughts about implementing this?
>>Sure. Encrypt/decrypt with GnuPG by yourself, then upload the end result
>>as a binary attachment. The recipient can download the attachment, and
>>decrypt it with GnuPG by himself.
This IS indeed the only safe solution. The entire asynchronous encryption
model relies upon keeping your private key secure. I do not believe that
placing your private key with your Courier Mail provider is a good idea for
This is indeed a similar situation to a few years ago when the NSA wanted
everyone to register their private key with them. If you choose to directly
use the encryption layer with Courier you ARE potentially exposing yourself
to similarly serious security problems.
Firstly, there is the issue of someone else being able to decrypt and read
your emails. But worse, they could use your private key to sign documents
etc etc etc. If someone is clever enough to install Courier, they can
surely brute force your pass-phrase (who really followed the sages in choice
of appropriate pass phrase...).
For public key encryption to work, you MUST stringently control access to
your private key. This means that encryption/decryption must take place on
the client where the private key resides! Thus I suggest encryption
functionality within Courier is laudible but misguiged.
For PC platforms, there is NetWare Associates PGPTool suite which is a well
integrated OpenPGP client. Using Courier IMAP/POP to download encrypted
mail in conjunction with this local tool is probably a good solution (I will
hopefully test this with Courier-encrypted messages next week). I haven't
discovered a good GUI counterpart for Unix yet. Both PGP and GnuPG are
command-line interfaces. I don't suppose anyone is up to writing a Netscape
>I don't know GnuPG but I do know PGP. The chain of trust model allows you
>create a long-lived, secure, pass-phrased key on a system you trust, then
>use it to sign short-lived, less secure keys, with restricted validity
>they can't be used to sign other keys) and without a pass phrase, that can
>be used in less secure environments. Then, even if your key is compromised,
>it can be easily revoked and can't be used for too much in the mean time
The chain of trust model is part of OpenPGP and is supported by GnuPG.
However, it is not recommended for use so you can regularly recycle your
public key. This is cumbersome because all old documents can only be
decrypted to the public key they were encrypted to. Reviewing your mail
archive would quickly become a nightmare!
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp