Điểm:2

Chữ ký từ mã hóa bất đối xứng

lá cờ in

Để cho $(K_{enc},K_{dec})$ là một cặp khóa bất đối xứng. Đối với tôi, có vẻ như một sơ đồ chữ ký có thể được tạo bằng cách đặt khóa xác minh công khai $K_{ver}=K_{dec}$ (khóa giải mã bất đối xứng) và khóa ký bí mật được $K_{sign}=K_{enc}$ (khóa mã hóa bất đối xứng). Nói với $H$ một số hàm băm và $m$ được ký kết: $$ s=\texttt{sign}(m,K_{sign})=\texttt{encrypt}(H(m),K_{enc}) $$ $$ \texttt{verify}(s,m,K_{ver})=\left\{ \begin{array}{cc} \text{True }&\text{if } H(m)=\texttt{decrypt}(s,K_{dec})\ \text{Sai }&\text{else}. \end{mảng} \đúng. $$ Nói cách khác, một người ký bằng cách mã hóa (một hàm băm) tài liệu và bất kỳ ai cũng có thể xác minh bằng cách giải mã (và băm).

N.B. Vai trò công khai/riêng tư của các phím đang bị đảo ngược giữa các ứng dụng! $K_{sign}=K_{enc}$ được giữ kín (quên rằng nó sẽ được công khai dưới dạng khóa mã hóa) và $K_{ver}=K_{dec}$ được đặt ở chế độ công khai (quên rằng nó sẽ ở chế độ riêng tư dưới dạng khóa giải mã).

Nếu đây là trường hợp, tại sao lại phát triển các lược đồ chữ ký riêng thay vì sử dụng lại các lược đồ khóa công khai? Có vẻ như thật lãng phí nếu không tái sử dụng PKC. Các chương trình chữ ký chuyên dụng có hiệu quả hơn nhiều không?

Nếu đây không phải là trường hợp, những gì đi sai?


Một vấn đề được lưu ý trong các ý kiến ​​​​xảy ra khi $K_{dec}$ tiết lộ thông tin về $K_{enc}$. Điều này chắc chắn xảy ra trong một số (hầu hết) lược đồ, giả sử khi khóa mã hóa thực sự là một phiên bản bị xáo trộn nào đó của khóa giải mã, nhưng không phải tất cả. Ngăn chặn điều này ít nhiều là thiết kế một sơ đồ chữ ký ("giải mã khóa công khai"), khiến câu hỏi của tôi trở nên không thú vị.

Trường hợp cụ thể duy nhất xuất hiện trong đầu là chữ ký RSA, trong đó tính đối xứng giữa các số mũ mã hóa/giải mã làm cho điều trên có thể xảy ra.

knaccc avatar
lá cờ es
Trong tiền điện tử EC, khóa công khai $K_{enc}$ có thể được lấy một cách tầm thường từ khóa riêng tư $K_{dec}$. Do đó, nếu bạn đưa ra $K_{dec}$ cho công chúng, thì công chúng có thể xác định $K_{enc}$ của bạn và "chữ ký" của bạn có thể giả mạo được.
poncho avatar
lá cờ my
Nếu chúng tôi hiểu nhầm điều gì đó, có thể hữu ích nếu bạn sử dụng một số thuật toán mã hóa khóa công khai (không phải RSA) và viết ra chính xác những gì bạn đề xuất...
fgrieu avatar
lá cờ ng
Tôi đề nghị thay đổi tiêu đề của câu hỏi thành âChữ ký từ mã hóa bất đối xứng, vì chữ ký (kỹ thuật số) được coi là một phần của mật mã bất đối xứng.
Điểm:6
lá cờ ng

Tốt

Phương pháp trong câu hỏi dẫn đến một hệ thống chữ ký luôn xác minh thành công thông điệp mà nó ký; và có sự kết hợp của các lược đồ mã hóa bất đối xứng và hàm băm trong đó hệ thống chữ ký đó đáp ứng Tài sản bảo mật EUF-CMA, bao gồm:

  • RSAES-OAEP gần như thông lệ và hàm băm mật mã tiêu chuẩn như SHA-256. Tuy nhiên, cần có hai điều chỉnh đối với phần RSA:
    • Lựa chọn $e$ ngẫu nhiên và có kích thước bit lớn (bằng một nửa kích thước bit của $n$ có vẻ ổn) chứ không phải $e=65537$ như phổ biến (hoặc giá trị khác thấp hơn có thể đoán được hoặc ngẫu nhiên nhưng quá thấp để bảo mật¹ của phương thức của câu hỏi)

    • Thể hiện khóa giải mã $K_{dec}$ như $(n,d)$ thay vì như thường lệ $(n,e,d,p,q,d_p,d_q,q_\text{Inv})$, được sử dụng bởi các triển khai tiêu chuẩn quan tâm đến hiệu suất.

      Cả hai thay đổi đều cần thiết để giữ $e$ của $K_{enc}=(n,e)$ bí mật khi chúng tôi thực hiện $K_{dec}=(n,d)$ public, như trong câu hỏi.

  • Mã hóa RSA như trong bài báo gốc ngoại trừ với $n$ đủ lớn để chống lại các phương pháp nhân tố hiện đại² và hàm băm lớn hơn đáng kể so với ở trên để chống lại Desmedt và Odlyzko tấn công.

Những người xấu

Phương pháp này không an toàn khi áp dụng cho hầu hết các hệ thống mật mã bất đối xứng

quan sát rằng $K_{dec}$ phải được công khai vì đó là khóa xác minh và $K_{enc}$ phải được giữ bí mật vì nó là khóa ký. Do đó, mối quan hệ giữa hai khóa phải sao cho chúng ta có thể làm $K_{dec}$ công khai đồng thời giữ bí mật $K_{enc}$. RSA là họ lược đồ mã hóa duy nhất mà tôi biết rõ có thể có thuộc tính đó (và như đã giải thích ở trên, các triển khai thực tế của nó thì không).

Đối với nhiều hệ thống mã hóa bất đối xứng, thuộc tính không thể được áp dụng. Ví dụ, trong ElGamal và nó là hậu duệ hiện đại ECIES, $K_{dec}$ là một số nguyên mã hóa cách tiếp cận phần tử nhóm $K_{enc}$ bằng cách áp dụng luật nhóm nội bộ cho một phần tử nhóm công chúng nhất định; do đó tiết lộ $K_{dec}$ không thể tránh khỏi tiết lộ $K_{enc}$, phá vỡ tính bảo mật của cấu trúc câu hỏi.

Tổng quát hơn, việc sử dụng hệ thống mã hóa bất đối xứng an toàn và hàm băm an toàn không phải là dấu hiệu tốt cho thấy hệ thống chữ ký thu được bằng phương pháp của câu hỏi là an toàn, vì nhiều lý do.

Khi chúng tôi xem xét bảo mật triển khai, có một vấn đề nữa: việc triển khai $\texttt{mã hóa}$ không cần bảo vệ chống rò rỉ kênh bên của đầu vào chính của nó, vì nó thường công khai. Tuy nhiên, sự bảo vệ như vậy là cần thiết cho hệ thống chữ ký của câu hỏi.

Phương pháp này có xu hướng xây dựng các lược đồ chữ ký với các đặc điểm không đạt tiêu chuẩn

So sánh chữ ký RSA (bao gồm cả phương pháp của câu hỏi) với EdDSA ở mức bảo mật tiêu chuẩn:

  • Chữ ký khá lớn (256 byte so với 64 byte)
  • Khóa công khai lớn (điển hình là 260 byte so với 32 byte)
  • Tạo chữ ký chậm (chậm hơn hàng chục lần)
  • Quá trình tạo khóa rất chậm (chậm hơn hàng trăm lần).

Và phương pháp này không hoàn toàn giống như những gì được sử dụng để tạo chữ ký RSA, ngay cả người anh em họ thân thiết RSA-FDH. Điều đó sử dụng chức năng khóa riêng RSA trong sách giáo khoa $h\mapsto s=h^d$ để ký một hàm băm rộng $h=H(M)$; và chức năng khóa công khai RSA trong sách giáo khoa $s\mapsto h=s^e\bmod n$ sau đó là một so sánh $h\overset?=H(M)$ trong xác minh. Trái ngược với phương pháp của câu hỏi, khóa công khai $(n,e)$ vẫn là công khai và khóa riêng $(n,e,d,p,q,d_p,d_q,q_\text{Inv})$ vẫn còn bí mật. So với điều đó, hoặc RSASSA-PKCS1-v1_5 hoặc RSASSA-PSS, phương thức chữ ký của câu hỏi:

  • Dấu hiệu chậm hơn gần bốn lần, vì nó không thể sử dụng $(n,e,d,p,q,d_p,d_q,q_\text{Inv})$ hình thức cho $K_{dec}$
  • Xác minh chậm hơn hàng trăm đến hàng nghìn lần, vì nó không thể sử dụng một $e$.

¹ Với $n$ đã biết, nếu một trong $e$ hoặc $d$ được biết đến và ít hơn $n^{0,292}$, thì cái kia có thể được tìm thấy, xem Boneh và Durfee. Do đó, giới hạn thông thường của 256-bit $e$ (ví dụ: được tích hợp vào phương pháp tạo khóa của FIPS 186-4) là như vậy mà tiết lộ $d$ cho phép tìm $e$.

² Khuyến nghị ban đầu âđiều đó $d$ nên được chọn từ một tập hợp đủ lớn để nhà giải mã không thể tìm thấy nó bằng cách tìm kiếm trực tiếpsau đó tính toán $e$ từ $d$ là không đủ, và cho phép Wiener's tấn công, sau đó được cải thiện bởi Boneh và Durfee. Nhưng giữ $d$ bí mật và làm $e$ public vì phương pháp của câu hỏi yêu cầu khắc phục sự cố đó.

lá cờ in
Tôi xin lỗi nếu tôi không rõ ràng, nhưng tôi tin rằng bạn đang hiểu sai câu hỏi của tôi giống như @poncho. Tôi không cố nhét ngẫu nhiên các khóa mã hóa/giải mã vào sai lỗ.
fgrieu avatar
lá cờ ng
@yoyo: theo cách diễn đạt mới, tôi đồng ý rằng bạn không "xô ngẫu nhiên các khóa mã hóa/giải mã vào sai lỗ". Tôi sửa lại câu trả lời của tôi.
Điểm:5
lá cờ my

Đối với tôi, có vẻ như một sơ đồ chữ ký có thể được tạo bằng cách đặt khóa xác minh công khai $sk$ và khóa ký bí mật là $pk$

Nếu đây không phải là trường hợp, những gì đi sai?

Ý tưởng có vẻ là "chúng tôi sẽ lấy 'mã hóa cơ bản bằng khóa 1, sau đó giải mã bằng khóa 2' mô hình mã hóa khóa công khai, gọi khóa 1 là khóa riêng, khóa 2 là khóa chung và sự cố chúng tôi có một hệ thống chữ ký".

Tuy nhiên, nếu chúng ta bắt đầu với một hệ thống mã hóa khóa công khai an toàn, điều này có thể không mang lại một sơ đồ chữ ký an toàn.

fgrieu đã bắt đầu với sự phản đối phổ biến nhất đối với các lược đồ mã hóa khóa công khai được thực hiện; kiến thức về khóa 2 (trong lược đồ chữ ký, trở thành khóa chung) có thể cho phép bạn suy ra khóa 1. Bất kỳ lược đồ dựa trên nhật ký rời rạc hoặc dựa trên ECC nào cũng thuộc loại này.

Những cách khác điều này có thể thất bại:

  • Có thể là với một chuỗi dài các tin nhắn và chữ ký, chúng ta có thể suy ra khóa 1. Một số sơ đồ chữ ký dựa trên mạng không thành công vì lý do chính xác này; hóa ra là mỗi chữ ký đã rò rỉ một chút khóa riêng - rõ ràng, điều đó đã được giải quyết bằng các sơ đồ chữ ký dựa trên mạng hiện tại (chẳng hạn như Falcon và Dilithium).

  • Có thể là, với kiến ​​thức về bản rõ, 'bản mã' có thể uốn nắn được. Nghĩa là, chúng ta có thể sửa đổi bản mã để giải mã thành một bản rõ khác. ClassicMcEliece (vào chung kết vòng 3 NIST) rơi vào hạng mục này.

Điểm mấu chốt: các thuộc tính của hệ thống mã hóa khóa công khai an toàn không đủ để tạo ra sơ đồ chữ ký an toàn; nếu ai đó đề xuất một sơ đồ chữ ký như vậy, nó cần được xem xét cẩn thận (giống như bất kỳ sơ đồ nào khác)

lá cờ in
Tôi không đề xuất một "mã hóa bằng khóa riêng". Tôi đang nói "mã hóa bằng khóa chung PKC" đang ký và "giải mã bằng khóa riêng PKC" đang xác minh. (Vai trò công khai/riêng tư của các khóa đang được chuyển đổi giữa PKC và lược đồ chữ ký.)
poncho avatar
lá cờ my
@yoyo: vì vậy, bất kỳ ai có khóa chung đều có thể ký, nhưng chỉ người có khóa riêng tư mới có thể xác minh"? Điều đó không phù hợp với ý nghĩa tiêu chuẩn của việc ký...
lá cờ in
@poncho quên công khai/riêng tư (vai trò đang bị đảo ngược giữa các ứng dụng). Tôi đã viết lại câu hỏi một số để tránh nhầm lẫn.
poncho avatar
lá cờ my
@yoyo: có vẻ như câu trả lời của tôi là phù hợp, sau đó - với hầu hết các sơ đồ mã hóa khóa công khai hiện tại, sẽ không có ý nghĩa gì khi 'mã hóa' bằng khóa riêng (khóa bạn giữ bí mật) và 'giải mã' bằng khóa chung (cái bạn xuất bản).

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