h a l f b a k e r yThis is what happens when one confuses "random" with "profound."
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,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
A website which publishes a list of public keys, one for every day of the coming
timeperiod. When each day arrives, the corresponding private key is published.
This would be useful for those times when you would like to make sure something is
widely published, but not readable until a specific
day, such as a note explaining
why you killed all those people. It would also be useful for things such as keeping
the combination lock code on your cookie jar a secret from yourself until the day
your diet is scheduled to end.
Rivest, Shamir, Wagner: Time lock puzzles and timed-release crypto
http://www.google.c...7Nlc0YjspvQ&cad=rja
I would have linked to a copy of Timothy May's cypherpunks post, but those pointers seem to lead to dead ends. I also can't imagine that this wasn't discussed before '93. [jutta, Apr 09 2011]
Time Capsule encryption
Time_20Capsule_20encryption
Essentally the same idea. But I guess you made it succinct. [mofosyne, Apr 10 2011]
[link]
|
| |
die katze kroch in die krypta, kackte und kroch wieder heraus. |
|
| |
simple, useful, original. Big tasty bun. |
|
| |
The general problem is called "timed-release cryptography". It would be nice to have a solution that doesn't require online access and doesn't involve trusting a third party. |
|
| |
Has anyone proposed using the trajectories of
asteroids for timed release cryptography? I'm assuming
they're
chaotic, thus computable, but only with very large
computers, analogous to factoring large numbers. But
unlike factoring, if you wait for the appointed date,
you can (in principle) determine the key with nothing
more
expensive than a telescope. |
|
| |
This avoids the requirement for online access, though one
still has to trust a third party with a very large
computer |
|
| |
// The general problem is called "timed-release cryptography" // |
|
| |
I see, so it's a known problem. But are there any public servers actually
implementing this, right now? |
|
| |
I'm considering setting one up myself but my VPS wouldn't be able to generate
enough entropy to come up with this many keys unless I sit there logging in
and out all day )-: |
|
| |
An associate was telling me of a service
in germany that will embed code into your online
profile photos, so on a certain preset date they
will expire and the companies logo will show up. |
|
| |
Though the intent of the software is to allow
people how long someone can access your photos,
I was most interested by how the image flips to
the companies logo, like a kind of timed
steganography. |
|
| |
Using the same basic Idea, I imagine one could
post boring photos all over the net that would on
some date the photo would change to a treasure
map or any other information that can be
represented visually. |
|
| |
Wouldn't time released private keys be a lot
more vulnerable? I imagine there are a dozen ways
you manipulate the time on a box and change it to
the year 3000 or something.. |
|
| |
As far as I know "The Military", whoever they are, have researched several of the; do not decrypt if <not at location>, or do not decrypt until <third party criterion=true>, or do not decrypt until <time=t>, amongst others. Most of these rely on zero-knowledge proofs for a challenge response authorisation. The underlying encryption protocols remain in use. |
|
| |
Why not just write the key on the asteroid. |
|
| |
at 4whom: So you're thinking the time criteria
wouldn't be checked internally, but would be done
by some 3rd party computer? interesting! I suppose
in that case packet injection or ID spoofing might be
possible right? or maybe take over the 3rd parties
computer? |
|
| |
// I imagine there are a dozen ways you manipulate the time on a box and change it to the year 3000 or something.. // |
|
| |
This is why you do not give control of key store system to the person who holds the encrypted data; instead the keys are entrusted to a third party such as verisign. |
|
| |
[irid...] That is Tim May's suggestion, however how long do TTPs stay TTPs? |
|
| |
//Why not just write the key on the asteroid.// If you
substitute "artificial satellite in highly eccentric
circumsolar orbit" that might work. |
|
| |
It seems the "standard" no-3rd-party technique is to
encrypt using a method that provably requires a certain
number of standard arithmetic operations for decryption
and
is provably unparalellizable. This uses "CPU cycles" as a
unit of time -- requiring that code run on known hardware,
which must be hardened against overclocking. |
|
| |
So far, all suggestions rely on inaccessesibility of a physical
object. If that's really a requirement, then a satellite in
the Oort cloud sounds a better candidate than a server or
the innards of an RSA card. |
|
| |
[bob] You are completely misunderstanding my misunderstanding of the concepts. No third parties necessary. The challenge-response mechanisms for zero knowledge proofs need not be third party (although they can be). They can also be made dependent on other attributes (location, time, how many sieverts/unit time are being given off by the local banana plantation, has third party completed action “x”).This way you can even keep a secret from yourself until a condition is true. |
|
| |
Although I am still not getting the problem, nor the solution, posed by [idris...].
The most useful implementation would be the // It would also be useful for things such as keeping the combination lock code on your cookie jar a secret from yourself until the day your diet is scheduled to end.// and the like. I.e keeping secrets secret, even from oneself.
Zero knowledge proofs would be the key (i know, bad joke) to this system, as opposed to issuing, and administrating, large amounts of keys, and times, etc. |
|
| |
I wonder if there is anyway to perhaps to make the confirmation of time a p2p process perhaps. |
|
| |
E.g. The packet needs to bounce around a number of times and encounter a x-number of computers with the correct time to compute the correct decryption keys. |
|
| |
[Akimbo...] now there's a problem! From your lips to... |
|
| |
Oh the hell 4whom! Looks like OP actually typed it up first D: , I swear I though it up independently as well. |
|
| |
Anyhow, would it work if you perhaps send copies of different parts of a key to random servers hidden in tor? At a specified time it will respond by sending the key to a specified location. |
|
| |
This may be much safer, provided most of the servers are honest, that there are enough servers and there is a critical mass of people using the services. Because these servers do not know who sent them the original key, they can't use it. Also even if they know, they have to get the other half/quarter/dozen parts of the key needed to decrypt it. |
|
| |
I appreciate your patience with me. I'm trying to
grasp this but Im a two semesters away from my first
Crypto course. |
|
| |
I had never thought that one would need to keep
information from oneself, but your example makes a
good point Idris! |
|
| |
I suppose using a public key and then losing the private key, then supplying appropriate brute force cracking software sort of gives it some kind of time delay if the number of digits for encoding is controlled. |
|
| |
But how about some kind of hardware dongle that uses a clock that ouputs something using the signature technique. I'll need to sit down and go through it on paper 'cos I can't quite remember all the principles. |
|
| |