# Encryption Algorithm

#### Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

•  Subject
• Author
• Posted on
Hello

Can anyone guide me on the implementation of encryption algorithm
using microcontroller?

Re: 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

Re: Encryption Algorithm

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       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Encryption Algorithm

[...]

Nice collection, thanks for sharing it!

Please change Schneider -> Schneier.

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)

Re: Encryption Algorithm

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

Re: Encryption Algorithm

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

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

Re: Encryption Algorithm
snipped-for-privacy@hotmail.com (Tina) wrote in message

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

Re: Encryption Algorithm

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       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Encryption Algorithm

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

Re: Encryption Algorithm

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

What are the disadvantages?

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)

Re: Encryption Algorithm

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

Re: Encryption Algorithm

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 <g>.

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)

Re: Encryption Algorithm

Oliver Betz wrote:

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.

--
Guy Macon <http://www.guymacon.com/

Re: Encryption Algorithm

[LFSR based cipher for Flash bootloader, shuffle blocks before]

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
--
Oliver Betz, Muenchen (oliverbetz.de)

Re: Encryption Algorithm

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

Re: Encryption Algorithm

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.

[Zenner's "Diplomarbeit"]

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

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)

Re: Encryption Algorithm

Oliver Betz wrote:

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".

Re: Encryption Algorithm

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
--
Oliver Betz, Muenchen (oliverbetz.de)

Re: Encryption Algorithm

Oliver Betz wrote:

Why encrypt then?  Why not just store whatever you were planning
to encrypt in this internal, more or less "protected" memory?
The result is the same.

--
Guy Macon <http://www.guymacon.com/

Re: Encryption Algorithm

[...]

as I wrote: field updates. Done by "untrusted" people.

The result is certainly the same, but the method is not feasible since
I can't access the controller "in the field".

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)