Cryptography Entry: Sensor messages Date: Sun Jan 21 11:33:48 EST 2018 Don't roll your own crypto. Though it appears I have to. Application: remote sensor. I want to implement this in a way that does not trust the host it is plugged into. This is a temperature sensor. Snooping is not a problem (for now). However, authentication is. I'm thinking about HMAC, which needs protection against replay. Both sides can be made to maintain state, however it would be great to avoid this on the sensor side. Time stamps cannot be trusted when they are initialized from the host. Entry: How and when do I use HMAC? Date: Sun Jan 21 11:38:45 EST 2018 https://security.stackexchange.com/questions/20129/how-and-when-do-i-use-hmac/20301 Entry: Practically, do I know anything that will work on a uC? Date: Sun Jan 21 11:42:54 EST 2018 The main issue is to establish an encrypted, authenticated connection between two sensor/actuator nodes connected across an unsafe network. The only practical way I know how to do this, is SSH. What is the minimal complexity needed to establish an SSH connection? Entry: Where to ask questions? Date: Sun Jan 21 11:45:56 EST 2018 https://security.stackexchange.com/ Entry: HMAC for query, response Date: Sun Jan 21 11:48:39 EST 2018 Basically, I have no actual code I can reuse, so start with rolling something out, then replace it later. Entry: STM32 crypto Date: Sun Jan 21 11:50:44 EST 2018 http://www.st.com/content/st_com/en/about/media-center/press-item.html/n3844.html http://www.st.com/en/embedded-software/x-cube-cryptolib.html?icmp=tt3896_gl_pron_jul2016 Entry: HMAC + time stamp Date: Sun Jan 21 12:56:47 EST 2018 Are time stamps enough to secure sensor readings? https://en.wikipedia.org/wiki/Replay_attack Bob->Alice: timestamp,hmac Alice->Bob: data,timestamp,hmac Maybe this way of "polling sampling" is enough?