Subject: Re: easiest way to encrypt a file?
To: Jeremy C. Reed <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 12/17/2004 22:02:47
In message <Pine.LNX.email@example.com>, "
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
>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
and you'd decrypt wtih
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