Encryption Algorithm

The implementation is not really different when done in software as it is on any other platform including PC's. If you tell us WHICH encryption algorithm you are interested in, I'm sure you get more concrete answeres. Since Microcontrollers usually don't have that much number crunching power, such code is often hand optimized in assembly and/or compromises are made with regard to the strength of the encryption used (i.e. the number of "rounds" is lower etc.)

Markus

In article , Tina writes

Which cipher? Which micro?

There are a whole load of cipher implementations on my web site (none mine I just collected them from all over the place)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

I suggest that you take a look at the XOR algorithm, which is quite usable with the One Time Pad (OTP) approach.

Of course, it is your problem to distribute the key in a secure way:-).

Paul

Nice collection, thanks for sharing it!

Please change Schneider -> Schneier.

Oliver

Thanks all for the reply. I'm planning to implement the algorihm using 8051 controller and stream cipher encryption.

For which see:- The Third Man, any James Bond, etc :-)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

In article , Tina writes

Then see the stuff on my web site as there are some 8051 cipher implimentations as well as other 8051 code. Depending onthe 51 you choose (Amel, Infineon or Philips for example who do smart cards and therefor crypto stuff) you should find plently of helpful code on their website.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

Hi,

Check out this algorithm, it is very fast and efficient on any processor or microcontroller...

Its the second entry on the webpage.

RC4 is a well established stream algorithm, but needs 512 bytes of RAM, RC5 may be a better choice. All block algorithms can be used to generate a stream when used in feedback mode. AES is well suited for 8 bit micro's, considered very secure and the required RAM is less than RC4

Wim

LFSRs, maybe two combined, need close to nothing (RAM, ROM, time).

What are the disadvantages?

Oliver

You are right with the minimum resources and it surely will deter the mere curious.

However, LFSRs need to be combined very carefully to be cryptographically secure, mostly involving irregular stepping and majority and/or selection funtions.

If you have 1 LFSR you need only the 'length' number of bits of know plaintext to break the system.

To see what can go wrong with combining LFSRs, see the attacks on PKZIP and GSM A5 (there is even a German 'Diplomarbeit' about it, althoug very technical)

Regards, Wim

which can be sufficient in many cases.

Do you have any sources where I can learn about this?

One has to know the position of the known plain text?

So if I use it for a Flash bootloader and shuffle the blocks before encrypting, there probably is no known plain text at known position.

Any hint how to find the "Diplomarbeit" (Title, Author)? I will read through some stuff describing the mentioned attacks, but maybe the "Diplomarbeit" would be also useful.

And I have to buy (and read) Bruce Schneier's book after all to avoid asking more stupid questions in newsgroups .

Oliver

Are you planning on having a human enter the key every time? If not, then al forms of encryption are trivila to defeat. You simply can not store the key anywhere inside the embedded system if you want real security.

Google comes up with lots of sensible hits on "attack lfsr cryptography"

You can guess it, if you know more or less what the plaintext will look like. If you need less then about 2^36 attempts, you can brute force it on a fast PC. Guy Macon has a very sensible point: where to store the key securely, see also the Xbox attack.

and

th.informatik.uni-mannheim.de/ people/zenner/pub/thesis.ps.gz

It does not go very deep, but it is a fairly complete overview. The book written by "van Oorschot" is available on the web, but is more technical.

Wim

The objective is to hide the executable from the human receiving the encrypted file. So only the microcontroller receiving the data should know the "secret".

Maybe I'm missing something, but since the protection of the data itself is as weak as the storage of the key (stored in the same memory), it's good enough. Making a safer enrcyption doesn't make the storage of the decrypted data safer.

Oliver

I have been reading some of them some time ago but can't remember a statement like yours. I will try again after reading the other documents.

"less" in usual executables. There are known sequences, but sparse and at unknown places. So most times, one has to check large ortions of the encrypted data making a brute force attack slower.

Has the key to be stored more secure than the data to be protected? If somebody can access the key, he can access the whole protected program, can't he?

But I will read about the Xbox attack, maybe I'm missing something.

thanks! I found it cited many times but not the document itself.

Oliver

Yes. It's like shipping someone a case-hardened steel box with a high security lock and taping the key to the lid.

So forget about XBox attacks, lsfr attacks, etc. The whole scheme is hosed.

If someone does figure out how to solve the key problem, using AES or RC4 encryption will make it resistant to all known attacks. Note the "If".

Maybe I'm a bit slow, maybe there is a misunderstanding.

I'm talking about a microcontroller flash loader with encryption to allow SW updates in the field without disclosure of the code.

If somebody can break the microcontroller's security, it's no more important to keep the key secret because he can access the protected stuff directly (without using the key). That's what I wanted to write in my last posting.

So why shouldn't the key be stored in this internal, more or less "protected" memory?

Oliver

Executables have a lot of redundancy. (An Intel .exe can be zipped to 35% of the original) Most executables have pedictable parts, like the startup code and push/pop everything The key of a LFSR is the initial condition. So try all initial conditions and see when the output entropy drops below

Wim