Điểm:7

Chúng ta có thể chọn khóa nào là riêng tư hoặc công khai trong mã hóa bất đối xứng không? Các khóa có thực sự mã hóa và giải mã một văn bản mật mã không?

lá cờ in

Bạn có thể giúp tôi hiểu rõ hơn về cách thức hoạt động của cặp khóa trong mã hóa Bất đối xứng không?

Trước tiên, tôi đang nghiên cứu mật mã ở cấp độ bề mặt. Trong khi đọc nhiều văn bản và nói chuyện với đồng nghiệp, tôi vẫn không chắc chắn về hai điều.

  1. Sau khi tạo một cặp khóa, chúng tôi có thể chọn khóa nào sẽ là riêng tư hay công khai không? Giả định đầu tiên của tôi là chúng tôi có thể, nhưng sau khi đọc về các thuật toán, có vẻ như chúng tôi không thể, vì các lý do toán học về cách các khóa được tạo, do đó, chỉ một trong số các khóa có thể là riêng tư.

  2. Chúng ta có mã hóa hoặc giải mã Văn bản mật mã bằng một khóa nhất định không? Điều này có đúng về mặt kỹ thuật để nói như vậy không? Hoặc có thể đây chỉ là một loại quy trình xác minh và thuật toán là thứ làm xáo trộn một tin nhắn?

Có đúng không khi nói rằng:

Có cặp khóa này, tôi có thể mã hóa một tin nhắn bằng khóa riêng của mình và sau đó xuất bản nó. Việc bất kỳ ai cũng có thể giải mã tin nhắn bằng khóa chung của tôi có nghĩa là tôi đã mã hóa nó bằng khóa riêng của mình, điều đó có nghĩa là chính tôi là người đã tạo tin nhắn, vì chỉ có tôi mới có khóa riêng của mình. Mã hóa dữ liệu bằng khóa riêng của người gửi, chúng tôi gọi là định dạng tin nhắn mở, bởi vì bất kỳ ai có bản sao của khóa chung tương ứng đều có thể giải mã tin nhắn.

