OneTimeSecret và PrivateNote: Vì sao nơi mã hóa quan trọng

Hai cách xây cùng một liên kết

Trong mã hóa phía máy chủ, người gửi gửi bí mật tới dịch vụ qua TLS. Dịch vụ nhận văn bản thuần, mã hóa nó, và lưu văn bản mã hóa. Sau đó dịch vụ có thể lưu tải trọng, chuyển nó, cho nó hết hạn và xóa nó. Máy chủ ứng dụng nằm trong quá trình mã hóa vì văn bản thuần đi vào dịch vụ trước khi trở thành văn bản mã hóa.

Trong mã hóa phía máy khách, thiết bị của người gửi mã hóa trước. Dịch vụ nhận và lưu văn bản mã hóa. Lần tải lên đó đi qua TLS. Dịch vụ không nhận khóa cần để giải mã một tải trọng tiêu chuẩn. Thiết bị của người nhận giải mã tại chỗ. Dịch vụ vẫn có thể lưu, chuyển, cho hết hạn và xóa tải trọng mà không cần truy cập văn bản thuần của nó.

Cả hai thiết kế đều có thể cung cấp liên kết tạm thời, quyền truy cập giới hạn và thời hạn. Cả hai đều có thể được mô tả chính xác là đã mã hóa. OneTimeSecret dùng kiến trúc thứ nhất; PrivateNote dùng kiến trúc thứ hai. Câu hỏi phù hợp vì vậy không chỉ là liên kết dùng một lần có được mã hóa hay không, mà là những hệ thống nào phải có quyền truy cập văn bản thuần thì liên kết đó mới hoạt động.

OneTimeSecret: mã hóa phía máy chủ

Trong luồng OneTimeSecret thông thường, người gửi gửi bí mật qua TLS. Ứng dụng nhận văn bản thuần, mã hóa nó trên máy chủ, và lưu tải trọng đã mã hóa.

Điều này bảo vệ có ý nghĩa cho dữ liệu đã lưu. Chỉ lấy được kho đã mã hóa không nhất thiết lộ nội dung khi dữ liệu cần để giải mã không có sẵn với kẻ tấn công.

Đánh đổi kiến trúc xảy ra trước khi lưu. TLS bảo vệ bí mật khi nó di chuyển giữa trình duyệt và OneTimeSecret, nhưng ứng dụng phải xử lý văn bản thuần để mã hóa nó. Máy chủ ứng dụng vì vậy nằm trong ranh giới tin cậy mật mã.

Một tiến trình ứng dụng độc hại hoặc bị xâm phạm tại thời điểm đó có thể truy cập bí mật trước khi nó được mã hóa để lưu. Mã hóa phía máy khách bỏ sự phụ thuộc cụ thể này bằng cách mã hóa bí mật trước khi nó tới dịch vụ.

Cụm mật khẩu của OneTimeSecret không đổi ranh giới mã hóa

Tài liệu của OneTimeSecret mô tả một cụm mật khẩu tùy chọn. Khi dùng cụm mật khẩu, OneTimeSecret nói rằng bí mật được mã hóa trên máy chủ của họ bằng cụm mật khẩu do người gửi cung cấp. Họ nói rằng họ không lưu chính cụm mật khẩu; thay vào đó, họ giữ một hàm băm bcrypt dùng để xác minh cụm mật khẩu lúc lấy lại. Theo tài liệu của họ, hàm băm đó tự nó không thể giải mã bí mật, và bí mật được bảo vệ bằng cụm mật khẩu đã lưu không thể giải mã nếu không có cụm mật khẩu gốc.

Việc lấy lại dùng cùng ranh giới phía máy chủ. Người nhận cung cấp cụm mật khẩu cho OneTimeSecret qua TLS. Dịch vụ xác minh nó và thực hiện giải mã trên máy chủ trước khi trả văn bản thuần.

Nghĩa là tiến trình ứng dụng có quyền truy cập bí mật và cụm mật khẩu khi mã hóa diễn ra, và lại xử lý cụm mật khẩu cùng văn bản thuần thu được trong lúc lấy lại. Một tiến trình ứng dụng độc hại hoặc bị xâm phạm hoạt động tại một trong hai điểm có thể lấy được thông tin đó. Đây là hệ quả của nơi mã hóa và giải mã chạy, không phải khẳng định rằng OneTimeSecret ghi lại hoặc lạm dụng các giá trị đó.

Tài liệu công khai của OneTimeSecret tự nó không xác lập mọi chi tiết của hệ thống khóa nội bộ—ví dụ, chính xác cách dữ liệu khóa phía máy chủ, khóa theo từng bí mật, dẫn xuất khóa và cụm mật khẩu được cung cấp được kết hợp. Không cần suy đoán các chi tiết triển khai đó cho so sánh này. Thuộc tính được ghi nhận và có liên quan là mã hóa và giải mã diễn ra phía dịch vụ.

