1

I'm running my TCP/IP protocol secured by encrypting each packet with AES128/CBC, bundling a SHA256 HMAC over that packet.

This causes quite a bit of space overhead for small packets, so at first I was thinking of running AES in CTR-mode and still use the HMAC, but it would be much better to run some sort of stream cipher with integrated authentication.

What are my best options in keeping overhead small?

Improve this question
8
  • 1
    Why oh why are you not using SSL, Dave? The protocol has been heavily vetted, tested, and protected against all sorts of vulnerabilities that you in your wildest dreams would never have even considered. If you're directly using AES, you're doing it wrong. No really, you actually are doing it wrong.
    – tylerl
    Commented Jun 16, 2013 at 6:35
  • @tylerl - Because I don't want the SSL hammer. And because I know exactly the trade offs I want in terms of security. And because I want fine grained control of my communications to ensure maximum scalability. And because I think cryptography is extraordinarily interesting. So really. You should not make assumptions.
    – Nuoji
    Commented Jun 16, 2013 at 9:47
  • @Nuoji, I think you shouldn't take offense so quickly. tylerl has a perfectly valid question. And none of those sound like convincing technical reasons to me. So my advice would be the same as tylerl's: re-examine carefully whether you could be using SSL, and whether you have any technical requirements that rule out SSL. Don't underestimate the risks of introducing subtle security vulnerabilities if you try to craft your own replacement for SSL on your own; it's very easy to get over-confident.
    – D.W.
    Commented Jun 17, 2013 at 0:03
  • @D.W. I know I shouldn't take offense, but I didn't start working on this yesterday. If I use SSL, I will have to use the black box that is a SSL implementation. From a technical perspective, it's very hard to create a robust, scalable and predictable server engine from that. Then taking into account that I only need a subset of SSL - for example, all certificates will be known a priori - it's very hard to see that SSL is a good fit. Since I know how gnarly this is, I've presented various versions of the protocol here and elsewhere to get feedback.
    – Nuoji
    Commented Jun 17, 2013 at 7:17
  • @Nuoji, my suggestion is to post your requirements (in a separate question, please). It's possible there might be an existing, vetted protocol that might suit your needs: e.g., DTLS, OpenVPN, IPSec, etc.
    – D.W.
    Commented Jun 20, 2013 at 0:07

2 Answers 2

Reset to default
4

Use any authenticated encryption mode.

That could be a stream cipher with built-in support for authentication (not what I would recommend; all of the candidates are still bleeding-edge), any standard authenticated encryption mode (e.g., GCM, EAX, etc.); or use encrypt-then-MAC with AES-CTR and a suitable MAC (e.g., AES-CMAC or SHA256-HMAC). Any of those will be fine. You have not given us any requirements that would rule any of those out. All of them allow you to select the size of the MAC tag, so you can control the overhead vs. security tradeoff.

But really, you'd probably be better off using TLS or DTLS -- at least, most folks probably would be. (I know you said you don't want to, but I haven't heard any compelling technical reason not to use them.)

Improve this answer
1
1

Assuming your protocol is stateful (i.e. you only need to send the parameters - such as the nonce/IV - once), then the overhead of using an AE mode should be very small. CCM for instance has a fixed overhead of as little as 4 bytes (depends on the desired MAC size). Since the minimum size of a TCP/IP packet is 40 bytes, that's a maximum 10% increase in size (for the empty message). By contrast, the SHA256 HMAC alone needs 32 extra bytes.

Disclaimer: I'm not really experienced enough to say if this is enough to achieve the security properties you need. In an answer to one of my earliest (and stupidest) questions, Tom Leek said:

An open SSL connection implies a very slight overhead compared with raw unprotected data: in practice, about 30 extra bytes per record (it depends on the cipher suite), each record able to hold up to 16384 bytes of data, so we are talking about less than 0.2% of size increase, and you would get that with any other protocol which ensures confidentiality and integrity anyway.

Since an AE mode should provide "confidentiality, integrity and authenticity", then something must be wrong here (did I forget something that must be sent besides the ciphertext on each message? or is it because of the "stateful" requirement?)

Improve this answer
4
  • 1
    Isn't CCM with a 4 byte HMAC virtually equivalent (although possibly more cpu efficient) to cutting a SHA256 HMAC 32 byte key down to 4 bytes?
    – Nuoji
    Commented Jun 14, 2013 at 21:57
  • @Nuoji my gut feeling says "yes", but only someone experienced with the internals of MACs can answer that definitely. In other words, I'm not sure whether or not a truncated MAC is weaker than a smaller but whole MAC (note also that CCM uses CBC-MAC, which may have different properties than HMAC).
    – mgibsonbr
    Commented Jun 14, 2013 at 22:37
  • I believe any HMAC with a decent hash function should evenly distribute across all bits, or it would be biased. That should mean that reducing the number of bits would simply change the difficulty for a brute force attack.
    – Nuoji
    Commented Jun 14, 2013 at 22:55
  • 1
    I don't know about CCM's properties, but truncating HMAC is as safe as it can be (unlike truncating GMAC).
    – CodesInChaos
    Commented Jun 16, 2013 at 21:13

You must log in to answer this question.

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