DannyNiu avatar
lá cờ vu
Tôi đã thu thập câu hỏi này trong [danh sách đọc](https://crypto.meta.stackexchange.com/a/1523/36960) của chúng tôi, hy vọng bạn không phiền.
Tomasz Nazarenko avatar
lá cờ in
Ngoài ra, có một câu hỏi từ Security Stack Exchange đã giúp tôi có ý tưởng. Tôi đang dán liên kết, vì ai đó có thể thấy nó hữu ích https://security.stackexchange.com/questions/81760/what-happens-when-encrypting-with-private-key
lá cờ mx
Trích dẫn ở cuối câu hỏi thiếu bất kỳ ngữ cảnh nào. Nó nói, "cặp khóa này", nhưng chúng tôi không biết nó đang nói về cặp khóa nào. Vì vậy, không có cách nào chúng tôi có thể biết liệu tuyên bố được đưa ra có đúng với bất kỳ cặp khóa nào mà nó đề cập đến hay không. Nó có thể hoặc có thể không. Làm thế nào chúng ta có thể biết?
jjj avatar
lá cờ cn
jjj
Nói chung, cả hai khóa có thể có dạng khác nhau (như với các đường cong elip, điểm và số), vì vậy chúng có thể hoán đổi cho nhau. Bạn có thể tham khảo RSA (nơi chúng có thể được hoán đổi), vui lòng thêm thẻ này vào câu hỏi của bạn.
Điểm:21
lá cờ vu

Không không không! Bạn không thể chọn khóa nào là riêng tư và khóa nào là công khai. Cảm giác tự do sai lầm đó là do

  1. mọi người không hiểu rằng mật mã khóa công khai về mặt khái niệm khác với mật mã và
  2. thuật toán khóa công khai phổ biến nhất RSA là một hoán vị phỏng đoán.

Ví dụ, với logarit rời rạc, khóa riêng của bạn luôn là số nguyên vô hướng và khóa chung của bạn luôn là nguồn. Mã hóa và trao đổi khóa được xây dựng dựa trên công thức giống như Diffie-Hellman và chữ ký số nằm ngoài các thuộc tính kết hợp và giao hoán của số học vô hướng.

Có các hệ thống mật mã khóa công khai khác (chủ yếu là hậu lượng tử) trong đó cặp khóa mã hóa/giải mã không tương thích về mặt toán học với khóa ký/xác minh của hệ thống mật mã dựa trên cùng một họ các nguyên hàm toán học.

fgrieu avatar
lá cờ ng
Ngoài ra: ngay cả trong RSA như đã được thực hiện, không có quyền tự do chọn khóa nào là khóa công khai và khóa nào là khóa riêng tư. Thông thường, một trong hai số có số mũ nhỏ (thường là 65537). Nó _phải_ là khóa công khai. Nếu đó là khóa riêng, thì khóa còn lại sẽ là khóa chung, do đó công khai, do đó kẻ thù biết được và tất cả bảo mật sẽ bị mất, vì việc tìm cả khóa và yếu tố mô đun công khai là chuyện nhỏ.
fgrieu avatar
lá cờ ng
Ngoài ra, liên quan đến Q2: khi có khóa chung và khóa riêng và có liên quan đến mã hóa, chúng tôi mã hóa bằng khóa chung và giải mã bằng khóa riêng; không có ngoại lệ. Khiếu nại ngược lại có thể gây nhầm lẫn giữa mã hóa và chữ ký: chúng tôi ký bằng khóa riêng và xác minh bằng khóa chung; cũng không có ngoại lệ.
lá cờ cn
@fgrieu Sự khác biệt là đối với RSA như thường được xác định, bạn "chỉ" phá vỡ bảo mật. Đối với nhiều PKE khác, chúng là những đối tượng hoàn toàn khác nhau và việc chuyển đổi chúng thậm chí sẽ không có ý nghĩa về mặt toán học.
fgrieu avatar
lá cờ ng
@Maeher: thực sự! Tôi đã khẳng định lại câu trả lời cho Q1 là phủ định và RSA (như thực tế) cũng không ngoại lệ.
ilkkachu avatar
lá cờ ws
@fgrieu, nhưng dùng 65537 chỉ là tùy chỉnh đúng không? Bạn có thể tạo ví dụ: chứng chỉ có số mũ mã hóa tùy ý (`openssl req -x509 -newkey rsa:4096 -pkeyopt rsa_keygen_pubexp:12345653`). Không chắc liệu một số chương trình có hoạt động ở mức đó hay không, hoặc liệu các bối cảnh khác có thực sự mã hóa cứng số mũ hay không.
fgrieu avatar
lá cờ ng
@ikkachu: vâng, bạn có thể, và hầu hết các chương trình hiện đại sẽ chấp nhận chứng chỉ và nó sẽ an toàn.Tuy nhiên, hoán đổi $e$ và $d$ sẽ không an toàn, bởi vì sau khi hoán đổi đó, vẫn dễ dàng tìm thấy $d$ (giá trị bất thường của $e$) và thừa số $n$ với khóa công khai. Điều này hoạt động với $e$ bất thường lên đến khoảng $n^{0,292\ldots}$ do [một cuộc tấn công của Boneh và Durfee](https://doi.org/10.1007/3-540-48910-X_1). Ngoài ra, openSSL sẽ chỉ đặt $e$ vào khóa riêng tư.
Điểm:10
lá cờ ar

Sau khi tạo một cặp khóa, chúng tôi có thể chọn khóa nào sẽ là riêng tư hay công khai không?

Không, nói chung chúng ta không thể. Cho hầu hết hệ thống mật mã bất đối xứng khóa riêng và khóa chung là các loại đối tượng hoàn toàn khác nhau (ví dụ: một khóa có thể là số và khóa kia là một điểm trên đường cong elip) và không có cách nào để sử dụng khóa này thay cho khóa kia.

Tuy nhiên, có một gần như ngoại lệ đáng chú ý: hệ thống mật mã RSA có khóa công khai và khóa riêng có thể được biểu diễn dưới dạng cùng một loại đối tượng (mô đun và số mũ) và được sử dụng trong cùng một phép toán (lũy thừa mô-đun) để mã hóa và giải mã tin nhắn. Cho nên, trên lý thuyết, người ta có thể tạo cặp khóa RSA "đối xứng" (như được mô tả trong câu hỏi này) rồi chọn xuất bản một nửa và giữ riêng tư một nửa.

Tuy nhiên, trên thực tế, ngay cả việc tạo khóa RSA cũng không hoạt động theo cách đó vì một số lý do:

  • Sẽ hiệu quả hơn khi chọn số mũ công khai là một số nhỏ cố định với dạng đơn giản ở dạng nhị phân. (Các lựa chọn phổ biến là 3 và 65537 = 216 + 1.) Điều này an toàn khi thực hiện đối với khóa chung, nhưng rõ ràng sẽ không an toàn nghiêm trọng đối với khóa riêng (vì số mũ là phần bí mật duy nhất của khóa riêng — mô-đun giống nhau cho cả hai nửa của khóa cặp khóa).

  • Có nhiều cách để tăng tốc hoạt động của khóa riêng RSA (nghĩa là giải mã hoặc ký) bằng cách sử dụng các thủ thuật toán học bổ sung như Định lý phần dư Trung Quốc, nhưng những điều này yêu cầu thêm thông tin về cách các khóa được tạo (chẳng hạn như các thừa số nguyên tố bí mật của mô-đun). Lưu trữ thông tin bổ sung này cùng với khóa riêng không có vấn đề gì và các định dạng khóa riêng RSA được sử dụng phổ biến nhất thực sự làm như vậy. Nhưng việc xuất bản nó sẽ cho phép bất kỳ ai phá vỡ cặp khóa và giải mã và/hoặc giả mạo tin nhắn.

Kết quả của tất cả những điều này là, trong thực tế, có thể tính khóa công khai RSA từ khóa riêng, nhưng không phải ngược lại. Như câu trả lời được liên kết (mà tôi đã viết) trên security.SE cho biết, về mặt lý thuyết, có thể tạo khóa RSA riêng an toàn mà khóa chung không thể tính được, nhưng điều này sẽ yêu cầu sử dụng cả thuật toán tạo khóa không chuẩn và thuật toán không chuẩn định dạng lưu trữ khóa riêng. Và ngay cả khi các vấn đề về định dạng đã được xử lý, không phải tất cả các triển khai RSA đều hoạt động với các khóa riêng tư đó (do thiếu thông tin bổ sung được đề cập ở trên).


Chúng ta có mã hóa hoặc giải mã Văn bản mật mã bằng một khóa nhất định không? Điều này có đúng về mặt kỹ thuật để nói như vậy không?

Sắp xếp, vâng. Nhưng những gì chúng ta thông thường làm là tạo một khóa ngẫu nhiên cho một mật mã đối xứng Như là AES, mã hóa văn bản gốc bằng mã đó, sau đó mã hóa khóa AES bằng thuật toán mã hóa bất đối xứng và khóa chung của người nhận dự định. Sau đó, chúng tôi gửi cả bản mã AES và khóa AES được mã hóa bất đối xứng cho người nhận, người này trước tiên có thể giải mã khóa AES và sau đó là bản mã.

Lý do chính cho việc sử dụng như vậy mã hóa lai là các mật mã đối xứng như AES được thiết kế để mã hóa nhiều dữ liệu một cách nhanh chóng, trong khi các hệ thống bất đối xứng thì không:

  • Mã hóa bất đối xứng có xu hướng tương đối chậm thường chậm hơn hàng chục, hàng trăm hoặc hàng nghìn lần so với mã hóa cùng một lượng dữ liệu bằng mật mã đối xứng nhanh như AES. Giải mã bất đối xứng thậm chí còn chậm hơn (trong khi giải mã AES thường nhanh như mã hóa).

  • Tất cả các sơ đồ mã hóa bất đối xứng an toàn đều tạo ra bản mã dài hơn bản rõ, do cần phải đưa một số tính ngẫu nhiên vào quy trình mã hóa để ngăn chặn các cuộc tấn công đoán. Một số (chẳng hạn như ElGamal-like lược đồ) sẽ tăng gấp đôi độ dài của văn bản gốc (sau khi đệm nó lên đến kích thước khối tin nhắn). Những thứ khác, chẳng hạn như RSA, yêu cầu đệm bản rõ lên đến hàng chục lần chiều dài ban đầu của nó. Rõ ràng, điều này là không mong muốn khi mã hóa các tập dữ liệu lớn. Trong khi đó, các mật mã đối xứng như AES thường chỉ thêm vài chục byte dữ liệu bổ sung vào bản mã bất kể độ dài của nó (tùy thuộc vào chế độ hoạt động).

  • Tổng quát hơn, các lược đồ mã hóa bất đối xứng đơn giản là không được thiết kế để mã hóa các thông điệp dài hơn vài chục byte hoặc hơn (tùy thuộc vào kích thước khóa và các tham số khác của lược đồ). Khóa AES sẽ phù hợp, nhưng ngay cả một tin nhắn trò chuyện cũng không được — và toàn bộ trang web hoặc hình ảnh hoặc luồng video chắc chắn sẽ không.

    (Về mặt kỹ thuật, giống nhau là loại đúng đối xứng mật mã khối giống như AES cũng vậy: chúng cũng mã hóa dữ liệu theo khối vài chục byte và để mã hóa các tin nhắn dài, chúng cần được sử dụng với một bộ xử lý phù hợp. phương thức hoạt động áp dụng mật mã cho từng khối dữ liệu. Nhưng có rất nhiều chế độ hoạt động của mật mã khối nhanh và an toàn có thể chứng minh được mà hầu hết phần mềm và phần cứng tiền điện tử đều hỗ trợ ngay lập tức, trong khi đối với các sơ đồ mã hóa bất đối xứng về cơ bản là không có. Và nếu bạn cố gắng tự mình thiết kế và triển khai một cái, khả năng cao là nó sẽ không hiệu quả và cũng không an toàn.)


Có đúng không khi nói rằng:

Có cặp khóa này, tôi có thể mã hóa một tin nhắn bằng khóa riêng của mình và sau đó xuất bản nó.Việc bất kỳ ai cũng có thể giải mã tin nhắn bằng khóa chung của tôi có nghĩa là tôi đã mã hóa nó bằng khóa riêng của mình, điều đó có nghĩa là chính tôi là người đã tạo tin nhắn, vì chỉ có tôi mới có khóa riêng của mình. Mã hóa dữ liệu bằng khóa riêng của người gửi, chúng tôi gọi là định dạng tin nhắn mở, bởi vì bất kỳ ai có bản sao của khóa chung tương ứng đều có thể giải mã tin nhắn.

Không thật sự lắm. Khóa riêng trong sơ đồ mã hóa bất đối xứng dùng để giải mã, trong khi khóa chung dùng để mã hóa. Bạn thường không thể mã hóa bất cứ thứ gì bằng khóa riêng, cũng như bạn không thể giải mã bằng khóa chung.

Tuy nhiên, cũng có bất đối xứng sơ đồ chữ ký số cho phép bạn dấu hiệu dữ liệu bằng khóa riêng và để thẩm tra chữ ký bằng khóa công khai, chứng minh rằng dữ liệu trên thực tế đã được ký bằng một nửa riêng tư của cùng một cặp khóa.

Một số lược đồ chữ ký số thực sự dựa trên các lược đồ mã hóa bất đối xứng. Trên thực tế, chữ ký điện tử, theo một nghĩa chung nhất định, có thể được coi là một bằng chứng không kiến ​​thức thực tế là người ký có thể giải mã một bản mã cụ thể (thường bắt nguồn từ một băm của tin nhắn được ký) bằng khóa riêng của họ bằng cách sử dụng một số sơ đồ mã hóa bất đối xứng, do đó chứng minh rằng họ có quyền truy cập vào cả tin nhắn (hoặc ít nhất là hàm băm của nó) và khóa riêng.

Đặc biệt, hệ thống mật mã RSA cũng có thể được sử dụng như một phần của sơ đồ chữ ký (chẳng hạn như RSA-PSS), sử dụng cùng loại khóa công khai và khóa riêng và cùng các phép toán (lũy thừa mô-đun) như đối với mã hóa RSA. Điều này (và những lời giải thích phổ biến ban đầu về mật mã khóa công khai) là nơi xuất phát mô tả phổ biến nhưng gây hiểu nhầm về việc ký (RSA) là "mã hóa bằng khóa riêng". Về mặt kỹ thuật thì không toàn bộ sai, ít nhất là nếu bạn bỏ qua tất cả các khác các phần của sơ đồ (băm, đệm, v.v.) ngoại trừ phép lũy thừa mô-đun ở cốt lõi của thuật toán RSA.

Nhưng nếu bạn sẵn sàng đơn giản hóa mọi thứ đến mức đó, bạn cũng có thể lưu ý rằng cả hai Mã hóa và giải mã RSA (cũng như xác minh chữ ký và chữ ký) về cơ bản chỉ là các phép lũy thừa mô-đun, vì vậy bạn cũng có thể nói rằng chúng tất cả các điều tương tự và việc ký RSA đó thực sự chỉ là giải mã RSA được áp dụng cho một bản mã đặc biệt. Theo một cách nào đó, điều này cũng đúng về mặt kỹ thuật và có lẽ không hơn (hoặc ít) gây hiểu lầm hơn là mô tả nó là "mã hóa bằng khóa riêng".

Điểm:8
lá cờ in

Trong mã hóa và giải mã RSA là tương tự nhau. Nếu bạn chọn e một cách ngẫu nhiên và tính toán khớp d thì bạn có thể chọn hoán đổi vai trò của chúng và chọn một trong hai làm khóa chung.

Thông thường chúng tôi không làm điều này, chúng tôi chọn một số mũ công khai nhỏ với một số bit được đặt. Điều này làm cho hoạt động khóa công khai nhanh hơn nhiều. Chúng tôi không thể hoán đổi vai trò và làm cho hoạt động của khóa riêng nhanh hơn trong trường hợp này vì có ít tùy chọn cho các số mũ nhỏ như vậy. Vì vậy, khóa nhỏ phải là khóa chung chứ không phải khóa riêng.

Điểm:6
lá cờ xk

Các câu trả lời hiện có từ DannyNiu và Meir Maor giải đáp tốt sự nhầm lẫn về việc khóa riêng và khóa chung có thể hoán đổi cho nhau hay không. Nhưng tôi nghĩ cũng đáng để giải quyết đoạn trích này từ câu hỏi:

Có cặp khóa này, tôi có thể mã hóa một tin nhắn bằng khóa riêng của mình và sau đó xuất bản nó. Việc bất kỳ ai cũng có thể giải mã tin nhắn bằng khóa chung của tôi có nghĩa là tôi đã mã hóa nó bằng khóa riêng của mình, điều đó có nghĩa là chính tôi là người đã tạo tin nhắn, vì chỉ có tôi mới có khóa riêng của mình. Mã hóa dữ liệu bằng khóa riêng của người gửi, chúng tôi gọi là định dạng tin nhắn mở, bởi vì bất kỳ ai có bản sao của khóa chung tương ứng đều có thể giải mã tin nhắn.

Không, điều này là rất sai! Cách mã hóa thông thường được sử dụng như sau:

  1. Tôi xuất bản khóa công khai của mình và giữ bí mật khóa riêng của mình.
  2. Bạn quyết định gửi tin nhắn cho tôi. Bạn sử dụng khóa chung của tôi để mã hóa tin nhắn của bạn; bạn gửi tin nhắn được mã hóa cho tôi.
  3. Tôi sử dụng khóa riêng của mình để giải mã tin nhắn để tôi có thể đọc nó.

Lời hứa mà mã hóa đưa ra là sau bước 2, bạn có thể gửi tin nhắn được mã hóa cho bất kỳ ai bạn muốn. Bất kỳ ai không phải là tôi (và do đó không có khóa riêng tư của tôi) sẽ chỉ nhận được rác có vẻ ngẫu nhiên; không có cách nào để họ tìm hiểu bất kỳ thuộc tính không cần thiết nào của thông điệp gốc, không được mã hóa.

Quan trọng, những lời hứa mã hóa cơ bản nhất làm không phải cung cấp bất kỳ đảm bảo về xuất xứ. Nếu Joe đưa cho tôi một tin nhắn được mã hóa và nói rằng nó được gửi từ Bob, tôi không có cách nào để kiểm tra xem nó có thực sự được gửi từ Bob hay không và ngay cả khi đó là từ Bob, tôi cũng không có cách nào để kiểm tra xem tin nhắn đó có bị sửa đổi hay không. (Ví dụ: nếu Joe biết rằng thông báo có nội dung "Bob muốn chuyển \$XXXXX từ tài khoản của Bob sang tài khoản của Joe", trong một số sơ đồ mã hóa, Joe có thể thay đổi thông báo thành "Bob muốn chuyển \$99999 từ tài khoản của Bob sang tài khoản của Joe", mặc dù Joe không thể biết XXXXX ban đầu là gì.)

tách rời các thuật toán có thể đảm bảo nguồn gốc, được gọi là chữ ký số. Trong chữ ký điện tử, cách sử dụng bình thường diễn ra như sau:

  1. Tôi xuất bản khóa công khai của mình và giữ bí mật khóa riêng của mình.
  2. Tôi quyết định muốn chứng minh với bạn rằng tôi tán thành một thông điệp. Tôi sử dụng khóa riêng của mình để ký tin nhắn và gửi chữ ký (và tin nhắn) cho bạn.
  3. Bạn sử dụng khóa công khai của tôi để xác minh rằng tôi đã tạo chữ ký và chữ ký đó là về thông điệp đã cho.

Lời hứa mà chữ ký đưa ra là sau bước 2, tôi có thể đưa chữ ký của mình cho bất kỳ ai tôi muốn. Bất kỳ ai không phải là tôi (và do đó không có khóa riêng tư của tôi) sẽ không thể sử dụng khóa đó để tạo chữ ký cho bất kỳ thư nào khác thay mặt tôi chỉ từ thông tin họ học được trong chữ ký này.

Kép cho các cuộc thảo luận ở trên về những điều không phải được hứa hẹn bằng mã hóa, có những thứ không phải hứa hẹn bằng chữ ký. Ví dụ: một chữ ký có thể tiết lộ thông tin không cần thiết về thông điệp mà nó áp dụng, do đó, nó không hứa hẹn tính bí mật như mã hóa. Vì vậy, mã hóa và ký là các kỹ thuật bổ sung.

...và tất nhiên, có nhiều thuật toán phức tạp hơn đưa ra những lời hứa phức tạp hơn, bao gồm cả việc hứa hẹn sự kết hợp giữa tính bí mật mà bạn nhận được từ mã hóa và tính toàn vẹn/xuất xứ mà bạn nhận được từ chữ ký.

AnoE avatar
lá cờ ws
Tôi hoàn toàn không hiểu điểm bạn đang thực hiện.Đoạn mã bạn trích dẫn từ OP dường như nêu chính xác khía cạnh chữ ký của mật mã khóa công khai (có thể với sự tối ưu hóa nhỏ mà người ta thường quyết định chỉ ký một hàm băm của tin nhắn thay vì chính tin nhắn đó; nhưng về mặt kỹ thuật/mật mã thì kết quả cuối cùng sẽ giống nhau). Bạn có thể chỉ định thêm một chút phần nào của khối được trích dẫn là phần không chính xác không?
lá cờ xk
@AnoE Khối được trích dẫn nói về việc mã hóa và giải mã một tin nhắn, không ký và xác minh chữ ký; đây là sai lầm chính. Đó không chỉ là sự khác biệt về thuật ngữ, như đã thảo luận trong câu trả lời của tôi: chữ ký không hứa hẹn một trong hai hướng về thông tin họ đang ký, thông tin có thể được khôi phục cũng như không thể, vì vậy hãy nói về việc khôi phục tin nhắn từ chữ ký sử dụng khóa chung không có ý nghĩa.
AnoE avatar
lá cờ ws
Bản thân mỗi câu của khối được trích dẫn đều có ý nghĩa và không có câu nào mâu thuẫn với nhau. Anh ấy thua tôi một chút ở "định dạng tin nhắn mở" (mặc dù đó có thể là vấn đề ngôn ngữ - tôi đoán anh ấy chỉ muốn nói rằng bản mã được gửi công khai, điều này khá hiển nhiên). Và rõ ràng là không cái nào trong số đó có bất kỳ khả năng ứng dụng thực tế nào, nhưng như anh ấy đã nói, anh ấy đang xem xét những cơ sở lý thuyết đầu tiên. Nhưng về mặt quan niệm nó có vẻ tốt với tôi. Trả lời "Không, điều này rất sai!" hình như hơi xa vời...
lá cờ xk
@AnoE "Tôi có thể mã hóa một tin nhắn bằng khóa riêng của mình và sau đó xuất bản nó" nói chung là không chính xác: trong nhiều (hầu hết) sơ đồ mã hóa, khóa riêng không có dữ liệu phù hợp bên trong để mã hóa. "bất kỳ ai cũng có thể giải mã tin nhắn bằng khóa chung của tôi" là không chính xác vì một lý do tương tự. "Chắc hẳn tôi là người đã gửi tin nhắn, vì chỉ tôi mới có khóa riêng của mình" là không chính xác vì mã hóa không đưa ra lời hứa về nguồn gốc. "bất kỳ ai có bản sao của khóa chung tương ứng đều có thể giải mã tin nhắn" là không chính xác vì lý do tương tự "bất kỳ ai cũng có thể giải mã tin nhắn bằng khóa chung của tôi".
lá cờ xk
@AnoE Nói cách khác, trái ngược với "bản thân mỗi câu đều có nghĩa" của bạn, *mỗi câu đều có lỗi* và một số câu còn nhiều hơn thế.

Đă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.