Hoe werkt TimeLock?
Een uitleg van het versleutelingsproces, wat er waar wordt opgeslagen, en waarom niemand je bestand eerder kan openen.
Het proces in stappen
Wat wordt waar opgeslagen?
Op de server
- • Publieke sleutel van de eigenaar (voor vrijgave-verificatie)
- • Ontgrendeltijdstip
- • Vrijgavebeleid (tijd / handmatig / beide)
- • Willekeurig ronde-nummer
- • Master public key (voor IBE-versleuteling)
Niet op de server
- • Je originele bestand (nooit)
- • De versleutelde inhoud (nooit)
- • Je privesleutel (.tlck-key bestand)
- • Bestandsnamen of metadata van je bestanden
In je browser (tijdelijk)
- • Versleuteld bestand (alleen tijdens de sessie)
- • Na verversen: alles is weg — upload opnieuw
- • Er wordt niets permanent opgeslagen
Bij de gebruiker (bestanden)
- • .tlck bestand — het versleutelde bestand, te delen met de ontvanger
- • .tlck-key bestand — je privesleutel voor vervroegde vrijgave, veilig bewaren
Waarom is dit veilig?
1. De ontsleutelsleutel bestaat nog niet
Je bestand wordt versleuteld met Identity-Based Encryption (IBE) tegen een toekomstig ronde-nummer. De bijbehorende ontsleutelsleutel (een BLS-handtekening) wordt pas door de server berekend wanneer het tijdstip is bereikt. Tot die tijd kan niemand — ook de server niet — het bestand ontsleutelen.
2. Je bestand verlaat nooit je browser
Alle versleuteling en ontsleuteling gebeurt lokaal in je browser met de Web Crypto API en tlock-js. De server ziet nooit je bestand, de versleutelde inhoud, of zelfs de bestandsnaam. De server kent alleen het tijdstip en de publieke sleutel.
3. Wiskundig onmogelijk zonder de sleutel
TimeLock gebruikt BLS12-381 pairing-based cryptografie. Om te ontsleutelen zonder de BLS-handtekening zou je het discrete-logaritme-probleem op een elliptische kromme moeten oplossen — iets dat met huidige technologie onmogelijk is.
4. Vervroegde vrijgave vereist je privesleutel
Om een bestand eerder vrij te geven heb je het .tlck-key bestand nodig. De server slaat alleen je publieke sleutel op. Zelfs als de server wordt gehackt, kan een aanvaller geen bestand vrijgeven — daarvoor is je privesleutel nodig die alleen in het .tlck-key bestand staat.
Het vrijgaveproces gebruikt een challenge-response protocol: de server stuurt een willekeurige nonce, jij ondertekent die met je privesleutel, en de server verifieert de handtekening. Een onderschepte handtekening is waardeloos — elke challenge is eenmalig en verloopt na 60 seconden.
5. Gerandomiseerde ronde-nummers
Het ronde-nummer dat aan je slot wordt toegewezen is volledig willekeurig. Er is geen wiskundige relatie tussen het ronde-nummer en het ontgrendeltijdstip. Iemand die het ronde-nummer kent, kan daar het tijdstip niet uit afleiden.
6. Integriteitscontrole
Elk .tlck bestand bevat een HMAC-SHA256 handtekening over de gecomprimeerde inhoud. Bij het importeren wordt deze gecontroleerd. Als het bestand is gewijzigd of beschadigd, wordt het geweigerd.
Cryptografische details
| Versleuteling | Identity-Based Encryption op BLS12-381 (tlock-js) |
| Sleutelpaar vrijgave | ECDSA P-256 (Web Crypto API) |
| Challenge-signing | ECDSA met SHA-256 |
| Bestandsintegriteit | HMAC-SHA256 |
| Compressie | gzip (CompressionStream API) |
| Sleutelafleiding server | BLS signature: msk * H_G1(SHA-256(round)) |
| Realtime notificaties | Server-Sent Events (SSE) |