Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
DropLock – 免後端、免註冊的端到端加密傳密工具，安全傳遞 API Key 與密碼
DropLock 是免後端、免註冊的端到端加密傳密工具，密文藏在網址片段、伺服器全程不碰明文，適合臨時傳 API Key、Token 與密碼。本文附實機截圖教你三步完成加密傳輸，並比較 Privnote、Yopass、Firefox Send，說明主機信任等使用限制。
用 AI 摘要這篇文章：
DropLock 是一個連後端都不需要的端到端加密傳密工具：接收方先在瀏覽器本地產生金鑰，發送方只用公鑰加密內容，密文藏在網址的片段裡，伺服器全程碰不到明文，特別適合拿來臨時傳遞 API Key、Token 與一次性密碼。整個流程只靠一個靜態 HTML 頁面就能跑完，連帳號註冊都省了。
TL;DR：DropLock 用單一靜態頁面跑完整套端到端加密，密文存在網址的
#m=片段、瀏覽器不會把它送給伺服器；適合臨時傳 API Key、Webhook Secret，但未經專業審計、沒有過期控制與存取日誌，更要注意「提供頁面的主機能不能信任」，因此不能取代 1Password 這類密碼管理器。
目錄
DropLock 是什麼？連後端都省了的加密傳密工具
一句話講：DropLock 是一個把「端到端加密」做到連伺服器都不需要的臨時傳密工具。它不是密碼管理器，也不是企業級金鑰平台，而是一個很輕的「傳完即棄」管道。核心檔案就一個 index.html，不依賴資料庫、不需要後端 API，你甚至可以把整個專案抓回來放到自己的靜態主機或內部網路裡跑。
它的官方線上 demo直接打開就能用，原始碼也完整公開在 GitHub。對於在意「對方伺服器到底有沒有碰過我的明文」的人來說，這種設計會比傳統 Firefox Send 這類加密檔案傳輸、或 Keychat 私密聊天服務更容易讓人安心，因為這裡根本沒有伺服器在幫你存東西。說白了，沒有伺服器就沒有資料庫可被攻破。就像我們介紹過的 Archive Forever 把資料寫進區塊鏈、或 Joplin 這類開源筆記工具，重點都在「攤開來讓你自己檢查」。
解決什麼問題：明文傳 API Key 到底多危險
日常協作裡，我們常常要把很短、但極度敏感的文字交給同事或外部廠商：一支高權限的 API Key、資料庫的臨時密碼、某個服務的 Webhook Secret，或一段短期有效的設定片段。多數人的直覺是直接貼進 LINE、Slack 或 Email。
問題是，明文一旦送出去就不再受你控制。它可能停留在對話紀錄、手機的通知預覽、企業郵件的搜尋索引，甚至是合規封存系統裡；即便你用的是 自訂網域信箱，內容一樣會留在收件匣與伺服器封存。哪天對方的帳號被盜、裝置遺失，或公司被稽核，這把金鑰就靜靜地躺在那邊等著被翻出來。
你可能會想到「閱後即焚」類的一次性連結工具，連我們介紹過的 69FUN 縮網址都標榜密碼保護功能。但很多這類工具背後還是有一台伺服器在幫你存放或中轉內容，安全性很大程度上取決於它們的加密實作、金鑰存放方式，以及伺服器到底有沒有參與明文處理。DropLock 想解決的就是這一塊：讓伺服器在正常流程裡完全不需要碰到秘密內容。
DropLock 怎麼運作？逆向的「接收方建鎖盒」設計
市面上多數分享工具的邏輯是「你填入密碼，網站幫你產生連結」。DropLock 反過來，採用的是「接收方主動索要」的逆向機制。聽起來多一步，卻能在純前端環境裡跑完一個相對乾淨的加密閉環。
關鍵在於它對網址片段（URL fragment）的運用。接收方產生的鎖盒連結會把公鑰放在 #k= 裡；發送方加密完成後，回傳連結把密文放在 #m= 裡。而網址 # 後面的這一段，瀏覽器在正常請求時根本不會送給伺服器，所以 DropLock 的伺服器實際上只負責分發那個靜態頁面，既拿不到密文，也拿不到本地的私鑰。順帶一提，網址本身常藏著隱私眉角，像注重隱私的 Miny.app 縮網址，或主打行銷分流與追蹤的 Lihi.io 短網址，背後的追蹤邏輯都值得先弄清楚。
實作上它走的是混合加密流程：先用 ECDH 派生共享金鑰，再透過 HKDF 派生 AES-256-GCM 金鑰來加密文字（詳見 GitHub 原始碼與 FORMAT.md）。你不需要懂這些演算法細節，只要把握一個重點：明文從頭到尾不會離開發送方的瀏覽器，也不會送進任何伺服器。如果你對加密這件事有感，mkcert 在本機啟用 HTTPS 講的是傳輸層加密，AvePDF 與 CleverPDF 這類線上加密 PDF 工具則是檔案層加密，跟 DropLock 的訊息層加密剛好是三個不同層次，對照著看會更清楚。
實測教學：三步驟把 API Key 加密傳給同事
講了半天原理，不如實際跑一遍。下面這組截圖是我直接在 DropLock 官方 demo 上操作的真實流程，從接收方建鎖盒、發送方加密，到接收方解密還原，全程沒離開過瀏覽器。提醒一下：使用官方 demo 等於信任 apitman.com 這台主機提供的 JavaScript，要完全不信任第三方，請改用後面提到的自架方式。
第 1 步：接收方生成鎖盒連結
需要別人傳金鑰給你的人（接收方），先打開 DropLock 頁面。這時瀏覽器會在本地產生一對公私鑰，私鑰以不可匯出的 CryptoKey 形式留在當下這個瀏覽器，正常情況不會離開你的裝置。頁面接著產生一個帶有公鑰的鎖盒連結，這個連結本身不含任何秘密，只是告訴對方：「待會要傳的內容，請用這把公鑰加密。」
第 2 步：發送方用公鑰把金鑰鎖起來
把鎖盒連結交給對方後，對方打開會看到「Share a secret」的輸入介面。在這裡貼上真正的 API Key、Token 或設定片段，按下 Lock it，發送方的瀏覽器就會用連結裡的公鑰在本地完成加密，再產生一個回傳連結。
這裡我故意用了一組公開的範例測試金鑰來示範。重點是：加密動作發生在發送方的瀏覽器，產生的密文被塞進回傳連結的 #m= 片段，這段內容不會送回 DropLock 的伺服器。
第 3 步：接收方在本地解密還原
把回傳連結交還給接收方，打開的瞬間，頁面會用一開始就存在這個瀏覽器裡的私鑰把密文解開，明文直接顯示在畫面上。整個解密同樣在本地完成，伺服器依然只是個發靜態頁面的角色。如果你常需要這類「傳完就清」的場景，它跟 LastPass 隨機密碼產生器搭配起來會滿順的：先用產生器造一把強密碼，再用 DropLock 加密傳出去。
DropLock vs Privnote、Yopass、Firefox Send 比一比
臨時傳密工具並不少見，但解法差很多。下面這張表把幾個常見選項攤開來比，重點不是誰功能多，而是「伺服器到底有沒有參與秘密的存放與解密」。
| 工具 | 伺服器角色 | 是否可自架 | 明文接觸 | 適合誰 |
|---|---|---|---|---|
| DropLock | 只發靜態頁面 | 可（靜態託管） | 正常流程不碰明文 | 開發者、小團隊臨時傳短文字 |
| Privnote／一次性連結 | 伺服器端加解密 | 視服務而定 | 明文經過伺服器記憶體 | 想「打開即銷毀」體驗的人 |
| Yopass | 存放加密後內容 | 可（自架伺服器） | 存的是密文、需自管伺服器 | 想自架掌控環境的團隊 |
| Firefox Send | 存放加密檔案 | 官方已停用（曾可自架） | 端到端加密、伺服器存密文 | 需傳較大檔案的使用者 |
可以看出 DropLock 的差異點不在功能多寡，而在互動設計更輕：一個靜態 HTML 頁面就能跑完整個加密流程。它跟 Firefox Send 加密檔案傳輸、Dropbox Transfer、FastSend P2P 加密傳檔 這類以「檔案」為主的工具相比，更適合「短短一段文字」的場景。
如果你要傳的是較大的檔案，MailBigFile 透過 Email 寄送、或 奶牛快傳 CowTransfer 這類大檔案傳輸服務會更順手。說到底，挑工具的關鍵是先釐清自己要傳的是「一段文字」還是「一個檔案」，再決定該用哪一種。
使用前必懂的 4 個限制：MITM、綁定瀏覽器、主機信任、未經審計
DropLock 能降低伺服器碰明文的機會，但它不是萬能。拿來傳正式金鑰之前，這四件事一定要知道。
1. 中間人攻擊風險（MITM）。DropLock 沒有做金鑰指紋校驗。要是在傳輸過程中，有人把你的「空鎖盒連結」偷偷換成攻擊者自己的連結，發送方就會把 API Key 加密給攻擊者。對於極度機密的資料，建議透過兩個不同的通訊管道交叉核對連結是否一致，這是 DropLock 自己也點明的取捨；再貴的 VPN 或 CDN 也取代不了這一步手動核對。
2. 私鑰綁定當下那個瀏覽器。解密用的私鑰保存在最初產生鎖盒的瀏覽器環境裡。如果你用手機產生鎖盒，回頭想用桌機打開對方回傳的密文，通常解不開，必須回到最初那台裝置與瀏覽器。使用前最好先想清楚「誰要在哪台裝置上解密」，否則密文解不開只能重產鎖盒。
3. 你必須信任提供頁面的主機。這一點最關鍵，卻最容易被「伺服器不碰明文」的說法蓋過。DropLock 的加密邏輯全部寫在伺服器發給你瀏覽器的 JavaScript 裡：如果官方 demo 所在的 apitman.com 這台第三方主機被入侵，或營運者惡意改版，它可以送出會偷走私鑰或明文的程式碼，而瀏覽器的 non-extractable CryptoKey 完全擋不住這種攻擊。要真正降低風險，只能自己從 GitHub 拉原始碼、審查後部署到自己控制的內網靜態主機，再讓對方透過你信任的管道連到那個版本。若要傳高權限的生產金鑰，請務必走自架這條路，而不是直接用官方 demo。
4. 未經專業審計，也不適合長期管理金鑰。官方明白表示程式碼沒有經過安全專家審計；而由於它只是一個沒有後端的靜態頁面，自然也沒有過期控制與存取日誌功能。它是一條臨時傳輸管道，不能取代 1Password、Vault 這類企業級密碼管理器或 Secret Manager。長期管理 API Key 與資料庫密碼，還是要交給專門的工具；DropLock 負責的只是「傳過去」這一下。
適合誰用？最佳與不適合的場景
DropLock 最順手的場景，是低頻、臨時、點對點的敏感文字傳遞。開發者之間臨時交接 API Key、Token、Webhook Secret、資料庫臨時密碼、邀請碼，或一段短期有效的設定片段，都是它最合適的用途。
反過來說，如果只是傳一般帳號、低風險口令，普通的 匿名郵件或一次性連結就夠用了，不必動用到非對稱加密。而需要長期存放、多人共用、要稽核誰何時讀取的情境，請改用正規的密碼管理器或 Internxt Drive 加密雲端空間，DropLock 幫不上忙。
對獨立開發者、小團隊或運維人員來說，它最大的吸引力是可以放到自己的環境裡跑。只要選擇自己部署，就不必擔心第三方服務哪天關站或改條款，因為核心就是一個 index.html，能擺在靜態託管環境或內網中自行審查與部署；這點跟 Hve Notes 部署靜態部落格到 GitHub Pages、或租一台 Bluehost 主機自己架站的精神很像，都是「把東西放在自己掌控的地方」。搭配 Filester 在 WordPress 後台管理檔案，自架環境的日常維護也能輕鬆不少。
常見問題 FAQ
DropLock 免費嗎？需要註冊帳號嗎？
完全免費，也不用註冊。它是一個開源的靜態網頁工具，打開官方 demo 就能用，你也可以把原始碼抓回來自己架。工具本身沒有帳號系統，也沒有用量限制的設計，因為正常流程裡伺服器根本不參與內容處理。
DropLock 可以傳檔案嗎？
不適合。DropLock 是為「短文字」設計的，拿來傳 API Key、Token、密碼這類內容最合適。要傳較大檔案，前面提過的 Dropbox Transfer、FastSend 與 MailBigFile 會更順手；若是常見的下載需求，Free Download Manager 也是穩定的選擇。
DropLock 可以取代 1Password 或密碼管理器嗎？
不行。DropLock 是臨時傳輸管道，沒有過期控制、沒有存取日誌、未經專業審計，也無法長期管理金鑰。長期存放與團隊共用金鑰，請使用正規的密碼管理器；DropLock 只負責「把敏感文字安全地傳一次」。
私鑰會被伺服器拿到嗎？
正常情況下不會。私鑰以不可匯出的 CryptoKey 形式保存在產生鎖盒的那個瀏覽器裡，加密與解密都在本地完成。密文則放在網址片段 #m= 中，瀏覽器不會把這段送給伺服器。不過要留意中間人攻擊與主機信任風險，重要資料建議跨管道核對連結，或乾脆自架。
換一台裝置可以解開別人傳來的密文嗎？
通常不行。私鑰綁定在當初產生鎖盒的瀏覽器環境，換裝置或換瀏覽器多半解不開，必須回到原本那台裝置操作。這是它設計上的取捨，使用前要先確認解密要在哪台裝置上進行。
DropLock 有做安全審計嗎？
沒有。官方明確表示程式碼未經安全專家審計。雖然原始碼完全公開、可以自行審查，但它定位是輕量臨時工具，不該拿來處理極度機密、一旦外洩會造成重大損失的資料。
結語：什麼時候該把 DropLock 放進你的工具箱
說到底，DropLock 不是要取代你手上的密碼管理器，而是補上「臨時把敏感文字安全交給某一個人」這個缺口。當你需要傳一支 API Key、一段 Webhook Secret 或一次性密碼，又不想讓明文躺在聊天紀錄或郵件裡，它的逆向鎖盒設計加上端到端加密，讓伺服器在正常流程裡全程不碰明文，是個輕巧又能自己審查的選擇，前提是你信任提供頁面的那台主機，或乾脆自己架。
它的核心價值在「夠輕、夠透明」：一個靜態頁面、開源可審查、能自己架。想強化整體網站安全，我們也介紹過 Security Header Scanner 網站安全掃描、WordPress 安全性強化技巧，以及 Cloudflare CDN 與 HTTPS 防護、Cloudflare Turnstile 驗證碼 這類工具。想再往連線隱私推進，ExpressVPN、Ivacy VPN、Mozilla VPN 等服務能加密你的上網路徑，也可以看看 VPN 還能幫上什麼忙。
如果你正好有臨時傳密的需求，不妨直接打開DropLock 官方 demo試一次，感受一下「伺服器不碰明文」是什麼體驗；要傳高機密內容，記得拉原始碼自架。覺得實用的話，也歡迎分享給常需要交接金鑰的同事，或到我們的粉絲專頁聊聊你平常都怎麼安全地傳遞敏感資料。
