Why couldn't one have a doubly encrypted session? Basically a PKI
encrypted repository accessed via a session key? Like so:
<-- Encrypted Session with Random Key -->
Client < -- > SSL Traffic < -- > Unencrypted Comparison < -- >
That way the actual transfer of the client key is encrypted and it is
erased at the end of the session. Granted this is a little complex,
but I don't see why it wouldn't work. Not to mention the fact that
dedicated server space is somewhat expensive and to my knowledge,
save a hardware VNC box, there's no way to access the boot prompt
remotely so encrypted boot is out. I've dealt with encrypted
partitions and swap and it's great, but I don't even want to depend
on them powering it off. I want it encrypted at *ALL TIMES* unless
I'm accessing it; and even then, for that short session, to be
On Jun 20, 2007, at 5:01 AM, Benjamin Podszun wrote:
> Michael Williams wrote:
>> What about a GPGesque setup?
>> 1) Create keys for client and server.
>> 2) Have the client encrypt the files to the server keys
>> 3) Have the server decrypt and compare
>> 4) Have the server encrypt to the client keys
> I fear I still don't see how that would make the system secure.
> 1) The servers private key has to be available to your svn server.
> -> It is accessable by anyone with root access anyway. Don't
> mention passphrases etc, because that wouldn't change the problem:
> Your svn server now would need to know that passphrase.
> 3) decrypt means access. The hard way would again be to read the
> memory of your svn server process, the easy way is given above. I
> don't even understand your concept completely (because it seems
> that you'd like to store the files on the server, encrypted by
> client keys. How do you decrypt that files again for comparison
> without private key?), but I think the main point is:
> - Go for your own server
> - Use an encrypted filesystem, enter the passphrase manually at
> boot time
> That way you're sure that no one has access to your files and
> stealing your harddrive/machine would be useless as soon as it
> powers off.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jun 20 14:50:27 2007