3

I apologize for the theoretical nature of this question, but It has cost me a lot of sleep over the past months. Querying my immediate peers has so far failed to produce results. I assume this question belongs to the domains of Cryptography & Game-Theory, hence I hope to be in the right forum.

Question

Is it possible to design a process or method that allows an operator to run a program that generates a public and private key-pair, executes a set of operations using the private key as input and produces a result. It then exports the result and public-key after which the context self-destructs, permanently deleting the private key in such a way that eliminates all suspicion that the secret could somehow have been retained or duplicated by the operator.

Pseudo code of the imagined program:

main () {
  public, secret = generateAsymmetricKeyPair()

result = someOperations(secret)


publish(public, result)


destroy(secret)
}

The source of the program is assumed to be transparently available to the general public. Upon program completion regardless if the secret was truly lost or not, the public and the result should be possible to publish while the method itself should serve as proof that the operator has no upper hand in any potential recovery of the secret in comparison to a third party.

What I have so far

I've looked into TEEs as a potential secure context for the imaginary graybox but unless I misunderstand it does not divert suspicion from the operator any more than running the program on a cloud VM without ssh-keys. Both approaches also fail to present proof of deletion without a hands on inspection (requiring a trusted arbitrator). And in turn might generate an unintentional incentive to possess the hardware that executed the operation.

Smart-contracts all operate in a completely transparent manner which leaves little room for random secrets.

My most creative idea to date is to train a chimpanzee to operate a raspberry and equip it with a pack of remotely detonated explosives, start a live broadcast and once the public and result is successfully transmitted; obliterate both hardware and operator. One obvious flaw with this approach is that the broadcast does not necessary display the destruction of the secret, rather it shows that a piece of hardware and an assumed operator was violently removed from the equation.

I feel sorry for the monkey, please help me understand if an "trust-less blind execution environment" can be designed; if not, then why?

Update: Practical example

The following article was brought to my attention: https://decrypt.co/41402/the-690-million-bitcoin-wallet-that-hackers-are-trying-to-crack

The game described by the article is one potential practical application for the imagined graybox. If we pretend that the wallet address is the public-key and the mentioned wallet.dat in the article could be seen as the result. The secret key is believed to be contained by the result.

Had the puzzle been generated by the proposed program, it could've been expressed as:

main () {
  public, secret = generateAsymmetricKeyPair()
  result = scrypt(secret, randomBytes(8))
  publish(public, result)
  destroy(secret)
}

Now we have a game with two sides, one bets that the secret can be recovered and stakes computational resources to brute-force the result. The other party bets against the recovery and does so by signing over value to the public-key. Disregarding speculation whether or not the secret is contained by the result, the game in the article has two additional problems:

  1. Inspecting the public wallet address in a block explorer shows that the operator deposited the initial value in 2013, and in 2015 there was a single withdrawal which tells us that the operator had access to the secret at least up until that point. There is suspicion that the operator has retained the secret.

  2. Further inspection of public transactions shows that the secret is not required to add more value to the wallet and latest addition was made on 20th of September. As an operator, If I would attempt to generate a similar lottery with a small initial value, a third party could increase the stake in my game beyond the point where I can protect my person against potential suspicion of having retained the secret. Let me rephrase that; It allows third parties to "put a bounty on the operators head". I don't possess the resources nor the stomach for such games.

So my question is: Is it theoretically possible to design a method that produces a valid "void-pair" or in this example a "void-wallet" that is provably owner-less?

