README
¶
Timelock
This is a experimental implementation of a custom-designed time-lock encryption mechanism.
This is very much a work in progress, and more than likely faulty, as I am not a cryptographer.
TODO: add details, design choices.
TODO: current implementation is very much a toy example with no real complexity. Needs to be updated.
Implementation notes
These are implementation notes stating mostly arbitrary choices as this is an arbitrary experiment. Actual choices have to be made still.
Functions:
- AEAD(plaintext, associated data, key, nonce), in this case AES-256-GCM.
- sha256(input)
- '🧩' indicates unknown "puzzle" value of certain length, with length contributing to difficulty to guess, i.e. puzzle complexity.
🧩input= sha256(🧩, input)
Given:
Each milestoneN represents an iteration in encrypted form. Each iteration relies on the result of the previous iteration. Any number of iterations can be used.
- input1
- milestone1 = AEAD(
input2,🧩input1, sha256(🧩input1), nonce1) - milestone2 = AEAD(
input3,🧩input2, sha256(🧩input2), nonce2) - milestone3 = AEAD(
secretKey,🧩input3, sha256(🧩input3), nonce3) - ciphertext = AEAD(
plaintext,🧩input3,secretKey, nonce4)
Remarks:
- Rationale:
- Follow the path of puzzles for a reasonable chance to beat decryption, or attempt to decrypt the ciphertext immediately facing maximum difficulty.
TODO: write down rationaleTODO: Is there any benefit to having the actual plaintext payload independent of the chain of iterations?
- Time-component realized through assumed average guessing time for puzzle component (
nnumber of bytes of random data). - Solution complexity / time-bounds determined by chosen one-way function, number of iterations of one-way function, number of iterations of milestone values.
- Massive parallelism mitigated by serializing solving capability by creating many iterations (of milestone values). Each iteration relies on the previous iteration's result for both key material and associative data.
- Trade-off: many milestones vs large puzzle-complexity for time-bounds. Many milestones of smaller complexity will give smaller upper and lower bounds for necessary time to solve? While number of milestones ensures certain amount of time needed to solve? (Does this even make sense?)
- As chained milestones each contain random byte-array being a key, it is hard to determine by statistical analysis whether or not decryption key is correctly guessed. Relies on authentication tag for confirmation of correct decryption. Authentication tag is obfuscated through associated data. Associated data is hash input, hence you need to know both hashed value used for decryption and original pre-image used for hashing. So 2 necessary parts for decryption:
- symmetric key, to decrypt content.
- associated data, to confirm of decryption result.
- Unhashed
?inputas associative data:-
to prevent skipping hashing challenge and tackling decryption directly. (If you know the key, you also know the associative data.)
It is outside of the model how the associated-data is made known to the receiver. We do not consider the associated-data to be part of the ciphertext, though the receiver will need it in order to decrypt.
-- Phillip Rogaway, 20 September 2002Seems to suggest that indeed
ADis a necessary component for decryption. -
to prevent 2nd pre-image attacks, as the original hash input needs to be known.
-
- Start sha256 hash-content with puzzle component, one cannot reuse "prehashed input". (puzzle component is the variable)
O(1)for creator, as he can choose the puzzle components.
O(avg-hashing-time-to-find-puzzle-component)for solver, as he needs to rediscover the same puzzle components, e.g. try out every byte-combination.- Choices of one-way function, AEAD cipher, etc. are arbitrary choices atm based on what is readily available in Go standard library.
- Individual milestone inputs can be released at will, in order to progress decryption effort.
- ...
TODO
- Actual secret data is not associated with last milestone, is there any value in doing so?
- Theoretical questions:
- Investigate if lengths of all values in use are acceptable in real-world scenarios. Are we crossing any boundaries/limits that violate cryptography rules?
- Investigate whether using "hash input" as associated data might reveal any information on the "hash input". (To what extent is associated data recoverable from the ciphertext?)
- How is this approach different from chained hashes? Each milestone can be solved with a single correctly guessed solution, so in theory can be solved very quickly. How is this different for chained hashes?
- Confirm: AEAD is guaranteed to use AD to "obfuscate" authentication tag?
- Write document explaining, detailing the mechanism.
- look up actual terminology instead of own made-up stuff ...
- increasing complexity with each iteration.
- different types of hardness by choice of one-way function (cpu-bound, memory-bound, ...) (As described in article)
- Fine-tune implementation to make it actually useable.
- See if we can prove this: https://tamarin-prover.github.io/
References
Material for on-the-fly learning of cryptographic concepts: (seriously, I'm mostly a noob with this stuff ...)
- https://en.wikipedia.org/wiki/Authenticated_encryption
- https://blog.cryptographyengineering.com/2012/05/19/how-to-choose-authenticated-encryption/
- https://web.cs.ucdavis.edu/~rogaway/papers/ad.pdf (needed to check up on security guarantee for "associated data", i.e. needed to confirm that "associated data" is a necessary component for decryption)
- https://tools.ietf.org/html/rfc5116
- YouTube: Time-Lock Puzzles from Randomized Encodings
The following references were inspiration to this custom solution.
References still to read:
Documentation
Source Files
Directories