Public key operations are slow. If you intend to encrypt an entire file with the public key alg (as opposed to encrypting just a secret key that's then used to encrypt the data) you can expect a lot of time spent on compression and decompression. One RSA implementation I've used does about 30,000 bytes/sec with a 1024 bit key on a p3 1.2 ghz. You'll also need to pad any data - which is 2:1 padding to data (varies by padding method I think?), so you end up with ~3x the original size.
The usual operation is to use a shared secret key to encrypt the actual bulk of the data you want to transfer. The public key is used to encrypt the shared secret key, since you need a way to transfer that key from location A - > location B through "hostile territory". In your situation the secret key stays in a single location, so there's no need to provide security to transport it anywhere.
Additionally you might consider ways to hide the size and source of data.
Also, by linking the public key with the file you give the person running the server the ability to replace your data. They take a replacement file, encrypt it with the public key you gave them for reference, and now you get back whatever they encrypted. If you use a block encryption method they can replace individual blocks. If someone knows a bit about you they can probably use your habits, the current situation, and the size of the file to make a pretty good guess as to what's inside - which can give them a good idea what they could replace it with that might cause the most problems for you.
Andrew Mann
Andrew Walrond wrote:
On Thursday 18 Mar 2004 16:14, Gerrit E.G. 'Insh_Allah' Hobbelt wrote:
Hi Andrew,
How unique is it? Is it statistically improbable that I could generate the same key twice?
If you have properly seeded your random generator, generated (RSA) keys should be quite unique.
Here is a simple description of WhiteWater which explains what I'm doing. You'll see why I asked the question, and it perhaps answers some of your counter-questions. Comments/criticism gratefully accepted...
"Whitewater is a cross between bittorrent and an anonymous file server, and handles multiple files (like the whole package source tree in rubyx)
Basically, there are two binaries, wws - White Water Server wwc - White Water Client
wws is a daemon which provides the data store, and wwc is used to talk to a wws.
First, understand asymetric cryptography. You generate a key-pair. The public key is used to encrypt (lock) data. It can only be decrypted (unlocked) with the private key. You can extract the public key from the private key when you need it, but obviously not the other way round. You can give out your public key to anyone who needs to send you encrypted data, but only you can decrypt it with the private key.
To 'distribute' a file (make it available from a wws) you would do
wwc --server ww.rubyx.org --distribute myfile > private-key
wwc generates a new (unique) key-pair and encrypts the file using the public key. It then makes a connection to the wws running on ww.rubyx.org, and uploads the encrypted file to the wws server, along with the public key.
The wws server splits the file into lots of small chunks (currently 50k each; testing will provide optimal size) and calculates an md5sum for each chunk. It then stores the chunks in it's data cache, accessible via their md5sums. It also stores the array of md5sums needed to recreate the entire encrypted file in a catalogue hash, referenced via it's public key.
wws now stores the data, which it can reference with the public key, but it has no idea what the data is and has no means of decrypting it. It is a true anonymous fileserver; Fully obfuscated and with plausible deniability :)
wwc then sends the private key to stdout. In the example above, the private key is stored in the file private-key. At no time did the private key leave wwc running on the local machine.
To access a file, you supply the private key to wwc.
wwc --server ww.rubyx.org --get private-key > myfile
wwc extracts the public key from the private key, connects to the wws on ww.rubyx.org and sends it the public key.
wws looks up the public key in the catalogue hash and returns the array of md5sums of the chunks required to reconstitute the file.
wwc, for each chunk/md5sum then requests the ip of a cooperating server which has that chunk from the wws on ww.rubyx.org. It contacts each of these other wws servers and requests the relevant chunk (by specifying the md5sum).
Note these downloads are done in parallel so you should always achieve near the maximum download speed according to your available bandwidth. (As with bittorrent, the more downloads, the faster it gets)
All recieved chunks are checked against their own md5sum, and bad or non responsive servers are reported to the wws on ww.rubyx.org and an alternative wws ip requested.
Once wwc has all the required chunks and has reconstituted the file, it is decrypted using the private key and sent to stdout. In the example above, the data is sent to myfile
Users wanting to lend (a small amount of) upstream bandwidth to the cause will run their own wws like this
wws --parent ww.rubyx.org
and use wwc --server localhost in the above examples. The local wws informs the parent of it presence and the md5sums of the chunks it has in its data cache. This is better than bittorrent (as I understand it) because it can share other data than just that which it is currently downloading.
Thats roughly what happens. Pretty simple I think you'll agree, but Whitewater combines the benefits of bittorrent with those of an anonymous file server."
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
