Encryption of client / server data

Hi there

I am not sure if this is the correct forum for the topic of encryption, but I could not find another place for it...

We have build a client-server application that replies on SSL for the encryption of data between the two points. After doing some more research, we have found that SSL puts a lot of extra bytes onto the data. So the next challenge is to work out how to transmit data in a secure way without adding so many bytes.

There are only certain things that absolutely have to be encrypted while they are travelling from the client so I had a look into the Cipher object and it's input and output streams. I've also looked at private/public and symmetric keys. (and I can't seem to figure how how to store they keys on the client's computer in a crafty secret manner) But I don't know how to take a decision on which way to go as I don't have any actual knowledge in this field.

I would be very appreciative if there is anyone who could give me more information as to which solution would best work for me.

Many kind regards,
Rachel

I think the question needs to be asked, are the bytes being added by SSL causing a serious performance problem? If it is not, don't bother. Just as premature optimization is the root of all evil, getting "clever" with security leads to security problems.
The bytes SSL adds to the stream are probably either padding (which any encryption scheme would require) or key negotiation (which you'd need to be "clever" with), so the net savings of rolling your own would be nearly zero at the cost of introducing untested security into your application. Not a good tradeoff.
If there is a network bottleneck, I'd look into getting a fatter pipe (throughput is cheap) rather than mucking around with reinventing the SSL wheel.

Well, the bottleneck comes in the fact that we are coding an application that makes use of the data channel on a satellite phone. So we are looking at 2.4 Kbps and that costs quite a fortune. So the idea is to transmit only the bytes that we absolutely have to.

For this reason we are trying to find out if it would be worth implementing something like public / private keys and if the trade-off with that would be big enough to warrent getting rid of SSL in favor of the keys.

1) If you don't want to exchange public/private keys over the network, then you have to figure out some way of installing the certificate on the client before hand. SSL internally does use public/private keys. The overhead is that SSL exchanges the public/private keys during the handshake. If you use some other mechanism of exchanging public/private keys (like through email or something), then you will have to worry about authenticating the transport mechanism. So, for example, if your client is going to download the public key through email, then there should be some way the client can authenticate that the email has not been sent by a hacker.

2) You might want to keep some of the handshakes. In SSL, after the client and server exchange certificates, they exchange symmetric ciphers, and the data is encrypted using the symmetric cipher. This might seem like overhead, but if your data is large compared to the cipher then this way is more efficient, because encryption/decryption using the assymetric key is much more costly than enryption/decryption using a symmetric key. If you are passing data that is very small, then it might be better if you encrypt using the assymetric key directly.

We need to make the transmissions themselves as small as possible and SSL adds on too many extra bytes. So we would rather encrypt only the neccessary files ourselves.

So looking at keys looks like a good idea. But as far as storing them goes, if our application can access the key file, then what is stopping Joe Random Hacker from building an application that can also access that key? Is there something about the storing of keys that I have missed?

Cheers,
Rachel

Hi , just wanted to know if the Diffie Hellman protocol would be useful to exchange a symmetric key.
Although it passes the key over the network but it's encrypted by the other person's public key and your private key.