Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have a poor knowledge in the world of cryptography, I'm just starting to learn it so I'm a newbie :)

As a project for getting into the field of cryptography I want to write a client\server program that can send and receive data in a secure manner (i.e encrypted).

Let's say I want to encrypt the traffic between a client and a server or between two clients. The service I'm running can only talk with the server or another client (which acts as server too) on a known port, the server basically listens for a connection on one side on a default port.

I want those services to be able to talk to each other with out the possibility that a third party who's listening on the network to be able to decrypt the content of the conversation or try to impersonate a service.

I'm not looking for a new way to exchange keys(or should I?), I can have the keys be saved securely in the services so when x sends a message to y, and back, they will be the only ones that can decrypt the content and response (off-course, only to a verified service).

  • side note, the key can be saved in the program - hard coded or it can be generated from a combination of things (e.g IP, computer-name, user name or any other combination of constants) which can be passed to the client so it will be able to generate the key (lets say I'm passing the IP, computer name and a random seed, there will be a known formula to create the key from those values).

I need to use a symmetric key for the encryption, but maybe I can try and use two pre-generated keys as SSL does.

I know that if I'm using the same key again and again, a third party can sniff the traffic and get the key (mathematics at it's best, how is it done?), the more data he will collect, the easier it gets(?).

So, what should I do in order to promise that no-one will be able to get the encryption key (eventually reading the data)? Which cipher should I use? What else I need to know before I start my journey?

share|improve this question
2  
(I'm understanding that you are doing this to learn, not to use this productively.) My recommendation would be to have a look on how TLS (SSL's successor) works, and try to understand why it works that way. (And ask again about specific points if you have more doubts.) Creating a secure protocol is not trivial, and easily done wrong. –  Paŭlo Ebermann Sep 22 '11 at 12:08
1  
Why are you trying to create your own protocol, rather than using an existing one? Is the "no SSL" constraint just to encourage "novel" answers, or are there particular aspects of an SSL/TLS-based approach which make it unacceptable to you? –  Misha Sep 22 '11 at 19:26
    
"No SSL" is due to the fact that I can't verify that the server\client's certificates. this model should be working in close networks which aren't bridged to the internet. eventually I want to implement a way that 2 clients can talk to each other in an encrypted way. –  YSY Sep 22 '11 at 19:44
6  
You don't need the Internet to use SSL/TLS (or certificates) - just the client would either have a certificate of the server, or from some CA which signed the server's key (or some other CA certificate). (And SSL/TLS can even work with pre-shared symmetric keys, if you don't want certificates. –  Paŭlo Ebermann Sep 23 '11 at 0:01
    
so I basically need to sign all the clients public key and have the certificates in all clients which acts as servers too, then implement a way that will check that I'm talking to a verified server/client. but, anyone can spoof a cerificate and "sign it" if I can't check it with the Certificate authority (which I can't), or is my assumption wrong? –  YSY Sep 23 '11 at 10:50

5 Answers 5

This is actually simpler than the others have suggested I think. Here is what I propose:

  1. Generate a public/private key pair using RSA. You can do this on any unix machine using openssl: openssl genrsa -out rsa.private 2048
  2. Distribute the public key as hardcoded in your client.
  3. When the client logs in, the client generates a private shared key (also using openssl, or another well known encryption library) and encrypts it using the public key.
  4. all data between client and server should be encrypted with the new shared key for the length of the session.

There is a lot of other stuff you can do to harden it, such as limiting sesison length to one or a few hours before re-generating keys, having the server sign message digests, etc. A full understanding of encryption will help you understand what those are and why, but for a basic implementation (for medium to low value data) this should be sufficient.

share|improve this answer
    
so each client will have the public and private key which I generated? (hard-coded). if I want to re-generate keys I must find a way to update all the clients with the same keys? or is it ok that each client will have it's own public/private key? –  YSY Sep 22 '11 at 19:55
    
ok, I think I got it.. what guarantees that no one will impersonate a client and start a session with another client? he will send "hi" (or something that will start the negotiation process), he then will get the public key, encrypt a private shared key with the public key and send it to the other client eventually starting a secured session. –  YSY Sep 22 '11 at 20:05

Before coding, read this: http://www.schneier.com/book-applied.html

This question is too broad to fit on StackExchange unfortunately. The length and breadth of cryptography is rarely traversed by a single individual with any degree of success without formal education in mathematics, computer science, and a smattering of engineering.

This book will help you learn common concepts, common mistakes, fark-ups to learn from, and examples to follow.

share|improve this answer

Basically you want the kind of tunnel that SSL provides. These things are actually difficult to get right.

SSL is an assembly of several things. There is the tunnel itself: once there is a shared secret (what is called the "pre-master secret" in the TLS specification), and client and server agree on which algorithms to use, then the individual data records can be encrypted, as is described in section 6 of the spec. To get to that point, SSL first performs the handshake in which the asymmetric cryptography occurs. If you control both client and server, and they already "inherently" share a secret, than you can skip the handshake.

During the handshake, the server sends an opaque blob (the "certificate") which the client may use to obtain the server's public key. If the client has an inherent knowledge of the server's public key, then it can totally ignore what the server sent, and simply use the known public key. Certificate validation (which is a rather complex piece of code) is used only when the client wants to discover dynamically the server's public key -- that's what occurs on the Web. But, depending on your scenario, this is not necessarily needed.

We now have on this very site a question about how SSL works with very descriptive answers (if lengthy).

If SSL does not inspire you, have a look at SSH. Same concepts, distinct protocol. SSH is described over several documents; begin with RFC 4251.

share|improve this answer

It can't be done without an independent distribution channel to transfer a key from the server to the client. For SSL, that's the whole certificate signing process and the public keys for certification authority root certificates that are included in web browsers. So your first problem is working out how to get a key from the server to the client in a way that can't be intercepted by a man-in-the-middle attack (i.e. not over the network).

share|improve this answer
    
I've mentioned that I can keep the encryption keys in the client/server program (pre-configured), so I don't have to pass the keys. –  YSY Sep 21 '11 at 20:27

If you want to create a secure channel without SSL/TLS, then what you need to do is re-implement SSL/TLS, piece by piece. There isn't much (if anything) you can leave out and still be left with a secure connection -- everything you see there is the result of about 20 years of use and review and analysis.

This is a pretty signification part of the reason why you always hear that you shouldn't try to roll your own encryption. So rather than starting from scratch and making your own road, you're better off sitting down with the specs and learning how the existing implementations work.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.