エンドツーエンド暗号化されたペーストビンをどのように構築したか（そしてなぜサーバーはあなたのテキストを読むことができないのか）

got annoyed that pastebin and similar sites log everything and keep your text forever, so i built one where the server literally cant read what you paste. heres how the encryption actually works and what i learned building it the problem most paste sites work like this: you type something, it goes to their server as plain text, and it sits in their database. they can read it. their employees can read it. anyone who breaches them can read it. and a lot of them keep it forever even after you think its gone. i didnt want to just promise not to look at your stuff. i wanted it so that i cant look even if i wanted to. the idea: encrypt before it leaves the browser the trick is that all the encryption happens on your side, in the browser, before anything gets sent. the server only ever sees scrambled bytes. the key never touches the server at all, it lives in the part of the url after the # , which browsers dont send in requests. so the flow is basically: you paste text browser generates a random key text gets encrypted with that key only the encrypted blob goes to the server the key gets stuck in the link after a # whoever opens the link decrypts it locally the actual code modern browsers have the Web Crypto API built in, so you dont need any library for this. heres the encrypt part, stripped down: \ `js async function encrypt(text) { const key = await crypto.subtle.generateKey( { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"] ); const iv = crypto.getRandomValues(new Uint8Array(12)); const encoded = new TextEncoder().encode(text); const ciphertext = await crypto.subtle.encrypt( { name: "AES-GCM", iv }, key, encoded ); // export the key so we can put it in the url const rawKey = await crypto.subtle.exportKey("raw", key); return { ciphertext, iv, rawKey }; } ` \ the ciphertext and iv go to the server. the rawKey gets base64'd and dropped into the link after the # . decrypting is just the same thing in reverse with crypto.subtle.decrypt . the thing that tripped me up the # part of a url (the fragment) never gets sent to the server. thats the whole reason this works, the key stays client side. but it also means if you log requests anywhere, you have to be careful you arent accidentally capturing the full url somewhere on the client and shipping it off. took me a bit to convince myself nothing was leaking it. also: burn after read is harder than it sounds. you have to delete on the server the moment its read, but handle the race where two people open the link at the same time. i settled on deleting on first successful fetch and just letting the second person get a 404. anyway ended up turning it into a small thing you can actually use: hidetext.sh . no accounts, no tracking, optional burn after read, and it does files and qr codes too. curious how other people have handled the burn-after-read race condition though, if youve built something similar lmk got annoyed that pastebin and similar sites log everything and keep your text forever, so i built one where the server literally cant read what you paste. heres how the encryption actually works and what i learned building it the problem most paste sites work like this: you type something, it goes to their server as plain text, and it sits in their database. they can read it. their employees can read it. anyone who breaches them can read it. and a lot of them keep it forever even after you think its gone. i didnt want to just promise not to look at your stuff. i wanted it so that i cant look even if i wanted to. the idea: encrypt before it leaves the browser the trick is that all the encryption happens on your side, in the browser, before anything gets sent. the server only ever sees scrambled bytes. the key never touches the server at all, it lives in the part of the url after the # , which browsers dont send in requests. so the flow is basically: you paste text browser generates a random key text gets encrypted with that key only the encrypted blob goes to the server the key gets stuck in the link after a # whoever opens the link decrypts it locally the actual code modern browsers have the Web Crypto API built in, so you dont need any library for this. heres the encrypt part, stripped down: \ `js async function encrypt(text) { const key = await crypto.subtle.generateKey( { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"] ); const iv = crypto.getRandomValues(new Uint8Array(12)); const encoded = new TextEncoder().encode(text); const ciphertext = await crypto.subtle.encrypt( { name: "AES-GCM", iv }, key, encoded ); // export the key so we can put it in the url const rawKey = await crypto.subtle.exportKey("raw", key); return { ciphertext, iv, rawKey }; } ` \ the ciphertext and iv go to the server. the rawKey gets base64'd and dropped into the link after the # . decrypting is just the same thing in reverse with crypto.subtle.decrypt . the thing that tripped me up the # part of a url (the fragment) never gets sent to the server. thats the whole reason this works, the key stays client side. but it also means if you log requests anywhere, you have to be careful you arent accidentally capturing the full url somewhere on the client and shipping it off. took me a bit to convince myself nothing was leaking it. also: burn after read is harder than it sounds. you have to delete on the server the moment its read, but handle the race where two people open the link at the same time. i settled on deleting on first successful fetch and just letting the second person get a 404. anyway ended up turning it into a small thing you can actually use: hidetext.sh . no accounts, no tracking, optional burn after read, and it does files and qr codes too. curious how other people have handled the burn-after-read race condition though, if youve built something similar lmk