Private key security

[GoogleCodeExporter]

What steps will reproduce the problem?
1. none - normal use
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
0.9.9.550 WinXP

Please provide any additional information below.

I just discovered TorChat, read about its logic, and, almost understand how it 
works, I'm convinced that it works as advertised! Awesome, simple and unique!

I have a question and a suggestion of sorts:

Q: A converses with B using TorChat.  C, the adversary, records all 
conversations, but can't read them at the time because of the intrinsic 
end-to-end encryption.  Later on, C, by coercion, acquires the Private Keys of 
A and/or B.  Can the recorded conversations be read then?

S: How hard/useful would it be if the Private Key file was encrypted at all 
times except when TorChat starts and needs to load the key for authentication?  
I was even thinking of writing a batch file that would: decrypt the Private Key 
--> start TorChat and load the Private Key to RAM --> encrypt it back 
immediately afterwards.  I'm not sure if this is gonna work.  

A possible problem is supplying the password: I love the simplicity of TorChat 
(i.e. no passwords, registration, convincing logic etc.) and I'm afraid that 
such additional encryption scheme would require providing a password when 
TorChat starts the first time and the account .onion number + key is created, 
then each time TorChat starts and then it would need either ask for a password 
each time it closes or keep in RAM and use the same password for 
decryption/encryption throughout the TorChat session. 

Does it make any sense, is there a way around it and is that an issue at all?  
(the reason I thought it was, was that the Private Key is on a disk out in the 
open the whole time - given enough time, it's somewhat easy to spread it 
(inadvertently perhaps).

Cheers!

Original issue reported on code.google.com by ojtam...@gmail.com on 20 Nov 2011 at 3:28

[GoogleCodeExporter]

this private_key file can not be used to decrypt traffic. 

When Tor builds a tunnel to the rendezvous point then it will first encrypt to 
the first node, then to the second and then to the third node. After connecting 
the tunnels at the rendezvous points it will do a Diffie Hellman key exchange 
with the other buddy with a random symmetrical key, so once the connection is 
established there will be 4 layers of encryption at each end (at your ISP 
connection) and still one layer at the rendezvous point and none of them is 
derived from private_key.

the only purpose of the private_key file is to make the .onion address work, to 
authenticate the owner of the hidden service address. It is used only for 
establishing the hidden service itself, to prove to the tor network that you 
really own this .onion address. If it is stolen then the thief can impersonate 
you and receive incoming connections under your address. It is NOT used for 
content encryption, this is a completely separate mechanism.

But you are right with your concerns about this file lying around unencrypted. 
I don't like this fact too.

But I have no easy solution, Tor needs it somewhere in the file system. I have 
thought about things like temporary RAM disks already and also hope that some 
day the Tor project might change it so that a hidden service can also be 
started by supplying the key through the control port without the need for a 
file on the disk, I have seen a feature request for this already having been 
discussed but I don't know if and when it will be implemented.

Currently the simplest way to make it really extremely secure would be to use a 
knoppix live CD (or similar) installed on an USB drive (in knoppix you can 
enable an encrypted persistent home partition on the USB drive, probably other 
live linuxes have something like this too).

Original comment by prof7...@gmail.com on 20 Nov 2011 at 12:00

[GoogleCodeExporter]

Many thanks, Bernd!

Would you recommend trying the new Tor's Tails live CD/USB?

Original comment by ojtam...@gmail.com on 20 Nov 2011 at 1:52

[GoogleCodeExporter]

I don't know enough, but there seem to be a RAM disk of sorts design to work 
with Tor - perhaps that could be useful in solving some of the Torchat security 
dilemmas?

http://opensource.dyc.edu/tor-ramdisk 

Original comment by ojtam...@gmail.com on 27 Nov 2011 at 11:19