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.

My model is one where I have several clients which wish to speak with some (but not all) of the other clients.

All messages will be sent through a server.

Only the two clients communicating with each other should be able to know the message. So the server AND the other clients should not be able to work out what message was sent.

Communication between two clients may start and end several times a day.

Messages will be plaintext with potentially unlimited length, but likely to be much less, think SMS style messages.

Given these circumstances, how should I encrypt the messages? I don't mind writing extra code if it leads to better speed or efficiency.

I know the rough basics of how RSA and AES work but I can't figure out what is best.

When you generate a public/private key pair for RSA, is there any situation where you would need to generate a new pair? Or can one client have one public key and give the same key to anyone that wants to talk to him and only him be able to (ever) read the messages, but they store the public key for all future messages?

Or should I have a separate symmetric AES key for pair of clients and simply share that when contact is first initiated and use that forever. Again, is there any circumstance where this would need to be generated again?

How would I store the key(s) so they persist if client crashes/shutsdown/reboots?

share|improve this question

migrated from stackoverflow.com Jan 23 '12 at 18:12

This question came from our site for professional and enthusiast programmers.

    
RSA is a public-key encryption algorithm (asymmetric), while AES is a symmetric key algorithm. The two algorithms work very differently, and often a cryptosystem will use both algorithms. For example, a cryptosystem may use RSA to exchange keys securely, while use AES to encrypt the actual messages. –  In silico Dec 17 '11 at 23:50
    
I am asking from an implementation point of view, the programming side of things...what algorithm should I program the encryption of messages, how do I program the storage of key(s). –  Ben Dec 17 '11 at 23:54
    
@Ben, You may also wish to consider an active eavesdropper, where either the server, or another client, are pretending to be the recipient of the message. I do not know how likely this is with your model, but something to consider. In fact, the eavesdropper could then echo the message on to the real recipient, and then again, I do not know if the real recipient would detect the changed fingerprint of the sender. –  George Bailey Jan 23 '12 at 18:30
add comment

4 Answers

Neither, unless it's both. You're asking the wrong question. You should not be thinking about a cryptographic algorithm at this stage, but about a cryptographic protocol.

Cryptographic protocols are hard to design, and a frequent source of security bugs. You don't fully understand public-key cryptography, so you aren't ready to use it in your own cryptographic protocol.

At a high level, your model is amenable to public-key cryptography (e.g. RSA). Let every client have its own private key and publish its public key to the other client. A client's private key does not change over time, unless the client has been compromised. Symmetric cryptography (e.g. AES) would not scale well here because each pair of clients would need to have its own secret key.

Use existing software whenever possible. Implementing cryptographic protocols is almost as tricky as designing them. For a model where clients occasionally send messages to one another, email-style, a tool that would work well is GnuPG. (For bidirectional communications, use SSL/TLS.)

So: for day-to-day operation, to send a message, call gpg, encrypt with the public key of the recipient, and while you're at it sign with the private key of the sender. When receiving a message, check the signature against the purported sender's public key, and decrypt with the public key of the receiver. In other words, send with gpg --sign --encrypt -r NAME_OF_RECIPIENT and receive with gpg --verify followed by gpg --decrypt.

The remaining problem is that of key distribution. After a client has generated its key pair, it needs to inform the other clients about it and distribute it without allowing the public key to be intercepted and replaced in transit by an attacker. How to do this depends a lot of your precise scenario. Don't neglect the security of this part.

If, and only if, invoking GnuPG proves to be too slow, then consider using a lighter-weight, perhaps home-made implementation of a similar protocol (going from e-mail range overhead to SMS range overhead). Under the hood, GnuPG generates a symmetric key for each message, because public-key cryptography is expensive for large messages; the public key algorithm is only used to encrypt the symmetric key and to sign a digest of the file. You should follow this model. Using AES for symmetric encryption, SHA-256 as the digest algorithm and RSA as the public key algorithm is a good choice.

share|improve this answer
add comment

As already said by In silico, RSA and AES serve two different purposes. AES is a fast algorithm, suited to encrypt a whole conversation. But it has a problem: how to decide which key to use between two parties without the other ones knowing it?

RSA can be the solution to this. If Every participant has the public RSA key of every other participant, anyone can start an encrypted communication with anyone else (by using the other participant's public key) and decide of a secret AES key to use. Once the AES key is decided, the rest of the conversation can be encrypted using AES. To prove that to participant B that it's really A which wants to tals to him, a digital signature can be used.

What I described is, grosso modo, what the SSL handshake does when a browser connects with an SSL-enabled web server.

share|improve this answer
add comment

Don't take this the wrong way but...

I know the rough basics of how RSA and AES work but I can't figure out what is best.

If you only know the basics you might not be the right person solve this problem (yet). Security is one of those areas where you must be very particular and careful or else you invalidate your entire security setup.

Additionally I don't believe we have enough information to give you a proper answer. The business contracts about security expectations will have to be known up front.

In most cases keys never leave the machine they are generated on for security reasons, so if you intend to "share" information then a public key solution is usually the right pick from a purely security stand point. The exception to this is if you can share a symmetric key in a secure manner such as sending the key to the person on a physical media.

share|improve this answer
    
I don't think business contracts ever specify encryption details, nor should they in most cases as business users may choose obsolete / inappropriate technology. See @Gilles answer for a concise answer "Neither, unless it's both" ... and protocol selection is most applicable now. –  makerofthings7 Jan 23 '12 at 21:13
add comment

Basically, the use of public key encryption (such as RSA) is much more expensive than the use of symmetric key encryption (such as AES), and when there are many messages that pass from one to another, it is better to use a symmetric key.

Now, the creation and exchange of the symmetric key may be done using public key encryption.

For example:

Each client has a private-public key pair, and the public key is stored on the server. When two clients start communication session, each takes the public key of the other from the server and send an encrypted number to the other. Then each side hashes those two numbers and uses the result as the key to encrypt/decrypt the data from now on.

share|improve this answer
    
I understand that principle, what I wish to know is, does the symmetric key have to be generated each time communication commences, or am I safe to use the same key for that pair of clients day-in-day-out. –  Ben Dec 17 '11 at 23:59
    
I would suggest not to use the same key even for two messages, instead, pass some random with the message and use a hash of the key from before with this random to create the message key. –  MByD Dec 18 '11 at 0:00
add comment

Your Answer

 
discard

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