12

I would like to create application for encrypting SMS messages. After long enough discussions I decided to use symmetric encryption, since handling public/private keys issue is too difficult for most of users.

So I suppose that secret key has to be transferred over voice interaction between parties or other method.

My question is: what will be suitable algorithm for encrypting SMS? Cipher must consider max length of message 160 chars and accepting only printable symbols. Message chunking and all kind of around issues - are unacceptable. I know that some phones can automatically merge chunked messages, but keeping in mind great diversity of makes/models - it's unworkable.

Any thoughts, advices?

5
  • 1
    And how are you planning on handling this on the client? Phones today dont have encrypted SMS builtin, which means you'd build a custom app... and if you're doing that, why bother with SMS?
    – AviD
    Feb 17, 2011 at 9:32
  • 1
    For sure both parties will have the same applications in their phones. Without that it's useless
    – Barmaley
    Feb 17, 2011 at 9:45
  • let's assume we're looking to encrypt "160-char messages" and it doesn't matter whether they're distributed over SMS or some other protocol. The important question that remains is what is the lifetime of these messages? Should they be safe from interception for five minutes after distribution or five years? Five decades??
    – user185
    Feb 17, 2011 at 10:23
  • 1
    @Graham ok, let's say there are 2 options: 1st - lifetime for 5 minutes, another one for 5 years. What will be your solution?
    – Barmaley
    Feb 17, 2011 at 12:46
  • Not affiliated with the company, and not trying to discourage you from making this, but doesn't Textsecure (whispersystems.org) already do this (it is also available on Android)? You could try their approach for SMS encryption for starters...
    – Nasrus
    Nov 23, 2014 at 11:46

3 Answers 3

9

I would urge you to revisit your premise. If both endpoints will have an app on it, then your criteria for choice of algorithm are not valid: the app will be handling the encryption/decryption, not the user. Public-key crypto can potentially provide better security in this context; for instance, it may enable trust-on-first-use (SSH-like) key management. Also, I'd suggest that you start by first thinking about the threat model. The first question should not be, what crypto algorithm do I use? Your first question should be, What threats am I trying to defend against?

If you must use symmetric encryption for SMS texts, AES in CBC mode with ciphertext stealing is a plausible choice. Ciphertext stealing will avoid waste if the message to be encrypted isn't an even multiple of 16 bytes. You will still need an IV, which will take up some space. To save space, you could send a counter, and use the AES encryption of the counter as your IV.

If there's any way you can avoid transporting ciphertexts over SMS, avoid it. 160 characters is very limiting. Can you transport messages over the Internet?

If you can avoid tunneling over SMS, you might explore a model where the app has its own private/public key, and maintains a public key for each contact. When contacting someone new, the app sends its own public key, receives a public key from the other person, remembers that public key, and sends the message encrypted with that public key. This is of course vulnerable to man-in-the-middle attacks but may be easier to use.

1
  • 1
    Agreed - encrypting SMS is a silly idea - you still have the problem of having to run custom software at both ends just to make it happen - even before considering the limitations on size. Using a wap push makes a lot more sense - or even just firing out a URL which requires a client cert or other authentication to access content.
    – symcbean
    Feb 18, 2011 at 15:02
4

If you're trying for a diversity of makes and models, it simply isn't going to work--although many smartphones allow third-party software to send SMS messages through internet gateways, all but the most open phone operating systems don't allow 3rd party software to handle incoming SMS messages.

However, if we disregard the impossibility, 128 AES should work fine. That'll give you a ciphertext no bigger than the plaintext; 8 of which can fit into a 140 byte SMS. Using SMS's character encoding, that means you still have 146 characters of message.

Since you specified symmetric encryption, I'm more than happy to leave the problem of key distribution up to you!

1
  • 2
    Primary target platform is Android based smarts - I don't see why I couldn't implement it
    – Barmaley
    Feb 17, 2011 at 19:40
0

You will need to use either AES or combination of AES+RSA. Now comes the issue of 160 characters. Actually the payload available is only 140 bytes. In mobiles (GSM or CDMA); 140 available bytes are encoded into 7 bit encoding hence allowing to put 160 characters in 140 bytes.

Now since SMS is the channel, and encryption is to be done than the mode of communication can no longer be text message but Binary Message. A binary message will take extra 7 byte for UDH (User Data Header). So the number of characters you can operate on is only 133.

I think if you are using SMS channel, than you need an APP in both ends. You can use port based messaging; using which the message will directly be processed by the end application and not the native inbox.

One advantage of SMS channel is store and forward protocol, means the chances of other party receiving the message is high, the problem is delay and the payload limitations. Using application level segmentation you could send long messages as well.

Another advantage of SMS channel, is that in a two way communication, it will be confirmed that the real trusted party is only involved in the messaging. A can spoof to be B while sending an SMS to C; but when C responds it will always go to A only. So using 2 way negotiations you can build a key generation and sharing algorithm for mutual communication.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .