Encryption Algorithm - Page 2

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

Translate This Thread From English to

Threaded View
Re: Encryption Algorithm



Oliver Betz wrote:
Quoted text here. Click to load it

Got it.  That will work.  Is your hardware such that the untrusted
people doing the field updates can overwrite the key inside the
contoller?  I think not if you write the updating code - which you
would have to do anyway to add encryption.

Take a look at my post about AES, RC4 and ciphersaber.  Let me know
if any of it doesn't make sense.

BTW, roughly how much RAM, ROM, and cycles can you afford to use
up during the update? (the RAM can be used for other things
afterwards, of course, and flash will work as RAM for the algos
I am talking about - with the usual speed penalty).

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


Re: Encryption Algorithm

[field updates done by "untrusted" people]

Quoted text here. Click to load it

Exactly. Maybe I keep the option to update also the loader part, but
usually it will be protected.

Quoted text here. Click to load it

I will have a look at them, and also TEA suggested by Marc Ramsey.

[copied from other posting]

Quoted text here. Click to load it

That was the intention <g>.

Quoted text here. Click to load it

The main goal till now was to make a very efficient loader for the
Motorola/Freescale HCS12. That means small footprint, little
restrictions for the application, no specific host requirements
(simple terminal program), fast transfer, 7bit data (e-mail).

Therefore I send BASE64 encoded lines at 115200bits/s without
handshake (the serial port is polled during the Flash programming
periods). At 24MHz bus clock, one byte is transferred in approx. 2000
cycles. I have to look how much is available for key generation.

In the current implementation, I have little RAM and code space
because the whole loader is copied to 2k RAM. This way I can simply
reprogram the _whole_ memory (including the loader itself). Space for
two 32 bit LFSRs, IIRC.

For a stronger encryption, I likely had to change this. Since small
HCS12 derivatives have only one Flash block, there is always the Flash
programming time where no Flash is readable. Therefore the receive
routine and buffer always must reside in RAM. The decryption could
stay in Flash, but then can use only the transmission time minus Flash
programming time.

So if I want stronger encryption, I probably had to slow down the
process. Either by using a slower transfer rate, or by decrypting
after transfer.


It's important to find the right trade-off between security and cost.

As long as the product is not widely known and/or subject to "just for
fun" attacks, the decryption (plus reverse engineering of the code)
doesn't need to be more expensive than re-writing the application
itself or breaking the protection of the microcontroller (no clue how
secure the HCS12 is).

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

Re: Encryption Algorithm



R Adsett wrote:
Quoted text here. Click to load it

With the key already in the micro?  That would work against someone
reading the downloadable/installable file.  Not a bad idea.

There are two algorithms that are suitable for this, AES and RC4.
AES requires less RAM, RC4 requires less ROM and is a lot easier
for an embedded systems programmer to understand.  Do a web search
on [ AES cipher ], [ RC4 Rivest ] and [ ciphersaber ].

I also suggest posting the code in sci.crypt before using it - but
make sure it is correct before swimming with the sharks!

(If anyone thinks that the encryption.decryption code should be
kept secret, please search on [ security obscurity cryptography ].)

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


Re: Encryption Algorithm
Quoted text here. Click to load it

Look into TEA (Tiny Encryption Algorithm), I've found that it suits
small embedded systems rather nicely:

http://www.simonshepherd.supanet.com/tea.htm

Marc

Re: Encryption Algorithm
Quoted text here. Click to load it
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
0.5, you do not even have to know the plaintext.

Wim



Re: Encryption Algorithm

[known plaintext attack for executables]

Quoted text here. Click to load it

Maybe message strings are worst if not runtime descrambled (which
would cause annoying coding). Startup code must not be known (for
example, I don't use the startup code provided by the compiler
manufacturer). push/pop sequences are short. After all, the positions
of all these code portions are unknown, therefore a noticeable part of
the code has to be tested - likely much more than twice the length of
the LFSR possible with known plaintext at known position.

Quoted text here. Click to load it

And the polynomial.

Quoted text here. Click to load it

A brute force attack is always possible but can be made enough
expensive, I guess.

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

Re: Encryption Algorithm



Oliver Betz wrote:

Quoted text here. Click to load it

Make the key 128 bits that you downloaded from hotbits and it
will always be too expensive - the universe is too small and
too young to do the computation in.  Make it 256 bits and
it will be too hard to ever do squared.  That's only 32 bytes
of ROM to hold your key. but its 2^256 (roughly 10^77) guesses
to do a brute force attack.

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


Re: Encryption Algorithm
Quoted text here. Click to load it
of
push/pop
Quoted text here. Click to load it

You can also encrypt only the interesting parts of the program (the code
segment I suppose) as the strings will be known anyway by someone who
observes the working of the products. Saves time as well.

Quoted text here. Click to load it

There is not much scope to vary the polynomal, as only a few polynomals
produce maximum length cycles.

Wim



Re: Encryption Algorithm

[where to find known plaintext]

Quoted text here. Click to load it

good idea!

Quoted text here. Click to load it

I don't remember numbers for larger polynomials, but there were 2048
or 4096 16 bit max. length polynomials.

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

Re: Encryption Algorithm

Quoted text here. Click to load it
Hi,

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

http://members.cox.net/berniekm/tricks.html

Its the second entry on the webpage.

--
Luhan Monat (luhanis 'at' yahoo 'dot' com)
"The future is not what it used to be..."
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline