In message <Pine.LNX.4.43.0412171024110.21256-100000@pilchuck.reedmedia.net>, "
Jeremy C. Reed" writes:
>I want to place a DSA key file on a server not maintained by myself. It is
>pass-phrase protected, but still I don't want the file used.
>
>What is the easiest way to encrypt a file with a key to decrypt?
>
>I have used zip and pgp and gpg to encrypt files. But what other ways do
>you suggest?
>
>Anything in the NetBSD base? (And examples?)
>

What is your threat model?  Whom do you think might try to crack the 
encryption, and what resources can they bring to bear?  How long must it
remain scret?  How many people need to retrieve and decrypt the file?  

The base system has bdes, but it uses DES.  A DES-cracker was built for 
$250K in 1997; it would be much cheaper today.  That said, I haven't 
heard of any commercial services offering DES decryptions.

RSA-based solutions (OpenSSL, PGP, gnupg) are good if you need to let 
several people decrypt it.  How long the RSA key should be depends on 
how long the file needs to be secure.  

mcrypt supports AES (aka Rijndael); AES is strong enough that NSA 
permits it to be used for TOP-SECRET data if you use a 256-bit key.  A 
128-bit key is rated safe enough for SECRET data.  Unfortunately, 
mcrypt has far too many options.  That said, the defaults -- 128-bit 
AES in CBC mode, with a SHA1 hash -- looks to be quite sufficient.
(Note: the man page never says what the default encryption algorithm 
is, and says that the default hash is CRC32.  This appears to be 
incorrect in my tests.)

Given that, to encrypt you'd say

	mcrypt file

and you'd decrypt wtih

	mdecrypt file

You'll be prompted for a key; practically speaking, this is probably 
the weakest point.

However -- you say that the key itself is "pass-phrase protected".  
What package did you use to create this key?  In most packages 
(including OpenSSL), when you "protect" a key with a passphrase you're 
actually encrypting it.  If you've used a decent cipher and passphrase 
to start with, there's probably little benefit to encrypting it again.

		--Steve Bellovin, http://www.research.att.com/~smb