Tự lưu trữ có thể làm việc tin máy chủ đó trở nên hợp lý

OneTimeSecret là mã nguồn mở. Một tổ chức có thể chạy phiên bản của riêng mình bên trong vành đai bảo mật doanh nghiệp, thay vì gửi bí mật tới dịch vụ công cộng.

Trong cách triển khai đó, tin máy chủ ứng dụng là tin hạ tầng mà tổ chức đã vận hành. Văn bản thuần vẫn tới máy chủ đó, vì mã hóa vẫn diễn ra ở đó. Bên kia ranh giới là các máy chủ, người vận hành và bản sao lưu của chính tổ chức. Với một nhóm đã chấp nhận các hệ thống đó là một phần đường đi của bí mật, mã hóa phía máy chủ có thể là lựa chọn hợp lý. Nó thu hẹp khoảng cách giữa mô hình đe dọa phía máy chủ và phía máy khách, vì người vận hành không còn là một dịch vụ bên ngoài.

PrivateNote mã hóa trước khi tải lên

Một ghi chú PrivateNote tiêu chuẩn được mã hóa trước khi tải lên. Trình duyệt của người gửi, hoặc một tiến trình CLI, tiện ích Chrome, tiện ích trình soạn thảo hoặc MCP tại chỗ, tạo một khóa ngẫu nhiên và mã hóa tải trọng bằng AES-256-GCM. Chỉ văn bản mã hóa được tải lên. TLS mang văn bản mã hóa đó từ trình duyệt tới worker Cloudflare của PrivateNote. Khóa giải mã được đặt trong phần đoạn URL, phần sau dấu #, ví dụ https://privatenote.ai/note/abc123#…. Phần đoạn được xử lý phía máy khách và không nằm trong yêu cầu HTTPS (RFC 3986, §3.5; Chuẩn URL). Worker nhận mã định danh ghi chú và trả văn bản mã hóa qua cùng kết nối TLS. Trình duyệt giữ phần đoạn và giải mã tại chỗ.

Cụm mật khẩu bảo vệ khóa nếu kênh của liên kết bị xâm phạm

Cụm mật khẩu trên PrivateNote làm một việc khác với cụm mật khẩu trên OneTimeSecret. Ghi chú đã là văn bản mã hóa trước khi rời thiết bị. Nếu bạn thêm cụm mật khẩu, trình duyệt dẫn xuất một khóa bọc từ nó bằng Argon2id và dùng khóa bọc đó để mã hóa khóa của ghi chú. Phần đoạn URL khi đó giữ khóa đã bọc. Người nhận cần liên kết và cụm mật khẩu. Trình duyệt mở bọc khóa tại chỗ và chỉ sau đó mới giải mã ghi chú.

PrivateNote không nhận cụm mật khẩu. Yêu cầu tạo mang văn bản mã hóa, một salt, và các tham số trình duyệt của người nhận cần để thử cụm mật khẩu tại chỗ. Không có hàm băm phía máy chủ có nhiệm vụ xác minh cụm mật khẩu. Cụm mật khẩu sai làm giải mã thất bại trên thiết bị.

Cụm mật khẩu còn bảo vệ khóa phía máy khách tại chỗ nếu kênh mang liên kết bị xâm phạm. Kênh đó khi ấy thấy một khóa đã bọc, không phải một khóa tự mở được ghi chú. Đó không phải cơ chế giữ PrivateNote ngoài đường đi của văn bản thuần. Sự tách biệt đó đã có trên ghi chú tiêu chuẩn, có hay không có cụm mật khẩu. Hãy chia sẻ cụm mật khẩu trên kênh khác với liên kết. Cùng một tin nhắn gộp hai lớp thành một — cùng quy tắc như chia sẻ mật khẩu an toàn.

Cách PrivateNote xử lý khóa được mô tả tại Cách hoạt động: khóa nội dung được bọc bằng Argon2id, và khóa đã bọc đi trong liên kết.

Giả định tin cậy còn lại với máy khách web

Mã hóa phía máy khách trên trình duyệt không phải một ứng dụng web không cần tin cậy. Mật mã có thể chạy tại chỗ trong khi JavaScript triển khai nó do trang web gửi tới. Trình duyệt tin mã nó nhận cho phiên đó.

Ai có thể sửa JavaScript đó — qua ứng dụng, một CDN, hoặc đường ống triển khai — có thể đổi máy khách và lấy khóa trong một phiên trình duyệt sau. Đó là một thất bại khác với việc đánh cắp cơ sở dữ liệu. Xâm phạm kho lưu lộ văn bản mã hóa. Việc phát mã độc tấn công điểm cuối khi khóa thực sự đang hiện diện.

