Confidex
Làm thế nào một máy chủ có thể lưu trữ và đồng bộ hóa các bí mật của chúng ta mà không cần giữ chìa khóa để đọc chúng? Chúng ta sẽ theo dõi cách Confidex tạo khóa, bảo vệ chúng trong ổ khóa và sử dụng chúng để mã hóa dữ liệu cũng như xác minh các thay đổi.
Khóa
Chỉ Người Được Chọn mới có thể mở cánh cửa
Ma trận được tải lại
Hãy tưởng tượng rằng chúng ta đang xây dựng một vault ảo để lưu trữ dữ liệu bí mật. Nó phải giữ dữ liệu đó trên máy tính xách tay sau khi đóng ứng dụng và để chúng tôi mở nó trên một thiết bị khác. Kho tiền sẽ cần có chìa khóa riêng. Chúng ta phải lưu trữ chúng sao cho việc sao chép các tập tin sẽ khiến người ngoài không thể đọc hoặc thay đổi nội dung của chúng.
lock bảo vệ các khóa: một tệp được mã hóa nhỏ. Để mở nó cần có mật khẩu chính và mã bí mật, secret_key; cũng không có trong chính tập tin đó. Chúng ta có thể in toàn bộ ổ khóa trên tờ báo buổi sáng. Người đọc sẽ nhận được một bản sao, nhưng việc xuất bản nó sẽ không tiết lộ khóa riêng.
Giả sử một người ngoài lấy được tập tin này và thậm chí biết được mật khẩu chính. Giờ đây, họ có thể lặp lại mọi phép tính chỉ cần mật khẩu, nhưng những phép tính đó sẽ không tạo ra chìa khóa mở ổ khóa: secret_key cũng là đầu vào. Tệp này không chứa phần kiểm tra mật khẩu riêng biệt. Mở nó vẫn yêu cầu mã bí mật không xác định.
Mã đó đến từ dữ liệu ngẫu nhiên bằng mật mã; một người không phát minh ra nó. Miễn là không xác định được secret_key, ngay cả mật khẩu chính được đoán đúng cũng không mở được khóa: kẻ tấn công vẫn thiếu một bí mật ngẫu nhiên. Do đó, chỉ một mật khẩu yếu không biến bản sao máy chủ thành một cuộc tấn công từ điển thực tế.
Nếu kẻ tấn công cũng lấy được secret_key, chúng có thể kiểm tra việc đoán mật khẩu chính ngoại tuyến. Việc này tốn kém nhưng độ khó cuối cùng phụ thuộc vào độ mạnh của mật khẩu.
Khóa
Thưa quý vị, chìa khóa có tác dụng gì? Chìa khóa… mở khóa mọi thứ?
Cướp biển vùng Caribe – Chiếc rương của người chết
Ứng dụng thu được 32 byte ngẫu nhiên từ trình tạo mật mã của hệ điều hành và chuẩn bị chúng để sử dụng làm khóa. Các byte được chuẩn bị này là khóa chính riêng, master_key.
Ứng dụng luôn lấy các khóa giống nhau từ master_key: việc lặp lại các phép tính giống nhau trên cùng một byte sẽ cho cùng một kết quả. Do đó, máy tính xách tay và điện thoại có thể khôi phục các khóa giống hệt nhau. Để lấy được master_key trên thiết bị mới, trước tiên ứng dụng phải mở khóa bằng mật khẩu chính và secret_key.
Cặp đầu tiên: mã hóa
Tôi là Người quản lý bàn phím.
phim ma
Để lưu trữ dữ liệu được mã hóa, ứng dụng sẽ tính khóa chung từ master_key: secret_key. Nó có thể mã hóa dữ liệu cho vault, trong khi việc giải mã yêu cầu master_key.
“Công khai” mô tả vai trò của khóa này trong thuật toán chứ không phải nghĩa vụ phải cung cấp nó cho mọi người. Trong Confidex nó vẫn thuộc về người dùng. Đây cũng là bí mật thứ hai cần thiết để mở khóa, vì vậy nó vẫn ở cục bộ và không được gửi qua mạng. Về bản chất, secret_key cho phép ai đó mã hóa dữ liệu cho vault nhưng không giải mã hoặc thay mặt nó ký các thay đổi.
X25519 là thuật toán lấy master_key và tính toán secret_key. Việc khôi phục master_key từ secret_key thực tế là không khả thi. Một cuộc tấn công cổ điển vào một siêu máy tính tưởng tượng thực hiện một tỷ tỷ thao tác đường cong mỗi giây sẽ mất trung bình khoảng 2,3 nghìn tỷ năm (ước tính của SafeCurves).
Cặp thứ hai: chữ ký
Điều duy nhất nguyên bản là chữ ký
Hãy bắt tôi nếu bạn có thể
Cặp đầu tiên giúp ẩn nội dung. Bây giờ chúng ta cần một cách để xác nhận rằng chủ sở hữu vault đã cho phép thay đổi. Máy chủ cũng phải có khả năng kiểm tra chữ ký, vì vậy chúng tôi cần gửi cho nó một khóa xác minh công khai. Phần công khai của cặp đầu tiên là secret_key mà máy chủ không được nhận. Do đó, chúng tôi tạo cặp khóa vĩnh viễn thứ hai cho chữ ký.
Thay vì lưu trữ một bí mật độc lập khác, chúng tôi lấy khóa ký riêng tư từ master_key và gọi nó là signing_key. Ứng dụng sử dụng nó để ký dữ liệu và khóa. Các thiết bị khác và máy chủ sử dụng phần công khai của nó để kiểm tra chữ ký mà không cần đọc nội dung.
Chúng tôi có thể khôi phục cặp này từ cùng một master_key. Ứng dụng lấy giá trị bắt đầu từ nó: 32 byte xác định duy nhất khóa ký.
Để lấy các khóa khác nhau cho các công việc khác nhau, chúng tôi đưa nhãn cố định vào phép tính: ở đây, confidex/vault/ed25519/v1. Cùng một master_key và cùng một nhãn luôn tạo ra cùng một khóa.
Mật khẩu chính chưa được nhập vào các tính toán này. Cả hai cặp đều phụ thuộc vào byte ngẫu nhiên của master_key, không phụ thuộc vào chuỗi do một người phát minh ra. Sự khác biệt này sẽ quan trọng sau này: mật khẩu sẽ bảo vệ quyền truy cập vào các khóa đã tồn tại, vì vậy chúng tôi có thể thay đổi mật khẩu mà không cần tự thay đổi khóa.
Đạo hàm sử dụng hàm dẫn xuất khóa dựa trên hàm băm: HKDF, HMAC-based Extract-and-Expand Key Derivation Function. Confidex sử dụng nó với SHA-256, do đó có tên HKDF-SHA256. 32 byte kết quả là seed cho cặp Ed25519. Phần công khai của signing_key không tiết lộ secret_key nên chúng tôi có thể gửi nó đến máy chủ để xác minh chữ ký.
Tệp khóa là gì và nó có tác dụng gì?
Mở cửa khoang khoang ra, HAL.
Một cuộc phiêu lưu không gian
Tôi xin lỗi, Dave. Tôi e rằng tôi không thể làm được điều đó.
Khóa lưu trữ master_key được mã hóa. Mở nó yêu cầu mật khẩu chính và secret_key. Tiêu đề công khai chứa phiên bản định dạng, mã định danh vault, phần công khai của signing_key, muối và các tham số xử lý mật khẩu. Phiên bản định dạng nội bộ được mã hóa cùng với master_key.
Khi tạo khóa, ứng dụng đã có sẵn master_key nên sẽ tính toán secret_key trước khi mã hóa. Khi mở nó, người dùng cung cấp riêng secret_key: nó không có trong bản sao công khai của khóa.
Sau khi giải mã, ứng dụng tính toán phần công khai của master_key bằng cách sử dụng X25519 và yêu cầu nó khớp với secret_key. Sau đó, nó khôi phục signing_key và so sánh phần công khai của nó với khóa trong tiêu đề. Bằng cách này, khóa sẽ tự kiểm tra.
Để làm chậm quá trình đoán mật khẩu chính, mỗi lần thử phải tốn thời gian và bộ nhớ. Confidex sử dụng Argon2id với 64 MiB bộ nhớ và ba lượt. Xử lý mật khẩu cũng sử dụng muối ngẫu nhiên. Muối không phải là bí mật: nó làm cho cùng một mật khẩu tạo ra các kết quả khác nhau ở các ổ khóa khác nhau.
Nếu secret_key đã được biết thì độ dài mật khẩu sẽ thay đổi đáng kể quy mô của cuộc tấn công. Có khoảng 12 triệu sự kết hợp của 5 chữ cái Latinh viết thường ngẫu nhiên, khoảng 8 tỷ chữ cái 7 và khoảng 9,5 × 10¹⁶ chữ cái 12. Việc chuyển từ 7 lên 12 chữ cái sẽ tăng không gian tìm kiếm lên gần 12 triệu lần. Nếu tìm kiếm 7 chữ cái trung bình mất một ngày trên một máy nhất định, thì chữ 5 sẽ mất khoảng hai phút và chữ 12 mất khoảng 33.000 năm.
Để lấy một khóa từ kết quả Argon2id và secret_key, chúng ta sử dụng hàm HKDF-SHA256 được giới thiệu trước đó, với nhãn confidex/lock/wrap/v1. Kết quả là wrapping_key, chìa khóa mã hóa ổ khóa.
Chúng ta phải ẩn master_key và bảo vệ nó khỏi bị giả mạo. XChaCha20-Poly1305 mã hóa nó bằng wrapping_key và thêm thẻ xác thực. Thẻ liên kết văn bản mã hóa với tiêu đề chung: mật khẩu sai hoặc thay đổi đối với byte được bảo vệ khiến việc mở không thành công. Thẻ và giá trị sử dụng một lần ngẫu nhiên, nonce, được lưu trữ cùng với văn bản mã hóa.
Mỗi khi khóa được tạo hoặc mã hóa lại, ứng dụng sẽ nhận được muối mới và nonce. Nội dung được mã hóa bao gồm một byte phiên bản và 32 byte của master_key; một nonce 24 byte và thẻ 16 byte được lưu trữ cùng với chúng. tài liệu về thuật toán mô tả cấu trúc.
Sự không khớp giữa các khóa được khôi phục có thể là do khóa bị cố tình sai định dạng hoặc do lỗi trong chương trình tạo ra khóa đó. Lỗi byte ngẫu nhiên thường được phát hiện sớm hơn khi thẻ được kiểm tra.
Máy chủ không có bí mật cần thiết để kiểm tra thẻ này. Do đó, để chuyển khóa, ứng dụng sẽ thêm chữ ký được tạo bằng signing_key. Nó bao gồm toàn bộ tệp đã hoàn thành, bao gồm tiêu đề công khai và nội dung được mã hóa. Máy chủ kiểm tra chữ ký và trong lần tải lên đầu tiên, ghim toàn bộ phần công khai của signing_key và mã định danh vault nội bộ. Nó kiểm tra các thay đổi tiếp theo đối với khóa này. Khóa và dữ liệu mã hóa được ký bằng cùng một signing_key, được khôi phục từ master_key.
Kho tiền
Bây giờ chúng ta có thể xuất bản khóa. Chỉ những người biết secret_key và master password mới có thể đọc master_key, trong khi bất kỳ ai cũng có thể lấy khóa ký công khai từ tệp khóa và kiểm tra dữ liệu đã ký mà không cần xem nội dung của khóa hoặc dữ liệu.
Hãy xem xét mật khẩu, SuperPa55worD. Hiện tại, chúng tôi chỉ muốn lưu nó: sau khi đóng ứng dụng, chúng tôi có thể gửi tệp khóa và mật khẩu được mã hóa đến bất kỳ đâu mà không ai nhìn thấy SuperPa55worD, trong khi vẫn cho phép họ xác minh quyền tác giả của chúng tôi. Quá trình mã hóa phải đảo ngược được khi chúng ta có secret_key và master password. Mật mã đối xứng có thể mã hóa và giải mã bằng cùng một khóa. Vì chúng tôi không lưu trữ khóa đó nên chúng tôi phải có thể khôi phục nó bằng khóa. Chúng tôi sẽ gọi nó là message_key.
Chúng tôi sẽ nhận được một message_key riêng biệt cho mỗi lần mã hóa mới. Chúng ta vẫn cần thu xếp việc khôi phục nó: để khóa mở bên cạnh bản mã sẽ cho phép bất kỳ ai có bản sao đều đọc được mọi thứ.
Từ các byte ngẫu nhiên mới, ứng dụng sẽ tạo một cặp X25519 tạm thời chỉ dành cho mã hóa này: record_key. Sau đó, nó lấy phần riêng tư của record_key và khóa chung vĩnh viễn của kho tiền, secret_key, rồi tính toán bí mật chung. Một hàm riêng biệt dẫn xuất message_key từ bí mật đó; khóa này mã hóa mật khẩu của chúng tôi.
Khi đọc, ứng dụng sẽ đi theo một lộ trình khác. Nó sử dụng master_key và phần công khai của record_key. Hai khóa này tạo ra cùng một bí mật chung. Về mặt toán học, cả hai tuyến đường đều nhân cùng một điểm ban đầu trên đường cong với hai số riêng, theo một thứ tự khác nhau. Thứ tự không thay đổi kết quả. Do đó, chúng tôi có thể khôi phục khóa giải mã mà không cần giữ phần riêng tư của record_key.
Việc lấy được bí mật này từ hai khóa chung trên thực tế là không thể: cả hai tuyến đều cần khóa riêng tương ứng. Các điểm công khai không cho phép chúng tôi khôi phục một cách hiệu quả các số riêng tư đã tạo ra chúng. Thủ thuật toán học này củng cố tính bảo mật của vault. Nhưng điều đó không ngăn được ai đó đưa cho chúng tôi một căn hầm khác có gắn ổ khóa của chúng tôi.
Bây giờ chúng ta có thể lưu trữ văn bản mã hóa cùng với phần công khai của record_key. Phần riêng tư của record_key và message_key đã sử dụng không còn cần thiết cho việc đọc sau này nữa. Sau đó, ứng dụng sẽ khôi phục khóa giải mã từ master_key và phần công khai được lưu trữ của record_key. Do đó, một kho bí mật vĩnh viễn có thể giải mã nhiều giá trị được mã hóa riêng biệt, mỗi giá trị có message_key riêng được khôi phục khi cần.
Ẩn văn bản thôi chưa đủ: chúng ta còn phải phát hiện sự giả mạo khi đọc nó. Do đó, mã hóa sẽ thêm thẻ xác thực, một giá trị ngắn được kiểm tra cùng với dữ liệu được mã hóa. Nếu kiểm tra không thành công, ứng dụng sẽ từ chối kết quả. Nó không được hiển thị văn bản ngẫu nhiên hoặc bị thay đổi dưới dạng mật khẩu được giải mã thành công.
Chúng tôi đã mô tả cấu trúc trong đó một cặp bất đối xứng giúp thiết lập bí mật chung, trong khi message_key mã hóa nội dung. Điều này được gọi là Hybrid Public Key Encryption hoặc HPKE và được chỉ định trong RFC 9180. Confidex sử dụng X25519 để đồng ý về bí mật, HKDF-SHA256 để lấy khóa và ChaCha20-Poly1305 để mã hóa bằng kiểm tra tính toàn vẹn. Ở đây, HKDF lấy bí mật chung đã được thống nhất bằng cách sử dụng cặp record_key và master_key; đây là một công việc riêng biệt với việc lấy Ed25519 seed. RFC 5869 mô tả HKDF.
Đối với lần mã hóa tiếp theo, ứng dụng sẽ tạo bối cảnh record_key mới và HPKE mới. Việc sử dụng lại kết hợp message_key và nonce sẽ phá vỡ khả năng bảo vệ của mật mã. Trong Confidex, khóa và nonce được dẫn xuất bên trong HPKE, được sử dụng cho một thông báo và sau đó ngữ cảnh sẽ bị loại bỏ.
Bản thân ChaCha20 sử dụng message_key 256 bit. Để hiểu được một cuộc tấn công trực tiếp, hãy tưởng tượng một siêu máy tính hư cấu đang kiểm tra hàng tỷ tỷ ứng viên mỗi giây. Việc tìm kiếm 2²⁵⁶ khóa có thể sẽ mất khoảng 1,8 × 10⁵¹ năm. RFC 8439 mô tả thuật toán và phân tích của nó.
Một kỷ lục
Chúng ta hạnh phúc chứ?
Tiểu thuyết bột giấy
Chúng tôi đã lưu mật khẩu, nhưng việc đăng nhập vào một trang web thường yêu cầu tên người dùng và địa chỉ. Đôi khi chúng ta cần một tờ ghi chú bên cạnh chúng. Nếu chúng ta lưu trữ các giá trị này một cách riêng biệt thì ứng dụng phải bằng cách nào đó nhớ rằng chúng thuộc về nhau. Chúng ta hãy đặt những “giấy tờ” này vào một phong bì. Chúng tôi kết hợp các trường thành một bộ sưu tập và gọi nó là record.
Một bản ghi có thể chứa bất kỳ tổ hợp trường nào. Ứng dụng tập hợp chúng thành một gói, nén nó và mã hóa toàn bộ bằng cách sử dụng cấu trúc mà chúng tôi vừa mô tả. Giá trị trường, tên, loại và thẻ đều được bảo vệ. Việc thay đổi địa chỉ trang web, ngay cả khi vẫn giữ cùng một mật khẩu, sẽ tạo ra một phiên bản mới của toàn bộ bản ghi, được mã hóa bằng record_key mới.
Chuỗi băm
DỰ ÁN CỦA BẠN CÓ NÊN SỬ DỤNG BLOCKCHAIN KHÔNG? → KHÔNG
XKCD 2267
Ai đó biết secret_key có thể chuẩn bị bản ghi được mã hóa cho vault của chúng tôi. Để tránh chấp nhận nó là của chúng tôi, ứng dụng sẽ ký mọi phiên bản bản ghi bằng signing_key. Nếu không có khóa này, người ngoài không thể tạo phiên bản có chữ ký mà máy chủ và các thiết bị khác sẽ chấp nhận.
Phiên bản được mã hóa cần một số thông tin đi kèm: nó thuộc về kho lưu trữ và bản ghi nào, thời điểm nó thay đổi và phiên bản nào đứng trước nó. Điều này tạo thành tiêu đề công khai. Nó không chứa mật khẩu nhưng vẫn cần được bảo vệ: nếu không ai đó có thể thay đổi quyền sở hữu và mối quan hệ của đối tượng mà không cần chạm vào văn bản mã hóa. Ứng dụng ký các byte tiêu đề chính xác cùng với văn bản mã hóa. Thay đổi dữ liệu đã ký sẽ làm mất hiệu lực chữ ký.
Máy chủ giống như một kho chứa các bưu kiện được niêm phong. Nó nhìn thấy tiêu đề, nội dung được mã hóa và chữ ký, nhưng không nhìn thấy mật khẩu bên trong và biết rằng người nhận có tồn tại trong thành phố. Nó kiểm tra chữ ký đối với phần công khai được ghim của signing_key và quyết định có chấp nhận phiên bản mới hay không. Nó không cần mật khẩu chính, secret_key hay bất kỳ khóa riêng nào. Khi đọc, máy khách sẽ kiểm tra cùng một chữ ký, sau đó kiểm tra lại liên kết giữa nội dung và tiêu đề trong quá trình giải mã, sử dụng thẻ xác thực HPKE.
Chữ ký cũng bảo vệ các liên kết giữa các phiên bản. Hàm băm SHA-256 của byte tiêu đề và văn bản mã hóa chính xác sẽ trở thành mã định danh của phiên bản. Tiêu đề của phiên bản tiếp theo chứa mã định danh của phiên bản trước. Khi chúng tôi thay đổi mật khẩu trang web, ứng dụng sẽ tạo và ký một đối tượng mới bằng liên kết này. Đối tượng cũ và chữ ký của nó vẫn không thay đổi. Do đó, việc thay thế phiên bản tiền nhiệm trong khi vẫn giữ được chữ ký của phiên bản mới sẽ không thành công. Nếu hai thiết bị thực hiện những thay đổi độc lập thì cả hai nhánh đều tồn tại; một phiên bản hợp nhất có thể đề cập đến cả hai.
Bạn có nhớ chuỗi khối không? Đây rồi :-).
Tiêu đề công khai cho phép chúng tôi kiểm tra các liên kết mà không cần giải mã, nhưng một số thông tin vẫn hiển thị. Máy chủ biết số nhận dạng, liên kết phiên bản, thời gian thay đổi do máy khách cung cấp, số lượng trường và kích thước được mã hóa của từng giá trị trường. Mã hóa ẩn nội dung của bản ghi chứ không phải thông tin cấu trúc này.
Đồng bộ hóa
“Không phải rò rỉ dữ liệu, là bản sao lưu được phân phối miễn phí.”
Meme Internet.
Để hoạt động trên một số thiết bị, chúng ta cần chuyển lịch sử khóa và ghi lại giữa chúng. Định dạng đối tượng không thay đổi: chúng tôi chuyển các byte và chữ ký được mã hóa giống nhau được lưu trữ cục bộ.
Để chuyển thủ công, ứng dụng sẽ tạo một kho lưu trữ ZIP chứa khóa, tất cả các phiên bản bản ghi được mã hóa được lưu trữ cục bộ và danh sách tệp đã ký. Cả mật khẩu và secret_key đều không được bao gồm. Trên một thiết bị khác, trước tiên ứng dụng sẽ mở khóa, sau đó kiểm tra chữ ký, giải mã hồ sơ và khôi phục bản sao kho lưu trữ cục bộ. Quá trình nhập dành cho thiết bị chưa tồn tại kho lưu trữ này; nó không hợp nhất lịch sử với một bản sao hiện có.
Máy chủ đồng bộ trao đổi các thay đổi giữa các bản sao làm việc. Trong lần tải lên đầu tiên, nó nhận được khóa đã ký, kiểm tra chữ ký và tính toán địa chỉ vault công khai từ phần công khai của signing_key. Sau đó, nó ghi nhớ khóa này và mã định danh vault từ tiêu đề: thao tác này sẽ đăng ký vault trên máy chủ. Những thay đổi tiếp theo phải khớp với mã định danh này và mang chữ ký từ cùng một khóa.
Thiết bị mới cần có địa chỉ vault và secret_key, vì vậy ứng dụng sẽ kết hợp chúng thành mã chuyển có tổng kiểm tra. Người dùng chuyển mã này vào thiết bị và nhập riêng mật khẩu chính; chỉ có địa chỉ công cộng được gửi đến máy chủ.
Sau khi mở khóa đã tải xuống, ứng dụng sẽ so sánh các phần công khai của khóa đã khôi phục với secret_key và tiêu đề, đồng thời kiểm tra địa chỉ được tính toán với mã chuyển. Sau đó, nó lưu phần công khai đã được xác minh của signing_key để kiểm tra hồ sơ.
Trong quá trình đồng bộ hóa, ứng dụng sẽ tìm nạp các phiên bản bị thiếu và tải lên các thay đổi của nó. Máy chủ kiểm tra chữ ký và liên kết đến các phiên bản trước, lưu trữ các đối tượng được chấp nhận và chuyển chúng đến các thiết bị khác. Việc kiểm tra dữ liệu nhận được, giải mã và giải quyết xung đột đều diễn ra trên thiết bị của người dùng.
Đăng ký không yêu cầu tên, địa chỉ email hoặc mật khẩu riêng. Máy chủ nhìn thấy địa chỉ công khai, khóa xác minh chữ ký, tiêu đề công khai, kích thước đối tượng và liên kết phiên bản. Nó cũng nhìn thấy địa chỉ IP và thời gian yêu cầu. Mật khẩu chính, secret_key, khóa riêng và nội dung bản ghi văn bản gốc vẫn còn trên thiết bị của người dùng. Bất kỳ ai biết địa chỉ công cộng đều có thể tải xuống các đối tượng được mã hóa nhưng việc đọc chúng đòi hỏi phải có bí mật của người dùng.
Các bước kiểm tra này phát hiện các đối tượng giả mạo nhưng không chứng minh rằng máy chủ đã hiển thị toàn bộ lịch sử và trạng thái mới nhất của nó. Nó có thể ẩn một nhánh mà khách hàng chưa từng thấy hoặc trả về một tập dữ liệu cũ nhất quán. Chữ ký xác nhận tính xác thực của một đối tượng riêng lẻ chứ không phải tính đầy đủ của phản hồi của máy chủ. Người dùng có thể nhận thấy những thay đổi bị thiếu trên một thiết bị khác nhưng lịch sử cũ nhất quán sẽ vượt qua quá trình xác minh hash-chain.
Thay đổi mật khẩu chính
Vậy ngài có vui lòng thay đổi mật khẩu của cô ấy không?
Tin tặc (1995)
Việc thay đổi mật khẩu chính chỉ mã hóa lại khóa; master_key bên trong vẫn giữ nguyên. Do đó, hồ sơ, chữ ký của họ, secret_key và địa chỉ vault không thay đổi. Khóa mới được ký bằng cùng một signing_key.
Bản sao khóa cũ vẫn mở bằng mật khẩu cũ và cùng secret_key; việc thay đổi mật khẩu sẽ không thu hồi các khóa đã bị lộ.
Hình ảnh đầy đủ
Khóa bảo vệ master_key, message_key mã hóa bản ghi và signing_key tạo chữ ký. kho lưu trữ ZIP và máy chủ nhận các đối tượng được mã hóa có chữ ký.