Điểm:1

Nói chung, nền tảng nhắn tin e2e xử lý các thay đổi đối với cấu trúc của dữ liệu được mã hóa như thế nào?

lá cờ tz

Tôi là một giáo dân đang cố gắng hiểu sâu hơn về tiền điện tử và nhắn tin riêng tư bằng cách xây dựng một "nền tảng" nhắn tin mã hóa đầu cuối, tập trung (bằng chứng về khái niệm).

Tin nhắn được các thiết bị gửi đến "máy chủ" (chạy trên Pi của tôi trong mạng gia đình của tôi), nơi chúng được lưu trữ và từ đó người nhận có thể truy xuất chúng thông qua lệnh gọi api. Máy chủ chỉ biết mức tối thiểu để phân phối tin nhắn một cách chính xác trong khi văn bản tin nhắn được mã hóa và toàn bộ tin nhắn được ký hợp lệ.

Tôi hiện đang phải đối mặt với thách thức sau: Tôi muốn đổi tên một thuộc tính của định dạng thông báo được sử dụng bởi các ứng dụng khách (nghĩ rằng JSON: message.body â message.content). Vấn đề bây giờ là (1) tất cả các tin nhắn trước đó được lưu trữ trên máy chủ ở định dạng cũ và (2) một máy khách "cũ" có thể cố gắng nhắn tin cho một máy khách "mới", điều này buộc tôi phải giải quyết bằng cách nào đó sự không khớp này giữa các định dạng của thông điệp được truyền đạt.

Nếu các khóa riêng có sẵn cho máy chủ, đây sẽ là một vấn đề nhỏ: chỉ cần chuyển đổi tin nhắn sang định dạng tin nhắn mong muốn của người nhận. Nhưng vì tôi đang cố gắng thực sự riêng tư và các khóa riêng tư chỉ có chủ sở hữu tương ứng của chúng biết nên đây không phải là một tùy chọn. Các tin nhắn không thể được sửa đổi bởi máy chủ.

Tôi cảm thấy rằng cốt lõi của vấn đề này nằm ở một thách thức cơ bản hơn mà tôi chắc chắn rằng mọi người có nhiều khả năng hơn tôi đã đưa ra các giải pháp và tồn tại các phương pháp tiêu chuẩn hóa. Như vậy đây là câu hỏi của tôi: Nói chung, các giải pháp nhắn tin e2ee (ví dụ: tín hiệu, ma trận) xử lý các thay đổi đối với cấu trúc của dữ liệu được mã hóa như thế nào? Những cách tiếp cận nào tồn tại ngoại trừ việc cắt bỏ các phiên bản cũ và loại bỏ mọi lịch sử tin nhắn?

Tôi xin lỗi nếu câu hỏi này nghe có vẻ mơ hồ hoặc quá rộng. Tôi chỉ là một người mới cố gắng để có được bức tranh toàn cảnh.

Cảm ơn rất nhiều.

Maarten Bodewes avatar
lá cờ in
Phân tích cú pháp hoặc giải mã không khác nhau lắm: cả hai đều cần mã cụ thể. Thường được giải quyết bằng cách đặt số phiên bản vào phần văn bản gốc của thông báo (và tốt nhất là đưa số đó vào tính toán chữ ký và/hoặc thông tin AAD của mật mã được xác thực). Nếu bây giờ bạn không có số phiên bản, bạn cần nhập nó vào. Hãy xem các giao thức bảo mật vận chuyển E2E khác; họ thường sẽ có một số phiên bản như vậy.
lá cờ kr
Câu hỏi này không có chủ đề trên Crypto SE. Câu hỏi này thực sự là về thiết kế phần mềm hỗ trợ nhiều phiên bản API. Nó nên được chuyển sang SO hoặc Software Engineering SE.
Điểm:3
lá cờ ng

Đây là vấn đề CNTT chung về khả năng tương thích ngược, khó hơn do tiền điện tử.

Trong CNTT, một cách phổ biến để xử lý khả năng tương thích ngược là có trường phiên bản ở đầu cấu trúc dữ liệu, cho phép các ứng dụng quyết định xem chúng có nhận ra định dạng hay không và xử lý định dạng đó nếu có thể. Các ứng dụng mới xử lý các định dạng cũ, ít nhất là trong giai đoạn chuyển tiếp. Điều này có thể được mở rộng cho các tải trọng mật mã bằng cách để trường phiên bản rõ ràng và phần còn lại được mã hóa/xác thực theo trường phiên bản.

Khi phương thức mã hóa/xác thực không thay đổi, sẽ không có vấn đề cụ thể về tiền điện tử và các cơ chế thông thường để xử lý các cấu trúc dữ liệu phong phú mà không phá vỡ tính tương thích sẽ hoạt động (ví dụ:trong JSON, có thể thêm các trường mới mà các ứng dụng cũ sẽ bỏ qua). Trong phần tiếp theo, tôi cho rằng tiền điện tử đã thay đổi và trường phiên bản cho phép phát hiện điều đó.

Vấn đề bây giờ là (1) tất cả các tin nhắn trước đó được lưu trữ trên máy chủ ở định dạng cũ và (2) một máy khách "cũ" có thể cố gắng nhắn tin cho một máy khách "mới", điều này buộc tôi phải giải quyết bằng cách nào đó sự không khớp này giữa các định dạng của thông điệp được truyền đạt.

Nếu ứng dụng khách mới vẫn có thể giải mã định dạng cũ thì đó cũng không phải là vấn đề. Đó là con đường để đi!

Vấn đề khó thực sự là khi một khách hàng "mới" gửi tin nhắn. Có nhiều sự lựa chọn, không cái nào là hoàn hảo. Một trong sô đo:

  • Khách hàng mới luôn sử dụng định dạng mới mà khách hàng cũ sẽ không hiểu.
  • Khách hàng mới sử dụng định dạng cũ cho đến khi kích hoạt nào đó (ngày chuyển đổi, tin nhắn từ máy chủ) thì sử dụng định dạng mới. Các ứng dụng khách cũ sẽ không thể sử dụng được sau khi chuyển đổi và các ứng dụng khách mới sẽ không tận hưởng các tính năng mới của định dạng mới cho đến sự kiện đó.
  • Khách hàng mới sử dụng định dạng mới sau khi kích hoạt hoặc nếu có manh mối nào đó thì người nhận (hoặc tất cả người nhận) hiểu nó, ví dụ: bởi vì ứng dụng khách gửi đã nhận được một tin nhắn xác thực từ (tất cả) (những) người nhận cho biết hỗ trợ định dạng mới, có lẽ hoàn toàn bằng cách sử dụng nó.
  • Máy khách mới tạo cả hai định dạng cho đến khi trình kích hoạt và gửi cả hai đến máy chủ, nơi lưu trữ chúng; các máy khách cũ tìm nạp định dạng cũ, các máy khách mới tìm nạp định dạng mới và trong trường hợp không thành công, tìm nạp định dạng cũ. Máy chủ phải xử lý các yêu cầu ở cả hai định dạng và cần thêm dung lượng cũng như lưu lượng truy cập nhiều hơn trong khoảng thời gian chuyển tiếp.
korolev avatar
lá cờ tz
Câu trả lời rất rõ ràng. Cảm ơn rất nhiều.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.