[rthille]

You don't need TLS for that, you could simply use an HMAC and a shared secret, assuming you're not worried about people with physical access (and ability to get the secret) being able to create updates. Of course if you've got multiple instances of the device (not some hobby thing where they are all owned by you), then the secret for each device should be different so someone can't buy the device, determine the secret and then push updates to other people's devices.

[conradev]

Wouldn't signing each release with a private key be the simplest solution here?

(that can take many forms, but that general idea is how most software updates currently work)

[revelation]

RSA means big integer which means unhappy performance on devices that often don't even have floating point in hardware. I think elliptic curve could be faster?

[erichocean]

> I think elliptic curve could be faster?

Yes, EdDSA is faster, with 64 byte signatures. Recommended.

https://en.wikipedia.org/wiki/EdDSA

[adrianN]

Verifying a signature is not the simplest thing to do on hardware that doesn't even support a normal OS.

[conradev]

I see, that makes sense. Let's say you implement verification as:

1. Hashing the incoming data

2. Decrypting an attached signature

3. Verifying the decrypted and calculated hash are the same

Even though Step 2 would involve RSA or ECC, wouldn't Step 1 be the most expensive part regardless?

[baby]

Yup you are right.

[captn3m0]

Not a very good idea, for the very reasons you point out. Signed releases with public keys, as conradev points out below is the far better approach.