[En-Nut-Discussion] local tcp port randomisation

[Harald Kipp]

Hi Ulrich,

On 05.07.2012 12:28, Ulrich Prinz wrote:
> Hey guys,
> 
> Did anyone read my _full_ answer?
> I already said that it is likely not random...

I read all your full answers at least twice and understood your point.


> 2012/7/4 Harald Kipp <harald.kipp at egnite.de>:
>> Hi Bernd,
>>
>>  ticks = (uint16_t) NutGetMillis();
> 
> This isn't random either as it is always the same value measured from
> power-on to time X, exactly as my value that is init to 0x0000 by most
> platforms formatting data and bss to 0x00.

I never criticized randomness.

http://lists.egnite.de/pipermail/en-nut-discussion/2012-July/013674.html


> This:
>>  ticks = (uint16_t) NutGetMillis();
>>  if (first)
>>   port = ticks;
>>  else
>>   port += (uint16_t) ((ticks & 0x000F) | 1);
>>  port |= 0xC000;
>>
> 
> end this:
>> ticks = (uint16_t) NutGetMillis();
>> port += ( ticks & 0x000F) | 1;
>> port |= 0xC000;
> 
> has exactly the same security level while my version produces less code.

Please do only quote lines, that have been posted previously. I spent several minutes to figure out, that the latter 3-line code never had been posted anywhere.

The difference between the 2 versions is, that the start value is more predictable on the latter. And exactly that was the initial problem that Ole reported.

What you suggested in the post I answered to was:

>> port += (uint16_t)NutGetMillis();
>> port |= 0xC000;

The problem with this is the possibly low re-use frequency.

I know that you suggested to keep the variable uninitialized. But this is not standard C. It's highly compiler/linker dependent. Anyway, it inspired me to change my suggested code again:

 ticks = (uint16_t) NutGetMillis();
 if (port)
   port += (uint16_t) ((ticks & 0x000F) | 1);
 else
   port = ticks;
 port |= 0xC000;


> Again, if you need something random, read the CPU internal temperature
> ADC value or read a reverse PN junction of a transistor via ADC. But
> even that could be breached as one could apply a stable voltage to the
> ADC pin overriding the noise produced by the PN.

What I want is a fast and easy (one may call it dirty) alternative to

http://lists.egnite.de/pipermail/en-nut-discussion/2005-November/005290.html

And I clearly stated that I do not want to wait until we have a reliable random number on all platforms.

Regards,

Harald