By that I mean encryption and authentication that's both strong and fits on a 328 easily (the way HTTPS / SSL won't)
Anyone with a copy of "Practical Cryptography" (Fergusson/Schneier) will know what I mean - the ability to send messages with either secrecy or authentication or both by means of shared secret "session" key.
There the authors describe an implementation using AES and HMAC, again too large, so I've been thinking of using XXTEA (with CBC-MAC) in a similar fashion. XXTEA is an improved development from TEA (tiny encryption algorithm) which takes up very little RAM and code. The use of suitable encryption mode and CBC-MAC means that only the enciphering code is needed, deciphering is not needed further reducing the foot print.
I've also been wondering if its feasible to construct browser plugins to handle the client-side when communicating with an Arduino/Ethernet shield combination.
The motivation is being able to provide rock-solid(*) protection against hacking of your home-control system over TCP/IP or the web. Its very nice to be able to feed your cat remotely, but you don't want some joker to dispense all the food at once (say).
The first step would be a library of crypto primitives and possibly an EEPROM key-safe.
IMNSHO, an algorithm is needed, but it must be compatible with off-the-shelf browsers/desktop/phone/operating systems. (otherwise you might as well run non-standard networking.)
Authentication is more important than encryption (alas, all "strong" authentications algorithms I know of are based on encryption.)
The first step would be a library of crypto primitives and possibly an EEPROM key-safe.
Sounds useful. I would like to see basic primitives suitable for just use with the basic arduino serial commands rather then just for networked Arduino/Ethernet application. Bare bone crypto as a learning tool.
Was in the teletype/crypto maintenance field in the Air Force in the late 60s and surely the 328 is much more powerful then those special purpose crypto system used back then, KW-26, KG-13, and those cute off line KL-7 units that looked about the size of present day lap-tops.
It would be nice if a PC-class machine were NOT the minimum size/performance/cost device for implementing the Things in the predicted "Internet of Things."
westfw:
IMNSHO, an algorithm is needed, but it must be compatible with off-the-shelf browsers/desktop/phone/operating systems. (otherwise you might as well run non-standard networking.)
That can be addressed by having a proxy than runs on a machine that can handle SSL/HTTPS - which can be shared by many end devices. And its not that unreasonable to provide an app/plugin at the client end anyway - this is for you controlling your own devices, you are not expecting random others to access it (in fact you want to discourage others, a DOS attack is not that hard to mount against an Arduino!!)
Authentication is more important than encryption (alas, all "strong" authentications algorithms I know of are based on encryption.)
You could argue that HMAC isn't technically encryption I suppose, but yes cryptographic primitives are required to provide security
Sorry, one more thing (related to crypto primitives) I wonder what the simplest/cheapest way is to create genuine (physically generated) random numbers on the Arduino - (zener) diode noise amplified and sampled?
Note: As far as I can tell, the technique does not work on modern Atmel processors. My suspicion is that the sample-and-hold capacitor has too low capacitance.
MarkT:
By that I mean encryption and authentication that's both strong and fits on a 328 easily (the way HTTPS / SSL won't)
Anyone with a copy of "Practical Cryptography" (Fergusson/Schneier) will know what I mean - the ability to send messages with either secrecy or authentication or both by means of shared secret "session" key.
There the authors describe an implementation using AES and HMAC, again too large, so I've been thinking of using XXTEA (with CBC-MAC) in a similar fashion.
Are you aware of the AVR crypto library? It's specifically designed for use on AVR microcontrollers. Most of the common authentication and encryption schemes you might want seem to be implemented. I've only used it for HMAC-MD5 message authentication on an Arduino Mega2560; it worked fine with no problems. You might need to edit the headers or wrap the #include lines to indicate C linkage, eg:
MarkT:
Sorry, one more thing (related to crypto primitives) I wonder what the simplest/cheapest way is to create genuine (physically generated) random numbers on the Arduino - (zener) diode noise amplified and sampled?
stevemarple:
Are you aware of the AVR crypto library? It's specifically designed for use on AVR microcontrollers. Most of the common authentication and encryption schemes you might want seem to be implemented. I've only used it for HMAC-MD5 message authentication on an Arduino Mega2560; it worked fine with no problems. You might need to edit the headers or wrap the #include lines to indicate C linkage, eg:
Interesting, that seems to be a fairly generic collection of implementations, but rather patchy (has XTEA which is deprecated, but not XXTEA, has only a few sets of test vectors and seems to lack references to the relevant crypto papers - safer to go to the author's reference implementations. The patent status of algorithms isn't mentioned either. BTW MD5 has been deprecated since 1996 and totally broken since Tunnels in Hash Functions: MD5 Collisions Within a Minute - this ought to be common knowledge.
MarkT:
The patent status of algorithms isn't mentioned either.
As far as the crypto algorithms themselves, I believe there are no issues. I'm going to be lazy and not spend any time right now investigating, but IIRC, in order to be a NIST std., they have to be either not patented, or royalty-free. The BSD and Linux crypto libraries wouldn't be using them if this were not the case -- I'm talking about things such as AES and Blowfish, RSA, DSA, Diffie-Hellman, etc.
MarkT:
Interesting, that seems to be a fairly generic collection of implementations, but rather patchy (has XTEA which is deprecated, but not XXTEA, has only a few sets of test vectors and seems to lack references to the relevant crypto papers - safer to go to the author's reference implementations. The patent status of algorithms isn't mentioned either. BTW MD5 has been deprecated since 1996 and totally broken since Tunnels in Hash Functions: MD5 Collisions Within a Minute - this ought to be common knowledge.
For HMAC-MD5 I used the RFC 2202 test vectors so I wasn't bothered about their absence. Although MD5 on its own should be considered broken HMAC-MD5 does not suffer from the same weaknesses.
MarkT:
Interesting, that seems to be a fairly generic collection of implementations, but rather patchy (has XTEA which is deprecated, but not XXTEA, has only a few sets of test vectors and seems to lack references to the relevant crypto papers - safer to go to the author's reference implementations. The patent status of algorithms isn't mentioned either. BTW MD5 has been deprecated since 1996 and totally broken since Tunnels in Hash Functions: MD5 Collisions Within a Minute - this ought to be common knowledge.
For HMAC-MD5 I used the RFC 2202 test vectors so I wasn't bothered about their absence. Although MD5 on its own should be considered broken HMAC-MD5 does not suffer from the same weaknesses.
You have a proof of security of HMAC-MD5 then? Or aware that everything MD4/MD5/SHA-1 is slowly and surely crumbling to cryptanalysis such as: http://dl.acm.org/citation.cfm?id=1533683 ?
Or aware that everything MD4/MD5/SHA-1 is slowly and surely crumbling
Your reference says that there's a 2^97 query attack against MD5/HMAC, whereas wikipedia says that there's a 2^59 query attack against XXTEA. I'm not qualified to know what the other details of the papers mean But I think we need to take a good look at just how much security is appropriate. While I don't want the internet at large to turn my networked sprinklers on and off as a prank (ie "nothing" is too little), I am also neither a likely target for a serious attack, nor will thousands of lives be lost if in fact the yard if flooded and my water bill goes up.
The attack against XXTEA is for large blocks (where the number of rounds is reduced), not against 128 or 256 bit XXTEA AFAIK... Another possibility for a small encryption algorithm is TwoFish I believe, haven't looked at that yet. Large block XXTEA does only 6 rounds, 128 bit blocks means it does 20 rounds, 256 bit blocks and it does 14 rounds.
But I think we need to take a good look at just how much security is appropriate. While I don't want the internet at large to turn my networked sprinklers on and off as a prank (ie "nothing" is too little), I am also neither a likely target for a serious attack, nor will thousands of lives be lost if in fact the yard if flooded and my water bill goes up.