3
$\begingroup$

I want to use a stream cipher to encrypt a continuous bitstream. Additional to that, I want to generate an additional stream to guarantee the integrity of the ciphertext.

  • stream a: ciphertext.
  • stream b: integrity check on stream a.

I am aware of authenticated encryption where the MAC can be accumulated and sent. I want to avoid that.

Is it possible to do this by encrypting the same plaintext using a different algorithm, key or iv? Will that actually protect against say bit-flip attacks? Does it cause any vulnerabilities?

Is there a better (preferably cheaper) way to do this?

Note that this has to be done in hardware and I am extremely limited on energy so I can't add any sort of control logic.

Improve this question
$\endgroup$
5
  • $\begingroup$ I will have to do a bit of research but I think you can do this with an appropriate cipher supporting intermediate authentication tags. $\endgroup$
    – SEJPM
    Feb 9, 2018 at 14:14
  • $\begingroup$ Are you referring to something like Grain-128a? $\endgroup$
    – user3019917
    Feb 9, 2018 at 14:43
  • $\begingroup$ I was referring to something like COLM (PDF) (the only CAESAR candidate with this feature that made it into round 3). Where you essentially insert an authentication tag every few blocks into your ciphertext stream so that you only need to buffer like 1-128 encryption blocks. Something like this can also be achieved with more traditional modes using appropriate chunking as suggested by Squeamish Ossifrage. Of course there's a buffer-size vs message-expansion trade-off here. $\endgroup$
    – SEJPM
    Feb 9, 2018 at 19:31
  • $\begingroup$ BTW, you may be interested in this (very recent) attack on Grain-v1. $\endgroup$
    – SEJPM
    Feb 9, 2018 at 19:35
  • $\begingroup$ Very interesting suggestion. I think my only issue with this is that block cyphers are probably too expensive for my application. I think what I am looking for does not exist and I have to compromise or find another way. And thanks for pointing out the attack paper! $\endgroup$
    – user3019917
    Feb 13, 2018 at 9:32

1 Answer 1

Reset to default
6
$\begingroup$

Break your stream into chunks. Use an AEAD for each chunk using the chunk sequence number as a nonce. Anything else is going to have at best the same effect, but will be convoluted, full of holes for the first umpteen drafts, difficult to implement, and nonstandard, and will have the effect of making cryptographers look at you like you have three heads.

Or, use a system that was already designed to do this (in particular, STREAM).

Improve this answer
$\endgroup$
4
  • $\begingroup$ Unfortunately, the system I'm designing does not have the energy to perform any computation of that sort.Simply breaking a message into chunks is way out of my budget. I understand that it's not a standard solution, and that's not preferable, but I need it none the less. $\endgroup$
    – user3019917
    Feb 9, 2018 at 12:28
  • $\begingroup$ Maybe you can elaborate on what your computational budget is and how breaking a message into chunks is out of your budget? It's hard to imagine that you can process a message at all if you can't even split it into chunks. $\endgroup$
    – Squeamish Ossifrage
    Feb 9, 2018 at 15:03
  • $\begingroup$ I have close to 0 computational budget and I do not process the message. Breaking the stream into chunks is additional logic costing more energy which reduces my operational time. All I have is a continuous stream of bits and I want to use simple hardware techniques to cypher it continuously and have some sort of integrity check. So far, my research only led to methods where the MAC is accumulated and sent, this defies the point. I am reaching the conclusion that this may not be possible. But hoped someone could provide some insight. $\endgroup$
    – user3019917
    Feb 9, 2018 at 17:21
  • 1
    $\begingroup$ If you can't quantify the budget, then we can't help you to find whether anything will fit in it. Any stream cipher has computational costs. If you use, e.g., NaCl crypto_secretbox_xsalsa20poly1305, the MAC part of it is actually the cheapest part of the computation, and would remain so even if you replaced XSalsa20/20 by ChaCha8, using the slightly faster ChaCha core and driving the number of rounds down to the smallest unbroken number. It's hard to take the question seriously if you just say ‘close to 0 computational budget’. $\endgroup$
    – Squeamish Ossifrage
    Feb 9, 2018 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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