SparkFun Forums

[brennen]

Hey guys. I am now working on a wireless protocol to use with the Nordic 24L01 chips. I want to do some encryption, but I have never studied actual encryption algorithms. I have used the cryptography library with .NET in C#, but that doesn't help me much when it comes to the embedded side of things. Do any of you guys have any suggestions on what algorithms would be good to use in embedded applications? Any links would also be really helpful. Thanks.

FYI - I'm using a Philips LPC2148 ARM7 uC, which has (IIRC) 40 kB of RAM and runs at 60 MHz. The Nordic chip is transmitting data at 2 Mbps.

[awalton]

Protip: Study encryption algorithms. There is plenty of information on them, and reference implementations for just about any algorithm you could imagine that is not only open source, but often liberally licensed for use with your application.

Embedded-wise, good luck. Most encryption algorithms don't lend themselves to being embedded very nicely, which is why it's so often implemented in hardware instead.

[brennen]

I tried some Googling but I didn't turn up too much, although I didn't spend too much time on it. I may pick up a book on encryption, and I think we have a class on encryption at my school.

As far as embedded goes, I was sort of afraid of that. I'm hoping to find some light-weight encryption scheme that will actually work in software, so I'll keep on looking. Thanks for the info.

[mare]

Maybe you could start here:

http://www-users.cs.york.ac.uk/~matthew/TEA/TEA.html

[brennen]

That looks pretty useful. I'm definitely gonna check into that.

[saipan59]

While you're studying up on encryption techniques, you should keep in mind what your real goal is.

For example, consider these questions:
1) Is the purpose simply to hide the contents of a message?

2) What if the bad guy intercepts and records your encrypted message. Can he use it to manipulate your system by sending the same message himself (even though he can't read the contents)?

3) How secure do you need to be? Who is your 'adversary'? If it is the NSA, then you should use the best system you can. Or, is it just your teenage neighbor, who has a Radio Shack scanner?

Pete

[riden]

Ditto on what Pete said about identifying your security requirements. One question that I ask myself is how long does this information need to be secret. In other words, if I have session information that is only valid for n number of minutes and doesn't contain information that could be useful i n the future, I only need an algorithm that resists cracking for n minutes or longer. Who cares if you were able to discover my one time PIN was "12345" (also the combination to my luggage) 1 year after it expired.

TEA and XTEA are block ciphers that require 32 bit math, exponentiation, and varying about of RAM to store the working tables. Since they are block ciphers, you need to assemble your data in blocks (i.e. your block size is 8 bytes and you want to send 1 byte, you will need to supply 7 other bytes to fill out the block). They can be very secure at the cost of computational overhead and processing resources.

You may find using a stream cipher such as ARC4 is better suited for your application since they work by feeding bytes in one at a time and you get them out one at a time on the other end. They are very simple to implement and provide reasonable level of protection. Here is a WikiPedia page on stream ciphers to get you started.

The fine print...
Whatever approach you take, you need to be aware of any patents that may be in force, and what restrictions are placed on the use of ciphers by your governmental authorities.

[brennen]

1) Is the purpose simply to hide the contents of a message?

At this point, yes.

2) What if the bad guy intercepts and records your encrypted message. Can he use it to manipulate your system by sending the same message himself (even though he can't read the contents)?

Right now I'm looking at securing wireless digital audio, but I plan on developing new applications that may be more sensitive. So right now, it's not that big of a deal if the bad guy gets my message, and sending the message will pretty much just give a nice little audible click at the receiver.

3) How secure do you need to be? Who is your 'adversary'? If it is the NSA, then you should use the best system you can. Or, is it just your teenage neighbor, who has a Radio Shack scanner?

I don't have an adversary as of yet, but I feel that at some point I will. I'm mainly looking to just get my feet wet right now with something simple and build on that as I go, which is one reason that TEA/XTEA looked really good.




