[En-Nut-Discussion] local tcp port randomisation

[Bernd Walter]

On Tue, Jul 03, 2012 at 10:10:44PM -0400, Nathan Moore wrote:
> On Jul 3, 2012 5:33 PM, "Ulrich Prinz" <ulrich.prinz at googlemail.com> wrote:
> >
> > Hi!
> >
> > port += (uint16_t)NutGetMillis();
> > port |= 0xC000;
> >
> > That saves some instructions and should be sufficient:
> > 1) port must not be initialized as it's value should be random
> 
> I think that the distinction between random and undefined needs to be
> made.  My guess is that most systems would produce very predictable values
> for this.

Undefined is that you don't know the value, but in fact undefined can
also always be a static value.
Random is defined as unpredictable and statisticaly even spread.
undefined completely fails on both point.
A coin for example might fail on the later point because of unbalanced
weight and this also adds some predictability to the results.
The time way of doing should be even spread, but is pretty easy to predict.
The reason to use random ports is that others can't predict ports and
therefor the complete time based story is completely useless.
You need two points:
 - a pseudo random generator
 - a source of noise to seed the generator, better multiple of it

The noise source adds randomness, but is not evenly spread and is
not available quickly.
For example you can't get endless randomness from a temperature diode
as sampling takes time and always results in more or less the same
temperature with some noise in the last bit(s).
Thermic noise as mentioned by Ulrich are a good source, but very slow
so you might want more noise and additionally seed with random points
as ethernet interrupt time, ...
Unfortunately some of the used MCUs (e.g. the MEGA128) have no temperature
diode, so such hardware will have to live with less random results.
The pseudo random generator results in hard predictable values spread
over the whole range with quick results.
Usually it uses a cryptografical mechanism (e.g. RC4) to get a following
value, which also makes it hard to predict as it internaly uses more bits
as it returns, so you don't know the whole base value and the next value
is spread over the whole possible range.
But if the pseudo random generator isn't regulary seeded with true random
values you end in result chains which allow guessing the internal bits.

> >
> > 2) adding a value from 0..15 or adding the whole timer doesn't make a
> > difference. In both cases it is possible to hit the same port if one
> > figures out the right time frame.
> >
> > 3) port is ored with 0xC000 resulting in a valid value according IANA
> > regardless how uninitialized it was before.
> >
> > Remark for 1) Some architectures initialize all RAM segments with 0x00
> > so there is no imminent random start value.
> >
> > If real random ports are needed, use the internal temperature diode,
> > read its ADC and add the value to ports, or sample a reverse PN junction
> > of a transistor on your ADC input.
> >
> > In any case you need to track, which ports are used to avoid opening an
> > already in-use port a second time.
> >
> > Best regards
> > Ulrich
> >
> > Am 03.07.2012 16:30, schrieb Harald Kipp:
> > > Hi Nathan,
> > >
> > > On 03.07.2012 16:13, Nathan Moore wrote:
> > >> Is there any reason not to just use the negative port numbers (if you
> > >> interpret them as signed int so top bit = 1) as the ephemeral ports?
> > >> The range testing is greatly simplified.
> > >
> > > Let me resend my code fragment:
> > >
> > >   ticks = (uint16_t) NutGetMillis();
> > >   if (first)
> > >    port = ticks;
> > >   else
> > >    port += ticks & 0x000F;
> > >   port |= 0xC000;
> > >
> > > Where do you think that signed interpretation combined with a increased
> range of 32768 to 65535 could simplify the code above. Note, that the IANA
> range of 49152 to 65535 includes all shorts with two MSBs set.
> > >
> > > Regards,
> > >
> > > Harald
> > >
> > > _______________________________________________
> > > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> > >
> >
> > _______________________________________________
> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.