> ... linux kernel account said ...
> >A host and a userspace rebooter on another box share a 20 byte (160bit)
> >secret.
>
> right. This is sensible.
>
> >When a client wants to reboot a host it takes the unix time and drops the
> >least signifiant 8bits and makes that byte=FF. Then it takes the first
> >8chars of the hostname (padding with nulls if shorted). Then it adds on
> >the 160bit secret. It then performs the SHA transform on the 32byte input
> >and produces a 160bit magic value)
>
[snip]
> ... you could also easily limit the set of hosts which can legally send the
> Reboot packets. A cracker could impersonate the machine, but they'd have to
> know which machine it was, and then would have to be in the route to that
> machine...
I see the only need for the 'challange system' is so that you can
idenitify the sender. My main difficulity with the challange system, is
that the reboot packet is to reboot a runaway computer. The challange
system would mostlikely lower it's effectiveness.
Furthermore, there is no need to use a random number to prevent replay.
The window is small enough (4minutes, someone with the ablity to sniff
could do more damage then making it go down again as soon as it came up)..
I was recommending using 24bits of the unix time in the hash input. That
should be sufficent.
MOST importantly, you sugesstion requires the 'rebooted' computer to
generate a random value and several SHA hashes per request packet
recieved.. That is a rather nice DOS attack. My perposal would have
virtually the same security but would only require 1 sha computation every
4.2 minutes and can be done on the first reboot packet recieved. Further
packets need just a compair.. No DOS there.. (at least no DOS worse then a
ping bomb)!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I dont think it's nessassary, however, it would need to be there for
people to use the feature. Relying on a 'secret' doesn't give people warm
fuzzies..
>
> >Providing no weakness in SHA the easiest cracking would involve sending
> >2^160 ping packets. Assuming that the protocall used ping packets of a
> >minimum size (20byte tcp 8 bytes icmp and 20 bytes payload) it would
> >require sending 70152078591883340073776871970381584943484762062848 bytes
> >of data for a brute force attempt. This is also assuming the compute
> >clocks were exactly synced and that it took no time to produce the hashes
> >and check them and such.
>
> Problems with this:
> - the cracker doesn't compute hashes... he just sends a 160 bit
> counter.
The target does, that slows things down. The number of bytes sent
would not be changed. My estimations of time are only dependant
on network speed.. I was estimating the average crack time of
well over a billion years on 100bit ethernet. I doubt the attack
would become feasible with 10-20 generations of human life.
> - You must allow a window for the lack of synchronization between
> the rebooter and the host to be rebooted. So you'll probably allow
> a single packet to have a validity of about 8 minutes.
Actually I allow for 256seconds of validity requiring +/- 2.16
accuracy with the clocks. I was recommending droping the last 8
bits of the 32bit unix time.. It fits well..
> - A single valid packet can be replayed until it is no longer valid.
> so your poor host will be rebooting until the packet expires... So
> if you validly reboot the machine, anyone listening can reboot the
> machine for a few minutes...
You couldn't reboot it until it was on the network.. How many
times could I reboot your computer in that 256second window? Maby one
additional time...
I think you are sugesting a little overkill.
The DOS potential of your solution greatly outweighs the minor potential
benifit of your sugesstion..