telamon
  • 131
  • 2
  • It is written generateSymmetricKeyPair where I guess there should be generateAsymmetricKeyPair. See this for what a Symmetric Key Pair is. Independently: an improvement of the pseudocode invokes destroy before publish. – fgrieu Sep 23 '20 at 18:51
  • @fgrieu oops, thank you for noticing. My intention was "asymmetric" keypairs. Yeah I agree about destroy before publish, though I did not want to focus on that order in case the method of destruction also destroys the context :) – telamon Sep 23 '20 at 19:43
  • 1
    Well, with your example, the output is indistinguishable from someone selecting a random valid public key, and a random string as the 'secret'; and then running scrypt on your random secret. Obviously, there is no chance that the private key corresponding to the public key is exposed (as you never compute it yourself). I suspect this doesn't solve what you're asking - what is the requirement? What is 'process'? – poncho Sep 23 '20 at 21:24
  • @poncho that thought has crossed my mind and i think it's a great suggestion. but the requirement in the game example should be that there actually is a secret that is temporary "lost" and should be possible to recover without giving the operator an unfair advantage. process renamed to someOperations, the idea is that it is a function that generates a cryptographic puzzle. – telamon Sep 23 '20 at 21:46
  • Maybe you could use a homomorphic encryption algorithm to generate a private key - start with ciphertext guaranteed to correspond to some valid plaintext without ever knowing what that plaintext is? Then perform operations to reduce the entropy of the plaintext until it's suitable for a cryptographic challenge. You basically end up artificially weakening the algorithm for the purpose of creating a fun game. – Serpent27 Sep 24 '20 at 20:41
  • If you want the key to be derived from a password or some other human-generated input, though, you can't without knowing the key. You can forget what the key was (securely remove it from memory; and don't peek), but you cannot generate the key intelligently without at some point knowing the key. – Serpent27 Sep 24 '20 at 20:43
  • @Serpent27 I'm only weakly aware of homomorphic encryption, but it's something that would let me generate 2 numbers, encrypt them and send them to a third party to let them operate on my numbers without disclosing their value? But unless i misunderstood the problem still remains that I at some point had access to the secret. I think it might similar to historical problem of rulers having murdered their architects and builders once they finished building the secret-pathways through out the castle. Maybe homomorphic encryption can be used to involve multiple architects in the generation process? – telamon Sep 27 '20 at 16:09
  • 1
    Public key homomorphic encryption could be used as follows: Generate a valid public key (without generating a private key), as mentioned before. Then you perform arithmetic operations on a randomly generated ciphertext to lower the number of possible states of the plaintext. The plaintext will then be some secret that you've never had access to. You never create a private key, and you never manipulate plaintext. The challenge would be obtaining the plaintext. – Serpent27 Sep 27 '20 at 17:16
  • 1
    For example, create 256 bits of ciphertext. Then divide it by 2, 192 times with the FHE scheme. You then get ciphertext corresponding to a 64-bit plaintext block. I have no idea how you'd actually implement this, or how it would be useful but to be honest I don't understand the usefulness of this entire question. You're not gonna be able to generate a BTC address using this scheme, since you can't read the data without cracking it yourself. The only reward for winning would be bragging rights; or whatever someone pays you after you win. – Serpent27 Sep 27 '20 at 17:22
  • @Serpent27 I am in general very interested in creative applications of weak crypto (I'm hacking on a game that I hope will be fun). I'm Intrigued, I did not expect your suggestion It's an interesting direction. Would I be wrong to assume that the method you proposed actually could serve as dice? Actor A performs the blind-encryption and sends value to B, B recovers the plaintext and presents solution to A. Then both actors have established a semi-trusted random value? Well.. maybe, there's some considerations for time needed to be taken into account to dissuade transmitting pre-solved puzzles. – telamon Oct 03 '20 at 18:32
  • Update: Please disregard the mention about shared dice as what I was thinking of is mostly covered by mental poker and a completely different topic. As for @Serpent27 suggestion to use FHE for entropy reduction to create a ZK publicly verifiable bounty is quite brilliant. Will post updates once I explore that venue. – telamon Oct 26 '20 at 15:01
  • I wonder if an FHE keypair could be similarly tweaked to let a message signed with an intentionally weakened private-key to be verified using a weakened version of the public-key. The assumed value would be a CRDT Keypair with finite amount of uses given that only one message for each pair-derivate is accepted. Now this is quite outside of my expertise but I suspect that reducing hardness in a forward secure and linear fashion is extremely difficult and quite off-topic. I can open another question on that subject if anyone wishes comment. – telamon Oct 26 '20 at 15:17
  • After revisiting this question I pretty quickly realized a scheme that could allow reward in BTC. The rough idea is as follows: (1) take your blindly generated ciphertext. We will call this $c$. (2) publish $c$. (3) take $c' = c + s$ (homomorphic addition) where $s$ is the secret needed to access the reward funds. (4) publish $c'$ – Serpent27 Oct 27 '20 at 01:53

0 Answers0