ARC4 looks to be a pretty interesting encryption algorithm, and seems to be more suited to wireless applications. I will assume that since "ARC4" is basically a hack of the RC4 encryption algorithm, it isn't really copyright protected, since you wouldn't be licensing RSA's code. I know that TEA/XTEA are not subject to patents, according to the Wikipedia articles on them.

My question with ARC4 is, however, what happens if you don't have the transmitter and receiver synchronized together. For example, your transmitter loses power and re-initializes it's key array when it is powered back up, and then tries to send data again. Does the receiver also have to re-initialize before the data received makes sense, or will the stream still work without the receiver re-initializing?

[saipan59]

A bit of trivia, perhaps not completely relevant:

In a truly secure system, one rule to follow is to never depend on your hardware as being the basis for your security. That is, you must assume that the enemy has the *exact* same HW as you do, and he knows how it works. This means that the security comes from in essence some type of 'setup' feature of the HW, such as a password. If the system is inherently secure, then knowing everything about the HW will not help you decrypt a message unless you have the password.

Many (most??) cipher systems ultimately rely on a random number generator at some point. Otherwise, software can quickly model the algorithm that is used to encrypt the data. Unfortunately, most random generators are not truly random. Also, the person on the other end must be able to reproduce the *same* random sequence that you used, so that they can decrypt the message.

In WWII (the OSS) and during the first part of the Cold War (the CIA), a system called a "one-time pad" was used extensively. The pad is nothing but a long list of random letters. The old 1-time pad system is *truly unbreakable* (there is no mathematical attack that will break it), assuming the following:
1) The letters on the pad are truly random.
2) Both sides of the communication have the same pad.
3) The enemy does not have access to the pad.
4) A given set of letters on the pad is *never* used more than once.

For some more historical info, see my 'online research paper':
http://militaryradio.com/spyradio/otp.html

Pete

[riden]

ARC4 looks to be a pretty interesting encryption algorithm, and seems to be more suited to wireless applications. I will assume that since "ARC4" is basically a hack of the RC4 encryption algorithm, it isn't really copyright protected, since you wouldn't be licensing RSA's code. I know that TEA/XTEA are not subject to patents, according to the Wikipedia articles on them.

RC4 is not patented, but RSA's implementation is copyrighted. ARC4/ARCFOUR are independent implementations of the RC4 algorithm.

My question with ARC4 is, however, what happens if you don't have the transmitter and receiver synchronized together. For example, your transmitter loses power and re-initializes it's key array when it is powered back up, and then tries to send data again. Does the receiver also have to re-initialize before the data received makes sense, or will the stream still work without the receiver re-initializing?

Actually you would have this problem with a block cipher as well. In both cases the data could be sent in packets so the receiver can get back in sync when the next packet arrives, or the transmitter can send a special escape sequence that will cause the receiver to reinitialize itself. The second approach (escape sequence to reset) is more complex and might be more problematic than it is worth. I'd opt for the packet approach and address any performance issues that might arise.

Using the lightest algorithm for your application will free your ARM for other processing.

[wiml]

IIRC, RC4 is a secret algorithm. ARC4 is a well-known, non-secret algorithm which may or may not be the same as the sooooper-seeekrit RC4 algorithm, but which happens to behave exactly the same in all known cases. The "A" stands for "alleged".

I strongly recommend Bruce Schnier's book Applied Cryptography. It's a few years old now but it gives you about all the info you need to do basic crypto stuff.

[mare]

sci.crypt is good sorce, too

[brennen]

I strongly recommend Bruce Schnier's book Applied Cryptography. It's a few years old now but it gives you about all the info you need to do basic crypto stuff.

Apparently this book is really popular, because my network application design teacher was talking about how it's like the end-all book on encryption yesterday in class.

[brennen]

OK, guys, thanks to your help, I have a working ARC4 implementation in C#. Now I just need to port it to C so I can use it in my system.

[exelty]

http://www.matrixssl.org/index.html