Add CLI command to regenerate key pair

[mattzzw]

In a situation where repeaters face zero hop key prefix collisions, keys will have to be regenerated.
Doing this via the set prv.key command is only possible via physical connection to the repeater - for good reasons.

Now, in order to be able to solve a prefix collision without having to climb on roof tops with your notebook in your backpack this PR will add the regeneratekeys command to enable remote regenerating of the key pair.
By applying the command the repeater will reboot immediately and by doing so will also send an advert so that the device will show up a couple of seconds later in the contacts list with a new public key.

This fixes #241

[marcelverdult]

yes please!

[recrof]

set prv.key might be more useful here, as you need to run this multiple times if the mesh is too crowded with occupied IDs.

[mattzzw]

set prv.key is currently only available via serial, so it needs physical access to the device. I think it would make a lot of sense to make set prv.key available on the cli console. (get prv.key is a complete different story, of course.)
However, using set prv.key requires knowledge and access to external key generators like https://gessaman.com/mc-keygen or ssh-keygen adding more steps involved.

Therefore I would propose two ways of solving the collision problem:

1. Make set prv.keyavailable via cli console (for the use case of very crowded routers with the need to use pre-defined and pre-generated keys)
2. Add the regeneratekeys command as a simple and user friendly "one-click solution"

[recrof]

Add the regeneratekeys command as a simple and user friendly "one-click solution"

I don't think it's friendly at all - it just randomly changes the id. if ID utilization is at 80%, you will need to do it 10x and pollute contact lists of whole mesh with bogus entries.

[IoTThinks]

set prv.key is currently only available via serial

Yah, most of the time, the repeaters are glued with silicon to protect them from rain.
Serial connection should be avoided at most of the time.

[mattzzw]

Another option would be to let the user provide a desired first byte of the public key as a parameter and let the regenerateKeys routine run for ~256 times until we have a match. Basically doing what https://gessaman.com/mc-keygen/ does for the first byte only. Part of that is already implemented in order to prevent 0x00 and 0xff as a first byte.
Don't know about the runtime though. Any thoughts on that?

[mattzzw]

Now the user has to define the first byte of the public key to be generated.
e.g.

> regeneratekeys 2f

On a Heltec v3 it never took longer than 3 minutes to generate a key pair with matching public key, most of the time it took less or about a minute.
(I tested this using an unused LoRa configuration in my area...)

[recrof]

thanks @mattzzw. can you try how long it takes on nrf52 device? those are deployed as solar nodes most of the time - if it takes 3 minutes on esp32s3 device, I fear it might take ~10 minutes on nrf52.

[mattzzw]

Yepp, will check on a faketec w/ nrf52.

[mattzzw]

It's more anecdotal evidence, but I did 10 runs and the runtimes where acceptable. I would expect the esp32s3 to be 3-5 times faster than the nrf53 in general. ED25519 operations cannot make use of the crypto hardware available in both chips, however the implementation of the software libs can have a huge impact, as usual.
Here's the times for the NRF52:
4:40 <
2:05
1:57
0:57
0:18
1:15
0:05
0:06
4:23<
0:48

[IoTThinks]

Even with 10 repeaters, I happen to see 2 of them have the same first byte.
How deep is the impact for routing if two repeaters have the same first byte?
The routing may be wrong to reach the destination wholly?

I guess the first byte is only required to be different with nearby neighbors only.
So instead of setting the wanted byte, we can list those bytes we do not want.
Will be faster.

[khudson]

It just means both repeaters will repeat the packet if heard by the same previous hop. The worst thing that happens is there is an unnecessary repeat in terms of airtime utilization. Definitively tracking a packet's path by the client app, on the other hand, is something that will be affected as there's no way for the client to discern which repeater with overlapping prefix actually did repeat a packet.