By the way, using SMPC remotely can be generalized beyond "Dead Man Switch"
pretty easily (IMHO). While SMPC actually isn't needed to do a DMS, just
secret sharing, SMPC lets you hide the terms for when to release the
secret, and even to change the terms while keeping them secret. Here's how:
First one creates a scripting engine that can run inside the SMPC. This can
be a Python or Bash port if one wants that. Then one writes a script that
will run inside the SMPC that during the first run that takes shares from a
secret sharing scheme. Each node gets different shares.
The data in these shares then contain a flag that says "first run", an
asymmetric key (generated by you in advance), the secret data and a script
with the actual conditions for releasing the secret. Then the loader script
assembles the shares and run that conditions script. That script also see
that this is the first run. So it gives certain commands to the software on
the outside of the SMPC as it's output. This can be "look for X at website
Y every Z hours, and run me again in 6 hours" or whatever. The response is
given in a certain format the script can understand as input during the
next run of the SMPC.
The internal state in the SMPC with all the data and code we want to save
is encrypted and split in new shares ("Grantor was last heard of
2021-06-12; run code X next time"?), this is part of the output and tagged
as the input shares for the next SMPC run. This replaces the original
shares. As the input fetched to the SMPC can contain new code, you can give
the SMPC new instructions this way. The new code in the SMPC can also give
new commands to the code outside the SMPC (that code that runs the SMPC and
fetch and pass on data).
The data the SMPC scheme is supposed to fetch should be both encrypted to
it's public key and signed by your public key (you have to give the SMPC
your public key then too, obviously).
So you rent a bunch of servers online, anonymously, and set up this SMPC
scheme on it.
So, what would you guys run on this thing? Remember that the overhead makes
it slooow, so no secret bruteforcing of anything.
- Sent from my tablet
Den 5 sep 2012 16:21 skrev "Natanael" <[email protected]>:
> If the trustee (correct word?) stops passing the messages to your "CDMS"
> (cryptographic dead man switch), it would simply decrypt the original
> message automatically. So you can not put the entire mechanism in the hands
> of the trustee, especially not the part that authorizes the decryption. I
> could imagine that you would set up a remote server that would simply send
> the secret to the trustee, encrypted to his public key for security, when
> you stop "pinging" it by sending signed messages.
>
> To prevent one server from being compromised and revealing the secret
> (even if only to the trustee since it can be pre-encrypted), I could
> imagine chained-session Secure Multiparty Computation across several remote
> servers. The idea is that you run the SMPC software on your remote servers,
> give a large random number to each, they generate a keypair inside the
> virtual SMPC machine, and you encrypt the message to that key.The machines
> split the keypair among themselves using a Secure Sharing Scheme. You send
> that encrypted message to all the machines. Each day the machines re-run
> the SMPC, sends their key parts and reassemble them using the secret
> sharing scheme inside the SMPC, checks if a signed message have been
> recieved from you, and if not it decrypts the secret message to the
> trustee. A program on the machines will then see this message as the output
> from the SMPC and send it to the trustee.
>
> Overly complicated, maybe, but secure and can actually work.
>
> On Wed, Sep 5, 2012 at 3:51 PM, StealthMonger <
> [email protected]> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> Can there be a cryptographic "dead man switch"? A secret is to be
>> revealed only if/when signed messages stop appearing. It is to be
>> cryptographically strong and not rely on a trusted other party.
>>
>> The motivating application is a Living Trust wherein the Grantor wants
>> to keep secret, even from the Trustee, the locations of his caches of
>> gold until such time as he is no longer able to send signed messages.
>> Each signed message has to somehow avert revelation of the secret for
>> another time period (three months, say).
>>
>> - --
>>
>>
>> -- StealthMonger <[email protected]>
>> Long, random latency is part of the price of Internet anonymity.
>>
>> anonget: Is this anonymous browsing, or what?
>>
>> http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain
>>
>> stealthmail: Hide whether you're doing email, or when, or with whom.
>> mailto:[email protected]?subject=send%20index.html
>>
>>
>> Key: mailto:[email protected]?subject=send%20stealthmonger-key
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/>
>>
>> iEYEARECAAYFAlBF1ecACgkQDkU5rhlDCl5omQCgpcuTWhFuojJkkgUOLeZwnYIf
>> TlwAnAhrxdyeLMccamIAZ8CbLZKn2jyb
>> =MaVJ
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> cryptography mailing list
>> [email protected]
>> http://lists.randombit.net/mailman/listinfo/cryptography
>>
>
>
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
