5 ms·
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
by rthille 10y ago
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 10y agoWouldn'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)
- adrianN 10y agoVerifying a signature is not the simplest thing to do on hardware that doesn't even support a normal OS.
- conradev 10y agoI 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 10y agoYup you are right.
- revelation 10y agoRSA 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 10y ago> I think elliptic curve could be faster? Yes, EdDSA is faster, with 64 byte signatures. Recommended. https://en.wikipedia.org/wiki/EdDSA https://en.wikipedia.org/wiki/EdDSA
- captn3m0 10y agoNot 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.