3
$\begingroup$

I'm building a small VoIP client which transmits encrypted audio data via UDP, and some packet loss is expected, so each packet will need to be decrypted separately even if others in the stream don't arrive. I also don't enforce strong ordering of data, since re-ordering is done only if a packet is significantly out of step.

I know some modes like CBC require the previous ciphertext block to be known in order to decrypt the next block, so I don't see that being suitable. ECB is ideal in terms of the "decryptability" requirement, but obviously it's not secure. I figure OFB might be useful, but I can see the implementation being awkward if multiple blocks are skipped.

Are there any modes of operation that suit this kind of scenario, without significant implementation overheads?

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ Side-node: Compressing audio easily leads to side channel attacks. $\endgroup$
    – CodesInChaos
    Commented Nov 29, 2012 at 7:47
  • $\begingroup$ @CodesInChaos I'm aware, though the compressed data is a constant size per packet. I think the packets-vs-time domain is where side channel leaks are likely to occur, which I'll have to research further in order to discover a solution. $\endgroup$
    – Polynomial
    Commented Nov 29, 2012 at 8:38

2 Answers 2

Reset to default
6
$\begingroup$

Reflex answer: EAX. EAX does encryption and authentication, with minimal space overhead. EAX also has light requirements on the IV: it just needs a non-repeating value, so a simple counter can work. Possibly you already have a suitable counter or time stamp in your packets, that can be used as IV.

About replay attacks: you already expect that some packets will be dropped, or reordered. Be warned that if your protocol tolerates it, then the attacker can force it upon you, mechanically. I suppose that your protocol already includes some sort of frame counter so that you can reject frames which are too old (or too new !) and merge duplicates. That frame counter would work nicely as an IV for EAX.

If you want to do it old-style, use CBC with a random IV (IV must be transmitted along the packet), and then a MAC (HMAC, for instance) computed over the encrypted data (including the IV) and appended to the packet. You will need more code, cryptographically strong generation of an IV for each packet, and space overhead is likely to be higher than for EAX. That's the price of being old-style.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Won't CBC require the previous ciphertext block, therefore making one lost packet destroy the next? $\endgroup$
    – Polynomial
    Commented Nov 29, 2012 at 8:33
  • 1
    $\begingroup$ @Polynomial: No, because each packet should have its own random IV. In fact, using the last block of the previous packet as the IV in CBC mode is a bad idea. $\endgroup$
    – Ilmari Karonen
    Commented Nov 29, 2012 at 8:42
  • $\begingroup$ @IlmariKaronen Hmmm, is there a reason why Wikipedia describes CBC as using the previous ciphertext block? I can see that a single unique IV should be used for the conversation (i.e. the full stream of blocks), but not per-block. $\endgroup$
    – Polynomial
    Commented Nov 29, 2012 at 8:48
  • 1
    $\begingroup$ @Polynomial: Typically, each message (= packet) you encrypt will consist of more than one block. Within a message, the blocks are chained together by (in effect) using the ciphertext of the previous block as the IV for encrypting the next one. However, this is only secure against chosen-plaintext attacks as long as there's no chance of an attacker seeing the ciphertext of the previous block before the plaintext of the next block is received. $\endgroup$
    – Ilmari Karonen
    Commented Nov 29, 2012 at 8:52
  • 1
    $\begingroup$ Ps. Other integrated AEAD modes, such as GCM, would also make good reflex answers. $\endgroup$
    – Ilmari Karonen
    Commented Nov 29, 2012 at 8:54
5
$\begingroup$

What about using CTR in that case ? As long as you know the index of the incoming packet you can decrypt it without needing any of the previous or subsequent packets. Do you need integrity as well ?

Improve this answer
$\endgroup$
1
  • $\begingroup$ CTR looks like it could do the job. Yes, integrity will be required. I was thinking of using a MAC, but if you know of a better solution I'm all ears! :) $\endgroup$
    – Polynomial
    Commented Nov 29, 2012 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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