Một bản sao cơ sở dữ liệu sau đó không thể tạo ra các khóa phía máy khách chưa từng được lưu ở đó. Một máy khách đang bị xâm phạm có thể tấn công các bí mật được xử lý trong phiên đó. Cùng giả định được ghi trong mô hình đe dọa của PrivateNote: mã ứng dụng được gửi tới chưa bị sửa đổi độc hại, và thiết bị của người gửi cùng người nhận được tin tại thời điểm mã hóa và giải mã.

Phần mềm đã cài đặt thu hẹp sự phụ thuộc vào một trang vừa tải xuống. CLI, tiện ích trình soạn thảo hoặc ứng dụng gốc chạy mã bạn đã cài. Các máy khách đó vẫn phụ thuộc vào hệ điều hành, chữ ký, phụ thuộc và kênh cập nhật. Công cụ cho nhà phát triển dùng cùng sự tách biệt như trình duyệt: mã hóa tại chỗ, tải văn bản mã hóa lên, để khóa trong phần đoạn.

Thời gian tồn tại và tính bí mật

Liên kết dùng một lần trả lời hai câu hỏi riêng. Tải trọng đã mã hóa nên tồn tại bao lâu? Và ai có thể giải mã nó khi nó còn tồn tại? Hủy nó sau khi lấy hoặc khi hết hạn rút ngắn cửa sổ. Việc đó không quyết định ai có thể đọc nó trong cửa sổ đó. Thời gian tồn tại và tính bí mật hỗ trợ nhau. Cái này không thay cho cái kia.

Sự phân biệt sắc nhất khi tải trọng là quyền hạn: khóa API, thông tin cơ sở dữ liệu, token đám mây, mã khôi phục, mật khẩu hạ tầng. Dịch vụ chia sẻ bí mật tồn tại vì người gửi muốn ít hệ thống hơn được giao thông tin đó. Nếu bên trung gian chỉ phải mang một đối tượng đã mã hóa không đọc được, thực thi thời hạn và xóa nó, máy chủ có thể làm việc đó mà không nhận bí mật hay khóa mở nó.

Ranh giới nằm ở đâu

“Đã mã hóa” không cho bạn biết ranh giới tin cậy nằm ở đâu. Tiêu chuẩn đáng dùng là ranh giới tin cậy tối thiểu: nguyên tắc đặc quyền tối thiểu áp dụng cho ai phải thấy văn bản thuần. Trong kỹ thuật mật mã hiện đại, mục tiêu không chỉ là tin rằng máy chủ cư xử đúng, mà là giảm sự cần thiết toán học của việc tin ngay từ đầu.

OneTimeSecret mô tả một hệ thống mã hóa phía máy chủ. Với bảo vệ bằng cụm mật khẩu, họ nói bí mật đã lưu sau đó không thể giải mã nếu không có cụm mật khẩu, và một vụ xâm phạm máy chủ sẽ để bí mật an toàn chừng nào cụm mật khẩu đó còn chưa biết. Cụm mật khẩu yếu có thể bị dò vét. Nếu nó yếu, vụ xâm phạm đó vẫn có thể để bí mật được khôi phục. Văn bản thuần và cụm mật khẩu tới OneTimeSecret lúc tạo, vì mã hóa diễn ra trên máy chủ của họ, và cụm mật khẩu được gửi lại lúc lấy để các máy chủ đó giải mã.

PrivateNote chọn một kiến trúc khác. Tải trọng được mã hóa trước khi tới dịch vụ, và khóa tải trọng tiêu chuẩn ở lại phía máy khách. Cụm mật khẩu, khi bạn đặt một cái, còn bảo vệ khóa phía máy khách đó tại chỗ nếu kênh mang liên kết bị xâm phạm. Nó không được gửi tới PrivateNote.

OneTimeSecret mã hóa bí mật của bạn. Máy khách dùng dịch vụ của PrivateNote mã hóa nó trước khi dịch vụ nhận. Sự phân biệt đó không phụ thuộc vào giả định rằng nhà cung cấp nào đó có ác ý. Nó thu câu hỏi về kiến trúc: bao nhiêu hệ thống cần quyền truy cập văn bản thuần thì dịch vụ mới hoạt động?

Câu hỏi thường gặp

Nguồn chính

Thông tin kiến trúc về OneTimeSecret được đối chiếu với tài liệu công khai của họ vào ngày 23 tháng 9 năm 2026. Cách triển khai sản phẩm và tài liệu có thể thay đổi.

• Tài liệu OneTimeSecret
• OneTimeSecret về bảo mật và cụm mật khẩu
• Mã nguồn OneTimeSecret
• Cách mã hóa PrivateNote hoạt động
• PrivateNote cho nhà phát triển, gồm CLI
• RFC 3986, mục 3.5, tách phần đoạn khỏi URI trước khi truy xuất
• Chuẩn URL, phần đoạn, về cách phía máy khách xử lý phần đoạn