3

I need to establish potentially infinite secure streams of data between many remote devices with very few resources. Chacha20 is lightweight enough, but I do not trust myself to implement a reliable nonce agreement protocol between devices.

One option is to use XChacha20 and random nonces, but I can not afford the performance reduction. Other option, the object of this question, is to generate a random 128 bits nonce and use it as both the conventional 64 bits nonce and the 64 bits counter.

Is there any references about the security of such a construction?

Some notes:

  • All devices use same secret key.
  • Public key cryptography is not an option due processing power and memory constrains.
  • Devices are mobile, so any connection can fail at any time, requiring to reconnect again.
Ella Rose
  • 19,603
  • 6
  • 53
  • 101
user3368561
  • 603
  • 5
  • 13
  • 4
    A little offtopic note: I just want to suggest to make sure you're using a MAC such as Poly1305 with it, a block/stream cipher on its own is not enough to ensure data integrity. – Mark Feb 05 '18 at 17:46
  • 1
    Why do you need to agree on nonces? Are you using them to detect and prevent replay? Are multiple parties sending messages using the same key and if so why can't you use multiple keys? Or are you meaning a use of nonce that's more of a salt? – Thomas M. DuBuisson Feb 05 '18 at 17:50
  • @ThomasM.DuBuisson Devices are very resource constrained and I need to implement all the code in assembly. There are no public key libraries available that fit my device nor I want to implement it myself. All devices will use same secret key for long time. Because all devices can start new connections when needed, I need to be sure that they never will use same nonce again. – user3368561 Feb 05 '18 at 18:07
  • Can't you any pair of devices that want to communicate agree on a temporary (cached) session key using symmetric key agreement? – SEJPM Feb 05 '18 at 19:55
  • @SEJPM The problem is that I haven't found any small enough symmetric capable cryptography library to fit my devices, so I will need to implement it myself, something that I'm not able to do securely. – user3368561 Feb 05 '18 at 20:08
  • 2
    What is your budget, if ChaCha fits in it and XChaCha does not? Do you have to use the full 20-round ChaCha or could you tolerate ChaCha12 or ChaCha8? What is the protocol you're hoping to build out of this? – Squeamish Ossifrage Feb 05 '18 at 20:56
  • @SqueamishOssifrage XChaCha20 fits, but its performance is 1/2 and his power consumption between 1-2 times higher. About lower round count, its a wireless application for long lived devices with public access. I don't want to loss security if I can avoid it. – user3368561 Feb 05 '18 at 21:35
  • 1
    @user3368561 So what is your budget and what are you trying to do with the stream cipher? – Squeamish Ossifrage Feb 06 '18 at 00:54
  • @SqueamishOssifrage I don't understand your question. – user3368561 Feb 06 '18 at 01:10
  • 4
    @user3368561 If you ‘can't afford the performance reduction’, there must be some budget (in joules? watts? cycles? RAM?) that XChaCha20 exceeds. Any other putative answer would presumably have to fit within that budget, but it's hard to say what will without knowing the budget. And to really give a useful answer it will be necessary to consider how you are using the stream cipher: what communication are the devices trying to do, what state do they have available, etc. – Squeamish Ossifrage Feb 06 '18 at 01:13
  • 1
    @SqueamishOssifrage Power by itself isn't a problem, but reducing it is always welcome. Speed is the problem. My current implementation of ChaCha20 can saturate my communication channel; XChaCha20 will waste half of the available bandwidth. Space is another problem. Devices are very heterogeneous, but smaller ones can have as low as 2 KiB of flash memory. I need a protocol that works for all them. I'm using the stream cipher to secure continuous, potentially endless data streams coming from sensor capable to generate very high volumes of data. – user3368561 Feb 06 '18 at 01:56
  • 3
    If there are many remote devices, and all of them share the same secret key, then that key is no longer a "secret"; it's at best a "discreet". – Thomas Pornin Feb 07 '18 at 14:49
  • @ThomasPornin Key is flashed at manufacturing time and hardware protected. – user3368561 Feb 07 '18 at 18:14
  • 3
    It is far easier for someone to just break the hardware protection (yes, it happens) than it would be for them to break even ChaCha8. Why do you use this as a session key rather than for authentication purposes? There are several very lightweight key exchange protocols out there. – forest May 09 '18 at 05:37

0 Answers0