Re: Store Encrypted Files
- From: per@xxxxxxxxxxxx (Per Hedeland)
- Date: Tue, 9 Jan 2007 22:38:14 +0000 (UTC)
In article <1168330346.858004.299470@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Doug Spencer schreef:
On 8 Jan 2007 04:33:43 -0800
I have a couple of questions concerning sending and storing encypted
files on a server.
is an article I wrote explaining the basics of using GPG to store
backups in an encrypted format using GPG. It might be helpful to you
with your project.
i read your article and it might come in handy for a future project,
but if i understand correctly, you have 2 parties that provide
You don't understand correctly - in some cases of public/private key
usage, there are two pairs of them (e.g. SSL/TLS when using client
certificates), but this is not needed or even typical. Incidentally, the
public/private keys are not used for the bulk encryption either in
PGP/GPG or SSL/TLS, they're (as far as the encryption part goes) just
used to allow sender and recipient to agree on a dynamically generated
symmetric key for that.
in my case those 2 parties would be the client and
the server, but as i stated in my original post, i do not want to do
any encryption on the server. When the file arrives on the server it
should already be encrypted!
If you replace the tape drive in Doug's text with your server, you get
this situation - the server gets an encrypted data stream and dumps it
to a file without "looking" at it. Later you can retrieve that file,
which means that the client receives a stream of encrypted data that it
can decrypt. In Unix/OpenSSH terms that could be as simple as
gpg [enc-args] < secret_file | ssh user@host 'cat > encrypted_file'
ssh user@host cat encrypted_file | gpg [dec-args] > secret_file
- gpg (and other tools) can also encrypt/decrypt without any use of
public/private keys at all (i.e. you get to provide the symmetric key),
but that is kind of beside the point.
The way i see it,
i have to do a streaming encryption, that is while my file is being
uploaded, i encrypt it, like https or sftp, but i do not want the
server to decrypt it.
As can be deduced from Doug's text, and as shown above, gpg (and other
tools) can certainly do streaming encryption, without any need for the
other party to decrypt. But the transport encryptions of SSL/TLS (https)
or SSH (sftp) are just that - transport encryptions. They can't be used
by simply dumping the stream to a file and later decrypt that file.
Among other things the stream includes protocol control information that
must be processed by the receiving party, and at least for SSH the
transport encryption must be undone to get at that information.
Or i do an encryption on the client, and then i upload it, but this
would consume client processor time.
Hm, I assume that you mean that the client then gets to do both the file
(or stream) encryption and the transport encryption? This is true, and
the one you can't do without is the file/stream encryption. I.e. if this
is a concern, you need to use a protocol without transport encryption -
I think this was already pointed out, along with the fact that you don't
need transport encryption per se since the content you're transporting
is already encrypted, but that you probably still need to think about
encryption to protect the authentication phase.
I can't think of any protocols in common use that fits that bill very
well - SSH with public-key authentication and cipher 'none', or SSL/TLS
with client certificate authentication and cipher NULL could work, but
those ciphers, while specified by the standards, are not normally
available. And with current processors, the effort of this "double
encryption", at "Internet speed", shouldn't be a problem (if you want to
do it on a Gigabit Ethernet LAN, things may be different).
- Prev by Date: Re: SSH on CYGWIN bash permissions error
- Next by Date: Re: Capture the public key using tcpdump?
- Previous by thread: Re: Store Encrypted Files
- Next by thread: Re: Store Encrypted Files