-8
$\begingroup$

Dragons are awesome, but they're still vulnerable thanks to their low-numbers and a certain type of people...

So, to prevent those from killing even a single dragon I came up with the wedding rings of death. They kill by releasing a poison straight into the vitals (usually the brainstem), they're wrapped around. Tampering will also trigger the ring.

The important thing is that they can be activated remotely via a radio signal. They're also already and will always be present in every living creature (except dragons), as the rings double as Von Neumann machines (they can replicate themselves).

The problem is that means any haxxor could attempt to make these things go off. And there's a LOT of these rings, and so a broadcast brute-force attack has a higher chance of activating one of them.

I need a way to encrypt the activation signal for every occasion in a way that it's near impossible to crack or brute-force it. Assume you have unlimited computing capacity, but less resource-intensive solutions that work just as well are more preferable.

Quantum computers are rare and exclusive to the creators of the rings, however, neural networks have made a step up from composing 10-hour rap music and can be a significant threat.

$\endgroup$
  • $\begingroup$ Note: OP can't fix what he doesn't know about. If you don't understand something in the question Request clarification here. If you think this is overflowing with memes at the expense of clarity, complain here. For everything else, there's Master card. $\endgroup$ – Mephistopheles May 30 '19 at 20:15
  • 4
    $\begingroup$ Since the question does not explain the structure and the operation of the ring, it's quite obvious that nobody can say how to harden it. "A wedding ring of death" is not explanation of structure. "It cannot signal" is not an explanation of operation. BTW, just for curiosity, what's the difference between a "wedding ring of death" containing potassium cyanide and a plain "ring" containing same? And how come the wedding ring of death be removed by a simple divorce of life? $\endgroup$ – AlexP May 30 '19 at 20:21
  • 4
    $\begingroup$ I feel like if you're able to make self-replicating, omni-environment-persisting, immune-system-evading nanomechanisms, making killswitches is about the most pointless and boring thing you are capable of doing. $\endgroup$ – Starfish Prime May 30 '19 at 21:17
  • 2
    $\begingroup$ From JoJo the anime/manga? I don't watch or read that one but if your are borrowing a move or idea you should reference it in the question (citing it is the minimum requirement and I have no idea about the possible fan fiction copy-write issues with using the literal name and move from a show). Also, modern technology level relating to surgical options on a brain stem: answer might be "not possible". $\endgroup$ – LinkBerest May 31 '19 at 0:52
  • 6
    $\begingroup$ If you think this is overflowing with memes at the expense of clarity --- perhaps the OP should simply write clear queries in the first place. This practice would avoid your question ending up in the close queue yet again. Not to mention you're trying to use a triple coupon in a no coupon shop. :/ $\endgroup$ – elemtilas May 31 '19 at 2:57
1
$\begingroup$

Assuming that there is someone that has proper authority to trigger someones rings of death then this is the most rigorous protection I can imagine there could be

  1. The very first Ring of Death (ROD) was created with its own private and public key that only it knows and it has the authority’s public key. It also created a one time pad. ROD prime encrypts its public key with the authority public key and transmits it to the authority. It then encrypts its one time pad with its private key and encrypts that with authority’s public key

  2. When a new ROD is generated, by another ROD, it generates a public and private key, a one time pad, and inherits the authority’s public key from its parent. The new ROD shares its public key and one time pad with the authority the same way ROD prime did.

As way of explanation of asymmetric encryption: Things encrypted with a private key can only be decrypted with a public key and vice versa.

one time pads contain single use ciphers used for one and only one message then destroyed. they can only be broken by brute force

If the authority needs to issue the Die! command to a ROD, it encrypts the kill command using the first cipher of the target’s one time pad, then encrypts it with targets public key, then again with its private key. The target’s ROD reverses the pattern and if the kill command is valid, BOOM!

| improve this answer | |
$\endgroup$
1
$\begingroup$

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.

Maintenance

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).

TDLR;

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.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.