Feature: passwords instead of keyfiles

[tpwrules]

Would you accept a PR to implement using passwords as a command line option instead of having to generate and share keyfiles? It should be straightforward to do using the libsodium API and would allow smoother setup.

[svpcom]

Why not use https://github.com/svpcom/wfb-ng/wiki/Drone-auto-provisioning ?
Enter any password anyway will require some network connection.

[tpwrules]

Sorry, I guess I should have been clearer, I meant as options to wfb_tx and wfb_rx. I am using them in a project instead of the whole wfb-ng system, so I would not be interested in using the auto provisioning right now.

It looks like passwords will also let you have in effect multiple binds at once. Passwords wouldn't be mandatory by any means but would just be a convenience and could migrate to other tools later.

[svpcom]

How to derive pubkey/privkey keypair from the password?

[tpwrules]

That's possible using libsodium's crypto_box_seed_keypair and a KDF like crypto_pwhash. Would you accept a PR to use that?

[svpcom]

yes.

[svpcom]

Also if crypto_box_seed_keypair can generate keypair deterministically from the password, then the easiest solution will to write two screen of code utility (like wfb_keygen.c) that will just generate keypair from the password and no other patches for wfb_rx/tx are needed

[svpcom]

Also original password will not be revealed to public because only generated keys will be stored in system

[tpwrules]

I will do some investigation but for my purposes it would be useful to not have another utility.

[svpcom]

Just add additional command-line option and crypto_box_see_keypair here:

wfb-ng/src/keygen.c

Line 58 in 1d14a1a

if (crypto_box_keypair(drone_publickey, drone_secretkey) !=0 ||

[tpwrules]

I think the implementation you have just added is not correct. You should generate 2*crypto_box_SEEDBYTES bytes with Argon2 and then pass one half of the buffer to each crypto_box_seed_keypair call. Currently both sides will get the same keys.

I still also would like to refactor the stuff out of the generator utility and have it as an option direct to wfb_tx and wfb_rx. We might have to turn down the amount of RAM used, I was thinking like 1MiB. The brute-forceability does not need to be super duper resistant.

[svpcom]

Libsodium crypto_box implementation allows to use such identical keypairs for both sides. I've already tested them. But I'll implement your sugesstion to have clean encryption logic.

Argon2 key derivation eats alot of memory and cpu (because it provides bruteforce protection) and recalculate it during every wfb_tx/rx start will be very slow and can lead to out of memory condition (especially on cheap devices like openipc cameras and openwrt routers). Also having password as cmdline argument vs key in the file is less secure, because every user ( or process in system) can run ps and read it