Help with product-specific AES encryption scheme

[zachary]

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

@IOTrav

Thank you @zachary

Yes you are absolutely correct in that the session initialization packet must change. We will change it each time with a session id which will increase for each initialization attempt so the cypher text will change each time session initialization is made. We planned on just incrementing 1 but we could even do more than that like exponential change of the session id. Your thoughts on this? I would love to discuss in further details but do not want to expose our security protocol to much publicly. I am creating a google doc right now outlining how we plan to handle security between the devices and our server. Is there a way I can send that to you privately and you could just do a quick check on my ideas?

We are extremely excited about this new line and are building a really cool prototyping device we have nick named the Spark Plug around here. Id love to send you a couple if possible for your help

Thanks again @zachary

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.

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!