gwern comments on Cryptographic Boxes for Unfriendly AI - Less Wrong

24 Post author: paulfchristiano 18 December 2010 08:28AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (155)

You are viewing a single comment's thread. Show more comments above.

Comment author: paulfchristiano 24 December 2010 01:03:38AM 2 points [-]

Sorry that this was unclear. The intended use is that the code of the AI itself is the encrypted input, and the plaintext program manipulating it is an interpreter for the language in which the AI is written. For example, the AI could be specified as a LISP program and a homomorphically encrypted copy would be given as input to a LISP interpreter.

Comment author: gwern 24 December 2010 01:29:25AM *  0 points [-]

So (in Haskell notation) our total set up would be something like eval (evilAI ++ problemDescription ++ verifier) where eval :: EncryptedBitstream -> EncryptedBitstream, and the homomorphic argument/input to our evaluator is effectively one gigantic inlined/combined function with no further input?

Comment author: paulfchristiano 24 December 2010 02:19:49AM *  0 points [-]

Correct. The result of that call then gets decrypted.

In Haskell, HomomorphicEncryption would probably be a monad.

Edit: actually, it makes sense syntactically for it to be a monad but Haskell doesn't really have the machinery to make it work so scratch that.

Comment author: gwern 24 December 2010 03:15:46AM 0 points [-]

No no, Haskell probably does. Look at the ST monad - you go 'into' it and then you can perform all sorts of destructive updates but purity is preserved by having to 'escape' it before its results are available anywhere else.

Comment author: paulfchristiano 24 December 2010 04:00:33AM 0 points [-]

The problem is that the only thing Haskell can do with functions is use them as black boxes, to the best of my knowledge. To apply a function to homomorphically encrypted data, you can't use it as a black box---you need to use an explicit description of the function.

Comment author: gwern 24 December 2010 04:30:27AM *  0 points [-]

Well, my point was that you can do something akin to Perl's taint - force operations to be done only within a particular type context.

So you could do something similar to the ST monad but instead of accepting functions which generate any type output, it operates on, say, a parse tree/ADT representing a Lisp function which is evaluated with the rest of the homomorphic data.

But it's not really important; any such strategy would probably be done in a new language (for efficiency, if nothing else) and the into/escape invariant enforced by manual code inspection or something.