Help with product-specific AES encryption scheme

Continuing the discussion from AES encryption demo and secure TCPClient usage:

You are very welcome @IOTrav!

First, I love discussing cryptography nuts & bolts (crypto and haskell are probably my areas most vulnerable to nerd sniping), but as Spark’s CTO, I don’t have the bandwidth to provide too much one-on-one support. Also, I’m about to go on my first vacation since Spark started in 2012, so I won’t be responding for the next week. :smiley: :sunny: :ocean: :sunglasses:

Regardless of those facts though, I highly recommend keeping security reviews public. Spark’s entire protocol and encryption scheme are open source; you can see everything we do.

It definitely takes hard work and careful thought to determine exactly which parts of a protocol are publicly reviewable mathematical processes, which parts are secrets, which parts are cryptographically random, and which parts are predictable. For us:

  • The private keys of both the device and the cloud are secret.
  • The nonce and session credentials created by the server are random.
  • The plaintext messages that will be sent by each side are somewhat consistent (i.e., predictable) right at the beginning, but the longer a device runs, the less predictable the messages are, both in timing and content.
  • Interestingly, (thank you AES CBC and tropicssl) our IV rotation scheme is completely public, it’s just not predictable more than a few seconds in advance of any given message and then only for an active listener.

I strongly encourage you to do the work required to publicly discuss your intended algorithm. Lots of people here other than me can weigh in on the pros and cons.

And of course, in reality, an encryption scheme doesn’t need to be mathematically perfect—it needs to be good enough for the specific risks to your product. For example a door lock is much more sensitive than a device that turns a light bulb on and off.

But security by obscurity (just because you didn’t talk about it publicly) is barely any security at all; anyone who sincerely wants to reverse engineer something can, and if you’re successful with a product, it’s only a matter of time.

Best of luck! Let’s talk crypto! :smile_cat: