h a l f b a k e r yIf you can read this you are not following too closely.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
dlog: Digital Time Capsule
Place a server with a self-destruct envelope to generate public keys, and private keys after set number of seconds, and let the world create wonders :) | |
We have blogs, but when we write something, it immediately becomes
available to the author. A dlog would be a blog, that is public, but its posts
are only readable after a set number of seconds from their inception.
This is how it would work:
1) An author writes an entry, chooses the number
of seconds, after which it
should become decryptable, and hits enter.
2) A new public key is requested to a server (computer) placed into a self-
destruct envelope, that deletes the computer's data upon tinkering with it.
(This guarantees that we either don't see the message at all, or see it after
the entered number of seconds.)
3) The author then gets the data encrypted with that public key, and
published
on-line.
4) After the N number of seconds, the server publishes the decryption key.
5) The client picks up the decryption key, if it exists, and displays the
message
decrypted, if possible, or encrypted otherwise.
Inspired by sci-fi, and delayed communications over great interstellar
distances.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
// delayed communications over great interstellar
distances.// This is basically how HMRC operate. |
|
| |
The HMRC of the United Kingdom of Great Britain? |
|
| |
Digital time capsule is a nice idea but the implementation is a bit boring -- if you're depending on a server to release the key after a certain time, you might as well just depend on that server to release the data itself. |
|
| |
Much better to encrypt the data with a symmetric cipher and publish the SHA-256 checksum of the secret key. So long as there is something of value in your capsule (maybe stick a bitcoin address at the end of it) someone will attempt to derive the key from the checksum. You can control how long this will take by publishing a fractional part of the checksum. |
|
| |
[mitxela], yeah, but that depends on you, the author... And what if you're
long gone before the time when the capsule is intended to become
visible? |
|
| |
> someone will attempt to derive the key from the checksum |
|
| |
Yes, and we don't know how much time it will take for them to do it, still
need the server... |
|
| |
I'm lost at this, [Max], and the Acronymfinder (dot) com doesn't help. |
|
| |
// but that depends on you, the author // |
|
| |
You seal the capsule by encrypting it, releasing the key's checksum and deleting the secret key. To be really sure, publish it by linking it into the blockchain, where it will be preserved basically forever. You could die the next day, the capsule would be set and ready to be opened. |
|
| |
It takes a reasonably predictable amount of computing time to reverse SHA checksums, this is basically how bitcoin works and was what I was alluding to. To be extra sure, do multiple rounds i.e. have each capsule contain the encrypted data and checksum of another capsule, only after solving all of them is the final data revealed. |
|
| |
> It takes a reasonably predictable amount of computing time to reverse
SHA checksums |
|
| |
I would think in most cases, not predictable enough... You can't time
very precisely, and it's going to be costly,
because it will depend on investment into computing power. No
compute investment - no guarantee that the capsule will be ever
opened.
And, it's
already done -- e.g., blockchains with PoW scheme use that. (E.g.,
challenge difficulty is intentionally made dependent on the computing
power of the network, that way, ensuring that the secret will be solved in
a predictable amount of time. However, it could be solved much faster, if
suddenly huge compute resources were added, or much slower, if
suddenly people were not interested in mining it, and while you could
get precision through the law of large numbers, again, it's costly and
depends on the social incentives to mine. E.g., bitcoin would stop exist
immediately, if all miners found a better purpose to use the machines.
What this idea presents, is something that's cheap, scalable, and
independent on social incentives to mine.) |
|
| |
Agree that it's a more boring implementation. If we have a better cheap
cryptographic and elegant solution, I'd be definitely curious to think of it. |
|
| |
If an author writes someting, then almost by definition //it immediately becomes available to the author//, whether the author uses an instant publishing scheme or a delayed publishing scheme. |
|
| |
What is the purpose of this joint? If the author wishes to write something and not publish it immediately, why then are they going to press the "publish" button? They could just press the "save as unpublished draft" button. |
|
| |
The only thing I can think of is if the author wants to conceal things from themselves. They could be drugged or hypnotised, and then write secret and destructive subconscious knowledge, which they wished to preserve but not have access to. |
|
| |
I think that the //delayed communications// in //sci-fi// are actually a direct result of //great interstellar distances// and are not actually reliant on a scheme like this. |
|
| |
// If an author writes something, then almost by definition //it immediately becomes available to the author //// |
|
| |
It is hard to argue with such straight forward logic. |
|
| |
Perhaps an alternate form of time capsule would be a delayed email system. You send an email to a particular non-existent address, which after 48 hours triggers a bounce. But by carefully manipulating the headers, the bounce is sent to a different email address, which is configured to auto-reply to yet another email address (also non-existent, but on a different mail server), which after 48 hours triggers a different bounce, and so on, with the email eventually arriving at its destination weeks after it was sent. On its journey the message would exist in a kind of email limbo, where no-one really knows where it is. Of course modern email servers are too clever and would make this impossible to work, the joyless bastards. |
|
| |