Re: DES implementation problems
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 09/24/04
- Previous message: BRG: "Re: DES implementation problems"
- In reply to: BRG: "Re: DES implementation problems"
- Next in thread: BRG: "Re: DES implementation problems"
- Reply: BRG: "Re: DES implementation problems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 24 Sep 2004 10:17:06 +0200
BRG wrote:
> Mok-Kong Shen wrote:
>
> [snip]
>
>>> Good tip!
>>> But it still remain only 4 bytes available to other variables, such as
>>> round counter, temp vars of multiplication for GF(2^8) and matrix. For
>>> common 8-bit cpu such as 8051, R0~R7 must be carefully allocated to
>>> these variables. It's indeed a hard job. Rijndael paper said that it
>>> is implemented in 68hc08 assembler:
>>>
>>> Key/Block Length Number of Cycles Required RAM Code length
>>>
>>> (128,128) a) 8390 cycles 36 bytes 919 bytes
>>>
>>> (192,128) 10780 cycles 44 bytes 1170 bytes
>>>
>>> (256,128) 12490 cycles 52 bytes 1135 bytes
>>>
>>> I think these data are only for encryption.
>>> Data of 8051 were also presented, but did not include RAM size.
>>
>>
>> Again a point of ignorance: Given these figures, it would
>> sound almost like magic that one could do the same with
>> as little as 32 bytes of RAM. BTW, doesn't one have to put
>> in at the start one block of the plaintext and one block of
>> the key. These alone occupies that amount of storage.
>> It's difficult to imagine that during the whole processing
>> one wouldn't need any additional space for storing some
>> temporary variables. But, of course, a hard and undisputable
>> proof would be a 'concrete' implementation with only 32 bytes
>> of RAM on some machine. Otherwise, one would be left with
>> wild speculations, I am afraid.
>
>
> Wild speculation is not necessary since those of us who are in this
> business have a lot of real experience on which to make such judgements.
>
> The reason that it is not possible to give a definitive general answer
> is that it depends on the actual processor involved. Some processors
> have all their 'registers' in memory and in this case, as Xiangyu Yang
> has said, it would be impossible to implement AES in a processor system
> with only 32 bytes of RAM. But other processors do have non-memory
> registers and if there are several of these it may be possible to
> implement AES in 32 bytes of RAM.
I see. But these registers have contents that are changing,
they are in fact more efficient than what is called RAM, aren't
they? So one would be in fact cheating with a 'superficial'
very impressive figure of 32 bytes of RAM of implementation,
wouldn't it? (Imagine a machine with 1K bytes of 'registers'
and one would require 0 bytes of RAM :-) )
M. K. Shen
- Previous message: BRG: "Re: DES implementation problems"
- In reply to: BRG: "Re: DES implementation problems"
- Next in thread: BRG: "Re: DES implementation problems"
- Reply: BRG: "Re: DES implementation problems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|