This could be considered a framing challenge but this is more due to how network security works:
First, I will be answering the full question which seems to be "how can I protect this distributed network I've made?" over just answering "what is the best encryption method to date?". I will base this idea on my own research into IoT & network security. Research which includes an internal medical device (pacemaker) where the word "near" (as in near impossible to hack) was used before a research group hacked one and showed a person could have been killed. In this case, by turning it off instead of on and it took 7 years of research or so but it's definitely possible.
So the full answer is you cannot just rely on asynchronous encryption but need a full risk-based Defense in Depth security plan. To expand on that:
Do not just rely on encryption
Now @EDL gave a solid answer on one method of using asynchronous encryption with a strong encryption algorithm (if they have a quantum computing method for building it - all the better but not necessary). So lets say we have that - it still doesn't matter if someone can guess the password or get the password from an authorized user (kidnap, torture, employee turns on you, etc). So we would need to add layers to the security with authentication, authorization, and maintenance.
Authenticate the User
Now to avoid the simple password issue (but still require a password), we should also fully identify the user. As this is "near future" tech, I would include the need to authenticate the user using biometric technology. If you have a recent tablet you may already be using this by using your finger print to open your device but current advancements include using brain waves or heart patterns to authenticate someone. Again, not full proof if you kidnap/force someone (and esp. if its an inside job) but at least this helps avoid some level of threat.
Authorize the User
Now, lets say your "bad guys" kidnap somebody who worked on the project and force them to send the "kill" command. This should only work if the person is also authorized to activate the command. This is the same in modern computer systems, the reason most operating systems ask you to login as an administrator or root when making changes to all users or the system's settings (like installing new software at a system level).
This builds a layer (defense in depth) with the last detail as now you must not only kidnap anybody but you have to kidnap the right person. That allows you to focus your resources on only protecting (or watching in the case of an insider) a few people over the whole project team.
Now lets say the "bad guys" did kidnap that person and then found that they didn't have authority for the full "kill" command but has access to lesser commands or they find a bug at a lower level authorization as happened recently here. By poking around this level, they might eventually find a way to access the full "kill" command (a backdoor or just another bug). To avoid this, one needs to be able to provide updates after releasing these - in software life cycles this has various names but the "Maintenance" or "post-deployment" phase are common ones.
For instance, in the first article about the pacemaker - the manufacturer's recommendation was to get a firmware update which (hopefully) fixed this bug so other people shouldn't be able to use it. In your case, I would have a few, the more looking the more you have to secure with the above methods, on-staff researchers who continue to do penetration tests and other debugging and fix these errors as their found (ramping this up if someone on the project is reported missing) and forcing the nanites to update on each patch. This is esp. useful with self-replication as there are mutations in the code which could happen if their is a fault during a copy (small chance but possible).
The best way to encrypt this is to use a strong encryption algorithm that is coupled with defense in depth protections like authentication, authorization, and post-deployment development. These are only a few but I think give a solid foundation in answer to your question.