Prev: Keil C51/ 8051 port of uIP v0.9 TCP/IP stack.
Next: TCP/IP stack for GPRS
From: Oliver Betz on 17 Feb 2005 02:54
"Wim Ton" <wimton(a)blueyonder.co.uk> wrote:

>> LFSRs, maybe two combined, need close to nothing (RAM, ROM, time).
>>
>> What are the disadvantages?

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

which can be sufficient in many cases.

[...]

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

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.

>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)

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)
From: Guy Macon on 17 Feb 2005 05:28



Oliver Betz wrote:

>So if I use it for a Flash bootloader and shuffle the blocks before
>encrypting,

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/>

From: Wim Ton on 17 Feb 2005 12:05
>
> >If you have 1 LFSR you need only the 'length' number of bits of know
> >plaintext to break the system.
>
> Do you have any sources where I can learn about this?
>
Google comes up with lots of sensible hits on "attack lfsr cryptography"

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

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

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

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

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



From: Oliver Betz on 17 Feb 2005 15:39
"Wim Ton" <wimton(a)blueyonder.co.uk> wrote:

>> >If you have 1 LFSR you need only the 'length' number of bits of know
>> >plaintext to break the system.
>>
>> Do you have any sources where I can learn about this?
>>
>Google comes up with lots of sensible hits on "attack lfsr cryptography"

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.

>> 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.
>
>You can guess it, if you know more or less what the plaintext will look
>like.

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

>Guy Macon has a very sensible point: where to store the key securely, see
>also the Xbox attack.

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

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

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

Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
From: Oliver Betz on 17 Feb 2005 15:37
Guy Macon <http://www.guymacon.com/> wrote:

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

>Are you planning on having a human enter the key every time? If not,

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

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

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)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Keil C51/ 8051 port of uIP v0.9 TCP/IP stack.
Next: TCP/IP stack for GPRS