Cơ sở kiến thức

Mã hóa đầu cuối

Khóa OpenPGP được tạo ngay trong trình duyệt của bạn. Thư bạn gửi tới một địa chỉ OpenEmail khác có thể được niêm phong trước khi rời khỏi tab, và thư niêm phong gửi cho bạn mở ra ngay trong khung đọc, được giải mã trên máy của bạn. Khóa không bao giờ là của chúng tôi để mà giao nộp.

Chi tiết

Cả hai nửa đều đã được đấu nối đầu cuối. Soạn thư tới một người nhận đã công bố khóa sẽ niêm phong phần nội dung ngay trong trình duyệt trước khi yêu cầu rời đi; máy chủ nhận được một khối armour mà nó không đọc được, đánh dấu nó là pgp-mime, và dựng một thư multipart/encrypted thực thụ. Việc đọc chạy đúng như vậy theo chiều ngược lại: bản mã được tải về, giải mã ngay trong tab, và hiển thị như thư thường.
Thuật toán là thứ mà mọi người khác vốn đã dùng: OpenPGP, thông qua openpgp.js, và PGP/MIME trên đường truyền. Một khóa v4 trên Curve25519, đúng dạng mà Proton cấp và gpg tạo ra với thuật toán hiện đại mặc định của nó. Nên về nguyên tắc thư mà phần này đọc chính là thư mà Thunderbird, gpg và Proton tạo ra, và không có gì ở đây là một định dạng riêng của chúng tôi để rồi phải gỡ ra về sau.
Tuy nhiên trên thực tế thì nó là OpenEmail gửi cho OpenEmail. Trong mã nguồn này không có Web Key Directory, không có tra cứu keyserver và không có phân tích header Autocrypt ở bất cứ đâu: nơi duy nhất từng tìm ra khóa của người nhận là thư mục của chính chúng tôi, nơi giữ các khóa được công bố từ ứng dụng này bởi những người có địa chỉ trên một tên miền được lưu trữ ở đây. Cũng không có cách nào để trao khóa của bạn ra ngoài. Ứng dụng công bố nửa công khai của bạn vào thư mục đó và không cung cấp bản sao hay xuất khóa, nên một người liên hệ dùng Thunderbird không có cách nào được hỗ trợ để lấy nó. Khả năng tương tác với thế giới PGP rộng lớn là một thuộc tính của định dạng, chưa phải điều sản phẩm làm giúp bạn.
Việc đọc thì không bị giới hạn như vậy, bởi giải mã không cần tới thư mục. Bất kỳ thư PGP/MIME hay PGP nội tuyến nào tới hộp thư này mà được niêm phong tới một khóa có trong trình duyệt này đều mở được, bất kể ai gửi và họ dùng trình đọc nào. Điều đó bao gồm cả những thư niêm phong tới khóa mà bạn đã xoay vòng bỏ đi: các khóa nghỉ hưu vẫn nằm trong keyring và được thử cùng với khóa hiện hành, nên xoay khóa không khiến bạn mất đi số thư đã nhận.
Màu xanh nghĩa là đã mở được, và không có cách nào khác để đạt tới nó. Hàng Details → Security chỉ chuyển xanh sau khi một lần giải mã thực sự trả về văn bản thuần trong tab này, không bao giờ từ một trường trên thư, không bao giờ từ việc một phong bì mã hóa đã tới. Nó ghi “Encrypted end-to-end. Opened with your key in this browser”. Mọi trạng thái chưa đạt tới đó đều có câu chữ riêng chứ không dùng chung một câu: đang tìm, khóa đang bị khóa, niêm phong tới một khóa mà trình duyệt này không có, không mở được, hoàn toàn không có khóa nào ở đây, và trình duyệt này không cho chúng tôi kiểm tra. “We could not check” và “you do not have the key” là hai phát biểu khác nhau và hàng đó buộc bạn phải đọc xem mình nhận được cái nào.
S/MIME vẫn chưa mở được. Nó là CMS dưới một chứng chỉ X.509, openpgp.js không đụng tới được, và trong sản phẩm cũng không có kho chứng chỉ để giữ khóa kể cả nếu có thể, nên một thư S/MIME sẽ nói rằng OpenEmail không mở được nó, và không được mời mở khóa một thứ chẳng có tác dụng gì.
Nửa khóa riêng tư được tạo ra trong trình duyệt của bạn và không bao giờ rời khỏi đó: không mã hóa gửi đi, không nằm trong bản sao lưu, không có trong công cụ hỗ trợ. Máy chủ không bao giờ được gửi nó, nên ở đây không có gì để giao nộp, để trát tòa đòi hay để rò rỉ. Nó được lưu ở dạng khóa bằng passphrase trong một cơ sở dữ liệu IndexedDB riêng, openemail-keyring, cố ý nằm ngoài tầm với của lời khuyên “xóa cache” và nút reset của bảng điều khiển gỡ lỗi: cả hai đều xóa query cache, và một khóa lưu cạnh đó sẽ khiến lời khuyên hỗ trợ thường ngày phá hủy vĩnh viễn mọi thư mã hóa mà tài khoản từng nhận. Xóa tài khoản thì đúng là xóa cả nó, bởi khi đó thư cũng đi theo. Mở khóa nó sẽ giữ nó trong bộ nhớ trong 15 phút không hoạt động và tối đa 8 giờ, sau đó đọc thư niêm phong tiếp theo sẽ lại hỏi passphrase.
Không có ký gửi khóa và không có khôi phục, và đó là điều vĩnh viễn chứ không phải chưa xây. Passphrase của bạn là lối vào duy nhất; quên nó thì mọi thư mà ai đó niêm phong gửi cho bạn sẽ nằm lại trên máy chủ của chúng tôi dưới dạng bản mã mà không ai đọc được, kể cả chúng tôi. Thư mất là mất, và có hỏi bao nhiêu cũng không lấy lại được. Màn hình đăng ký khóa nói điều đó trước khi khóa đầu tiên tồn tại, sau một ô tick mà bạn phải tick, và tệp sao lưu là bắt buộc, còn nút Done vẫn bị vô hiệu cho tới khi bạn tải nó về. Tệp đó được ghi mà không có lớp gia cố lưu trữ bổ sung mà trình duyệt này dùng, một cách có chủ ý, để nó vẫn nhập được vào các bản gpg cũ hơn: một bản sao lưu bạn không mở được ở nơi khác thì không phải bản sao lưu. Khóa cũng chỉ nằm trong một trình duyệt trên một thiết bị, và một chiếc điện thoại hay một máy tính thứ hai sẽ chẳng có gì cho tới khi bạn nhập tệp đó vào đó.
Thư mục chỉ giữ khóa công khai và không gì khác, và một khóa thuộc về một con người chứ không thuộc về một hộp thư, bởi khóa gắn với một địa chỉ sẽ phải được sao chép cho mọi người mà địa chỉ đó được chia sẻ cùng, tức là ký gửi khóa dưới một cái tên khác. Tra cứu một khóa cần một phiên đã đăng nhập và quyền gửi, không bao giờ là một endpoint công khai, bởi việc dò địa chỉ mở là một cỗ máy tiên tri cho bất kỳ ai biết địa chỉ nào ở đây là hộp thư đang hoạt động. Nó trả lời giống hệt nhau cho “chúng tôi không lưu trữ địa chỉ đó” và “chúng tôi lưu trữ nó nhưng chưa ai công bố khóa”, bởi phân biệt hai điều đó chỉ đẩy cỗ máy tiên tri ra sau một lớp đăng nhập chứ không loại bỏ nó. Và một khóa ngừng được trao đi ngay khoảnh khắc chủ nhân của nó mất quyền với địa chỉ, chứ không phải khi ai đó nhớ ra là phải thu hồi.
Mọi byte đều được niêm phong trong trình duyệt ngay lúc bạn viết ra, và đó chính là thứ làm cho các lần gửi trì hoãn hoạt động được: một thư đã lên lịch hoặc đang nằm trong khung hoàn tác được lưu dưới dạng bản mã và được một hàng đợi không giữ khóa nào và không đọc được gì trong đó gửi đi sau. Một người nhận mà lượt tra cứu thư mục THẤT BẠI sẽ chặn lần gửi lại thay vì bị âm thầm coi như không có khóa. Và một thư đã niêm phong chỉ đi ra qua một đường truyền mang trọn vẹn cả thư. Một đường gửi ra nhận vào một nội dung HTML thay vì thế sẽ đăng phần armor thành văn bản hiển thị rồi báo thành công, nên một lần gửi sẽ rơi vào đó bị từ chối trước khi có byte nào rời đi chứ không phải sau đó.
Việc niêm phong sẽ tốn những gì, đo đạc chứ không đoán: phần armor lớn khoảng 1,86 lần số byte thô, nên xấp xỉ 2,7 MB tệp đính kèm là vừa với mức 5 MB mà đường gửi cho phép, và trình soạn thảo từ chối một tải trọng vượt mức đó trước khi bỏ ra vài giây mã hóa một thứ mà lớp truyền tải sẽ từ chối. Thư đã mã hóa không báo cáo lượt mở và lượt bấm nào, bởi việc theo dõi theo từng người nhận hoạt động bằng cách thay đổi nội dung theo từng người mà một khối niêm phong duy nhất thì không thể thay đổi, và một liên kết bị viết lại là liên kết chúng tôi đọc được, tức là ngược lại với tuyên bố này. Một lần gửi đã mã hóa cũng không bao giờ khử trùng lặp được bằng idempotency key: một session key mới khiến bản mã là những byte khác nhau ở mỗi lần thử, nên một lần thử lại không bao giờ có dấu vân tay giống bản gốc.
Lên lịch thì niêm phong tại thời điểm soạn, không phải thời điểm gửi. Trình soạn thảo dựng bản mã theo khóa mà người nhận đang giữ vào ngày bạn viết, chứ không phải ngày thư sẽ rời đi, đúng quy tắc mà sản phẩm này đã áp dụng cho mẫu và bản dịch, nơi một thư đã lên lịch mang theo thứ bạn đã duyệt chứ không phải thứ thay đổi về sau. Khác biệt là một mẫu cũ thì chỉ lỗi thời còn một khóa cũ thì không đọc được, nên trình soạn thảo nêu rõ ngày bằng lời thay vì đưa ra một lời rào đón: “Sealed now, sent on …. Everyone on it will need the key they have today.” Lời từ chối canh giữ nửa còn lại đã có mặt nhưng chưa bao giờ kích hoạt, bởi chưa thư nào như vậy tồn tại được: nếu có, việc sửa nó sau đó sẽ bị từ chối thay vì âm thầm cho phép, vì vá phần nội dung sẽ ghi văn bản thuần đè lên bản mã và đổi người nhận sẽ đổi luôn đối tượng mà thư được niêm phong tới, và cả hai đều dẫn tới việc thư đi ở dạng phơi trần trong khi mọi màn hình vẫn gọi nó là đã mã hóa.
Có hai thứ mà trình soạn thảo hoàn toàn không cung cấp, và nó nói rõ thay vì để hỏng ở lớp truyền tải. Một mẫu được render trên máy chủ từ một phiên bản đã công bố, nên không có gì trong trình duyệt này để niêm phong. Một lượt trả lời trích dẫn cuộc hội thoại ở dưới và phần trích dẫn đó được nối vào sau khi nội dung lẽ ra đã được niêm phong, để lại một bản đọc được của cả thread nằm ngoài lớp niêm phong, nên trả lời và chuyển tiếp không thể mã hóa cho tới khi phần lịch sử trích dẫn được gấp vào bên trong bản mã.
Không có gì trong số này che giấu dòng tiêu đề, người bạn viết thư cho, hay thời điểm. Tiêu đề đi ở dạng phơi trần trên một thư đã niêm phong y như trên mọi thư khác, và khung đọc nói rõ điều đó ngay trên thư: “The subject and the addresses travelled in the clear; this text did not.” PGP bao phủ phần nội dung và không bản cài đặt nào của nó bao phủ phần còn lại. Bản nháp cũng không được niêm phong, vì tính năng tự lưu liên tục ghi văn bản thuần vào hộp thư của bạn trong lúc bạn soạn, bởi âm thầm không lưu sẽ làm mất công sức, và ổ khóa nói rõ điều đó bằng lời.
Việc nhận ra thư tới ở dạng niêm phong đến trước và vẫn còn đúng. PGP/MIME, PGP armor nội tuyến và S/MIME trước đây hiển thị thành một thư rỗng kèm hai tệp đính kèm vô nghĩa, bởi bộ phân tích chỉ coi văn bản thuần và HTML là đọc được rồi ném phần còn lại vào dải tệp. Những phần đó giờ đã được nhận diện, phần khung giao thức được giữ ra ngoài danh sách tệp đính kèm, bản mã được lưu nguyên vẹn, đó chính là thứ mà trình đọc giải mã từ đó thay vì tải thêm thứ gì mới, và một thư mà không ai ở đây mở được thì vẫn nói thẳng ra như vậy.
Một thư được ký được xử lý như một thứ riêng biệt, bởi nó đúng là như vậy. Nội dung của nó đọc được, nên tìm kiếm, quy tắc và mọi thứ khác vẫn hoạt động trên đó; nó không bao giờ bị chặn sau một ổ khóa và không bao giờ bị đưa qua giải mã. Hàng đó báo “Signed by the sender. Signature not checked”, ở dạng mờ, và nó còn mờ cho tới khi có thứ gì ở đây thực sự xác minh được chữ ký, điều mà hiện chưa có gì làm được, kể cả trên một thư đã giải mã thành công. Thấy rằng một thư đã được niêm phong không giống với việc đã mở được nó, và mở được nó cũng không giống với việc biết ai đã niêm phong nó.
Trên một thư đã mã hóa, phần nội dung bị giữ lại khỏi mọi thứ lẽ ra sẽ đọc nó: đoạn trích tìm kiếm, lượt quét nội dung của bộ chấm điểm lừa đảo, kiểm tra văn bản do AI viết, các điều kiện theo nội dung trong quy tắc, nhập lời mời lịch, và tóm tắt thread. Nửa xác thực của kiểm tra lừa đảo vẫn chạy, bởi DMARC, DKIM và SPF được đọc từ các header mà bản mã không che giấu. Việc giải mã không thay đổi điều nào trong đó. Văn bản thuần chỉ tồn tại trong tab đã mở nó, nên một thư đã niêm phong vẫn không tìm kiếm được và vẫn nằm ngoài các tính năng AI kể cả sau khi bạn đã đọc, và tính năng dịch không được cung cấp trên thư đó. Đó là cái giá của tuyên bố này, không phải một thiếu sót.