3 ms·

I think the second one applies but I don't see how indistinguishability obfuscation could allow for the first.

• eternalban 6y ago
  (sorry for late reply.) There was a bit in the OP that said in passing, "[f]or instance, it enables the creation of “deniable” encryption, in which you can plausibly convince an attacker that you sent an entirely different message from the one you really sent". So candidate plaintexts that are plausible sources for the obfuscated blob appears to be a capability of this approach.
  • schoen 6y ago
    Thanks, now I see the connection. As there's a whole other thread going on right now about deniable encryption (in the context of e-mail), I think it's worth pointing out that the recipient still typically knows whether or not a particular encryption method is deniable. Such methods would presumably not be a good idea to use for software distribution. In other words, the deniability is an intentional construction that could be used if parties feel they have a reason to use it (like in a messaging application, as tptacek and Matthew Green are arguing for). However, it's not something that automatically applies to all signature methods merely because of the existence of indistinguishability obfuscation. A software signature method that is constructed to have a deniability property is probably not one that a software user should accept. :-) In my view, which I've expressed elsewhere, software releases should move in the exact opposite direction by including advertisements of their existence in a public log (whether that's a blockchain, a widely-distributed git repository, a Certificate Transparency log, or whatever).