Encryption / Authentication Library (SHA, HMAC, OTP)

Since the electric IMP connects the cloud to physical devices, security should be a big concern for everyone. It’s great that the communication with the planner server is encrypted but that still doesn’t provide protection if someone were to somehow figure out the API link for an IMP.

It would be great if electric imp could provide a library that implemented some of the basic encryption / authentication algorithms like SHA, HMAC, OTP, TOTP so that we wouldn’t have to each re-implement them from scratch. I’m in the middle of trying to port some TOTP code to Squirrel right now.


Daniel C.

A basic encryption library is in the works right now. It will allow you to perform SHA1 and (I think) MD5.

That’s great to hear.


I’ve spent many evenings working on a SHA1 class for Squirrel so I can send tweets from the agent. It’s been… interesting, and I haven’t successfully hashed anything yet, so I’m pretty excited about it.

I agree with @DanielC! Great question.

@beardedinventor, any progress on this library? Success in finding an existing one?

when might this basic encryption library be ready for some testing ?

I was able to get an SHA1() hash working in native squirrel (see attached). I based it on some native python code i found at https://github.com/ajalt/python-sha1 (thanks ajalt). I did run into one problem though. Its seems that my native squirrel interpreter returns a -1 for the modulus of -1 (-1%64). A quick google search indicates that it should return 63 which is what I get in python. Effectively this means that you can not hash a message larger then 55 characters with this code until this gets fixed.

@bodinegl - this is really great… really really great!!! I made some minor changes, and now it works in agents.

Here’s a link (let me know if you want me to attribute it in a different want).

Next step - Tweeting!

@beardedinventor, Thanks for the changes/suggestions. I have now finish building/testing a hmac_sha1() function. I also solved a number of problems like mod64, and left_rotate on a 32bit squirrel which is what the agent runs in it turns out. my local sq was 64bit. (lot of fun finding that)

I am with in a day of being able to tweet. I will post that when I get it working. I am currently getting a 400 with a 215 code. Its just a matter of formatting the OAuth header correctly I think.

@bodinegl a BIG thanks for this

I agree! Thank you.

That’s great! My foible for optimisations has me point out that left_rotate is (x << n) | (x >>> (32 - n)) using Squirrel’s unsigned-right-shift operator, and mod64 is a & 63. Also, it’s more efficient (especially on the device) if blobs are pre-allocated to their final size: mb=blob((message.len()+9+63) & ~63) etc.

But those are nitpicks, and the code is very useful as it stands!


@peter, thanks for the tips. I will incorporate these. I am very new to squirrel and can use all the help I can get. Any other suggestions and optimisations will be most greatly welcomed.

@peter, I found that left_rotate of (x << n) | (x >>> (32 - n)) worked on a 32bit sq,but sometimes failed on a 64bit sq where (x << n) | (x >> (32 - n)) & ~((-1 >> n) << n) worked correctly on both. I do know that the agent is currently running on a 32bit sq but will that always be the case?

The a&63 for mode64 works well on both and simplifies the code. much thanks.

“Always” is a long time. But switching agents to a 64-bit Squirrel would break tons of code in the field and so would be a crazy thing for us to do, even less likely than switching to a different language altogether.

The actual Squirrel binaries running on our server are 64-bit in the sense of being amd64 rather than i386, but we’ve patched Squirrel so that the Squirrel built-in integer and float types are 32-bit even on 64-bit platforms.


I have created a public repo for my imp library functions.


So far I have two nuts. hmac_sha1.nut which is tested/working and twitter.nut
which is not working yet but thought I would get extra eyes on the problem. Let me know if you see my blunder.


Well, I found another hint to the twitter oauth problem on https://dev.twitter.com/docs/auth/percent-encoding-parameters It seems that the RFC 3986 specifically states that “Write two characters representing the uppercase ASCII-encoded hex value of the current byte”. the http.urlencode() function is using lower case.

I just found this as well :slight_smile: I’m writing a new encode function.

Oh, you guys are just ruining all the fun it was to have to go from agent to xively to zapier to twitter just to tweet my grill temp! :slight_smile:


Here is a Twitter class so you can tweet too!