Sự khác biệt giữa mã hóa và đăng nhập vào mã hóa bất đối xứng là gì?


297

Sự khác biệt giữa mã hóa một số dữ liệu so với ký một số dữ liệu (sử dụng RSA) là gì?

Nó chỉ đơn giản là đảo ngược vai trò của các khóa công khai?

Ví dụ: tôi muốn sử dụng khóa riêng của mình để tạo tin nhắn để chỉ tôi mới có thể là người gửi. Tôi muốn khóa công khai của mình được sử dụng để đọc tin nhắn và tôi không quan tâm ai đọc chúng. Tôi muốn có thể mã hóa một số thông tin nhất định và sử dụng nó làm khóa sản phẩm cho phần mềm của mình. Tôi chỉ quan tâm rằng tôi là người duy nhất có thể tạo ra những thứ này. Tôi muốn đưa khóa công khai của mình vào phần mềm để giải mã / đọc chữ ký của khóa. Tôi không quan tâm ai có thể đọc dữ liệu trong khóa, tôi chỉ quan tâm rằng tôi là người duy nhất có thể kiểm chứng được.

Là ký hữu ích trong kịch bản này?

Câu trả lời:


441

Khi mã hóa, bạn sử dụng khóa chung của họ để viết tin nhắn và họ sử dụng khóa riêng của họ để đọc nó.

Khi ký, bạn sử dụng khóa riêng của mình để viết chữ ký của tin nhắn và họ sử dụng khóa chung của bạn để kiểm tra xem đó có thực sự là của bạn không.

Tôi muốn sử dụng khóa riêng của mình để tạo tin nhắn để chỉ tôi mới có thể là người gửi.

Tôi muốn khóa công khai của mình được sử dụng để đọc tin nhắn và tôi không quan tâm ai đọc chúng

Đây là , nó được thực hiện với khóa riêng của bạn.

Tôi muốn có thể mã hóa một số thông tin nhất định và sử dụng nó làm khóa sản phẩm cho phần mềm của mình.

Tôi chỉ quan tâm rằng tôi là người duy nhất có thể tạo ra những thứ này.

Nếu bạn chỉ cần biết điều đó với chính mình, bạn không cần phải lộn xộn với các phím để làm điều này. Bạn chỉ có thể tạo dữ liệu ngẫu nhiên và giữ nó trong cơ sở dữ liệu.

Nhưng nếu bạn muốn mọi người biết rằng các khóa thực sự là của bạn, bạn cần tạo dữ liệu ngẫu nhiên, giữ trong đó một cơ sở dữ liệu VÀ ký tên với khóa của bạn.

Tôi muốn đưa khóa công khai của mình vào phần mềm để giải mã / đọc chữ ký của khóa.

Bạn có thể cần phải mua chứng chỉ cho khóa công khai của mình từ nhà cung cấp thương mại như Verisign hoặc Thawte, để mọi người có thể kiểm tra xem không ai giả mạo phần mềm của bạn và thay thế khóa công khai của bạn bằng khóa của họ.


7
Về mặt kỹ thuật, khi bạn nói khóa riêng được sử dụng để viết chữ ký của tin nhắn, bạn có nói rằng hàm băm của tin nhắn đang được mã hóa bằng khóa riêng của tôi không?
Andy Ibanez

4
@AndyIbanez: những gì được mã hóa ( thông báo ) cũng có thể bao gồm dấu thời gian và một số muối ngẫu nhiên, nhưng vâng, đó là ý chính của nó.
Quassnoi

7
@Quassnoi Trong thực tế khi chúng ta nói 'ký bằng khóa riêng', điều đó có nghĩa không phải là 'mã hóa' mà thay vào đó có nghĩa là 'giải mã'. Ký thông báo đại khái giống như giải mã với khóa riêng và trong mã hóa máy thu bằng khóa chung, cách này băm sẽ trở nên giống nhau và có thể được so sánh.
Johnny Willer

5
@JohnnyWiller: như @slim đã đề cập dưới đây, lõi toán học giống nhau cho cả chức năng mã hóa và giải mã. Chúng không phải là các chức năng riêng biệt, chúng là cùng một chức năng f(key, message), sao chof(private, f(public, message)) === f(public, f(private, message)) === message
Quassnoi

2
@ Không, không phải vậy. Tạo cặp chìa khóa là miễn phí. Chi phí liên quan đến việc khiến những người khác tin rằng chữ ký thực sự là của bạn. Để làm điều đó, bạn có chính khóa công khai mà bạn đã tạo trước đó miễn phí, được ký bởi một cơ quan có thể hoặc có thể không tính tiền cho bạn cho việc đó.
Quassnoi

143

Trong tiền điện tử RSA, khi bạn tạo một cặp khóa, nó hoàn toàn tùy ý bạn chọn khóa nào là khóa chung và khóa riêng là khóa riêng. Nếu bạn mã hóa bằng một, bạn có thể giải mã bằng cái kia - nó hoạt động theo cả hai hướng.

Vì vậy, khá đơn giản để xem cách bạn có thể mã hóa tin nhắn bằng khóa chung của người nhận , để người nhận có thể giải mã nó bằng khóa riêng của họ .

Chữ ký là bằng chứng cho thấy người ký có khóa riêng khớp với một số khóa chung. Để làm điều này, sẽ đủ để mã hóa tin nhắn bằng khóa riêng của người gửi đó và bao gồm phiên bản được mã hóa cùng với phiên bản văn bản gốc. Để xác minh người gửi, giải mã phiên bản được mã hóa và kiểm tra xem nó có giống với bản rõ không.

Tất nhiên, điều này có nghĩa là tin nhắn của bạn không bí mật. Bất cứ ai cũng có thể giải mã nó, bởi vì khóa công khai đã được biết đến. Nhưng khi họ làm như vậy, họ đã chứng minh rằng người tạo ra bản mã có khóa riêng tương ứng.

Tuy nhiên, điều này có nghĩa là tăng gấp đôi kích thước truyền của bạn - văn bản gốc và bản mã cùng nhau (giả sử bạn muốn những người không quan tâm đến việc xác minh chữ ký, để đọc tin nhắn). Vì vậy, thay vào đó, thông thường một chữ ký được tạo bằng cách tạo một hàm băm của bản rõ. Điều quan trọng là băm giả không thể được tạo, vì vậy các thuật toán băm mật mã như SHA-2 được sử dụng.

Vì thế:

  • Để tạo chữ ký, hãy tạo một hàm băm từ bản rõ, mã hóa nó bằng khóa riêng của bạn, bao gồm nó cùng với bản rõ.
  • Để xác minh chữ ký, hãy tạo một hàm băm từ bản rõ, giải mã chữ ký bằng khóa chung của người gửi, kiểm tra xem cả hai giá trị băm có giống nhau không.

8
@headcode nó chỉ áp dụng cho các khóa không đối xứng. Các khóa đối xứng không đi theo cặp.
mỏng

3
Trên thực tế, nó chỉ áp dụng cho các khóa RSA. Ví dụ, với các khóa ECDSA, bạn có thể tạo khóa công khai một cách tầm thường từ khóa riêng và khóa riêng là vô hướng trong khi khóa chung là tọa độ.
David Schwartz

5
Làm thế nào bạn có thể giải mã tin nhắn bằng khóa PUBLIC? Không phải tin nhắn chỉ được giải mã bằng khóa riêng?
daremkd

3
5 nguồn mâu thuẫn với câu trả lời này 1 , 2 , 3 , 4 , 5
từ

6
Nó không độc đoán mà bạn gọi là công khai và riêng tư. Bạn có thể tạo khóa chung từ khóa riêng, nhưng bạn không thể tạo khóa riêng từ khóa chung. Đó không phải là một sự khác biệt lớn sao?
Greg Schmit

23

Có hai vấn đề khác biệt nhưng có liên quan chặt chẽ trong việc thiết lập một giao tiếp an toàn

  1. Mã hóa dữ liệu để chỉ những người được ủy quyền mới có thể giải mã và đọc nó.
  2. Xác minh danh tính / xác thực của người gửi.

Cả hai vấn đề này đều có thể được giải quyết một cách tao nhã bằng cách sử dụng mật mã khóa công khai.

I. Mã hóa và giải mã dữ liệu

Alice muốn gửi tin nhắn cho Bob mà không ai có thể đọc được.

  • Alice mã hóa tin nhắn bằng khóa chung của Bob và gửi nó đi.
  • Bob nhận được tin nhắn và giải mã nó bằng Khóa riêng của anh ấy.

Lưu ý rằng nếu A muốn gửi tin nhắn đến B, A cần sử dụng Khóa chung của B (có sẵn công khai cho bất kỳ ai) và không phải khóa công khai cũng như khóa riêng của A xuất hiện ở đây.

Vì vậy, nếu bạn muốn gửi tin nhắn cho tôi, bạn nên biết và sử dụng khóa chung của tôi mà tôi cung cấp cho bạn và chỉ tôi mới có thể giải mã tin nhắn vì tôi là người duy nhất có quyền truy cập vào khóa riêng tương ứng.

II. Xác minh danh tính người gửi (Xác thực)

Alice muốn gửi tin nhắn cho Bob một lần nữa. Vấn đề mã hóa dữ liệu được giải quyết bằng phương pháp trên.

Nhưng chuyện gì sẽ xảy ra nếu tôi ngồi giữa Alice và Bob, tự giới thiệu mình là 'Alice' với Bob và gửi tin nhắn của riêng tôi cho Bob thay vì chuyển tiếp tin nhắn do Alice gửi. Mặc dù tôi không thể giải mã và đọc tin nhắn gốc do Alice gửi (yêu cầu quyền truy cập vào khóa riêng của Bob) Tôi đang chiếm quyền điều khiển toàn bộ cuộc trò chuyện giữa họ.

Có cách nào Bob có thể xác nhận rằng những tin nhắn anh ấy nhận được thực sự được gửi bởi Alice không?

  • Alice ký tin nhắn bằng khóa riêng của mình và gửi nó đi. (Trong thực tế, những gì được ký là một hàm băm của thông điệp, ví dụ SHA-256 hoặc SHA-512.)
  • Bob nhận được nó và xác minh nó bằng khóa công khai của Alice. Vì khóa công khai của Alice đã xác minh thành công tin nhắn, Bob có thể kết luận rằng tin nhắn đã được Alice ký.

1
Vì vậy, khi bạn ký tin nhắn, bạn có ký chính tin nhắn thực sự hoặc tin nhắn được mã hóa không?
FrostyStraw

21

Vâng nghĩ về việc ký dữ liệu như đưa cho nó con dấu sáp của riêng bạn mà không ai khác có. Nó được thực hiện để đạt được tính toàn vẹn và không thoái thác . Mã hóa là để không ai khác có thể xem dữ liệu. Điều này được thực hiện để đạt được bảo mật . Xem wikipedia http://en.wikipedia.org/wiki/Inform_security#Key_con

Chữ ký là một hàm băm của tin nhắn của bạn được ký bằng khóa riêng của bạn.


16

Việc ký đang tạo ra một "hàm băm" với khóa riêng của bạn có thể được xác minh bằng khóa chung của bạn. Các văn bản được gửi rõ ràng.

Mã hóa sử dụng khóa chung của người nhận để mã hóa dữ liệu; giải mã được thực hiện với khóa riêng của họ.

Vì vậy, việc sử dụng khóa không bị đảo ngược (nếu không khóa riêng của bạn sẽ không còn riêng tư nữa!).


Trong mã hóa bất đối xứng thông thường, mã hóa được thực hiện với khóa chung của người nhận, không phải khóa riêng của bạn.
mmcdole

Bạn có bỏ lỡ rằng câu hỏi này là cụ thể về RSA khi việc sử dụng các khóa được đảo ngược và nơi mà nó không thỏa hiệp với khóa riêng.
David Schwartz

8

Bạn đang mô tả chính xác cách thức và lý do tại sao việc ký được sử dụng trong mật mã khóa công khai. Lưu ý rằng rất nguy hiểm khi ký (hoặc mã hóa) các tin nhắn tùy ý do người khác cung cấp - điều này cho phép các cuộc tấn công vào các thuật toán có thể làm tổn hại đến các khóa của bạn.


1
Không trình duyệt web mã hóa dữ liệu tùy ý khi sử dụng SSL?
Ian Warburton

2
@IanWarburton: Nhưng họ không sử dụng mã hóa bất đối xứng cho điều đó. Việc truyền dữ liệu thực tế sử dụng mã hóa đối xứng với khóa phiên được tạo ngẫu nhiên.
Michael Borgwardt

1
@IanWarburton: không, bởi vì kẻ tấn công sẽ không được chọn . Nguy hiểm nằm ở việc mã hóa hoặc ký tên thứ gì đó do kẻ tấn công cung cấp trực tiếp, bởi vì điều đó rất có thể được tạo ra một cách có chủ ý để tiết lộ thông tin về khóa riêng của bạn hoặc thậm chí tạo chữ ký có vẻ hợp lệ cho thứ bạn không có ý định ký. Một phân tích chi tiết về cách thức hoạt động của trường hợp sau cho RSA tại đây: crypto.stackexchange.com/questions/35644/ mẹo
Michael Borgwardt

2
@IanWarburton: đó là lý do tại sao RSA yêu cầu đệm, vì vậy bạn không bao giờ chỉ mã hóa một tin nhắn đã chọn: en.wikipedia.org/wiki/iêu - nhưng đó thực sự là các hoạt động liên quan đến khóa riêng (như ký), đặc biệt dễ bị tổn thương trước đầu vào được chọn.
Michael Borgwardt

1
@IanWarburton Tôi không phải là chuyên gia về mật mã, nhưng theo những gì tôi hiểu, điều đó sẽ không gây ra bất kỳ vấn đề nào.
Michael Borgwardt

8

Việc ký cho biết bạn thực sự là nguồn hoặc chứng từ cho đối tượng đã ký. Mọi người đều có thể đọc đối tượng, mặc dù.

Mã hóa có nghĩa là chỉ những người có khóa riêng tương ứng mới có thể đọc được, nhưng không ký thì không có gì đảm bảo bạn đứng sau đối tượng được mã hóa.


Nếu tin nhắn được giải mã bằng khóa mu của tôi thì chỉ tôi mới có thể gửi nó. (Giả sử khóa riêng của tôi không bị xâm phạm)
Dojo

5

Sự khác biệt giữa mã hóa một số dữ liệu so với ký một số dữ liệu (sử dụng RSA) là gì?

Mã hóa bảo vệ tính bảo mật của tin nhắn ("một số dữ liệu"), trong khi việc ký cung cấp không thoái thác: tức là chỉ có thực thể đã ký nó mới có thể ký tên. Có sự khác biệt về chức năng là tốt; đọc tiếp

Nó chỉ đơn giản là đảo ngược vai trò của các khóa công khai?

Tuyệt đối không. Việc sử dụng cùng một khóa riêng để ký và giải mã (hoặc, tương tự, các khóa chung để xác minh và mã hóa ) được chấp nhận, vì bạn không nên trộn lẫn các mục đích. Đây không phải là một vấn đề toán học (RSA vẫn phải được bảo mật), nhưng là một vấn đề với quản lý khóa , trong đó, ví dụ như khóa ký phải có thời gian tồn tại ngắn hơn và có nhiều sự bảo vệ hơn trước khi sử dụng.

Đối với cùng một tin nhắn, bạn nên sử dụng khóa riêng của người gửi để ký và người nhận khóa công khai đáng tin cậy để mã hóa. Thông thường ký mã hóa sau đó được sử dụng nếu không một kẻ thù có thể thay thế chữ ký bằng chữ ký của mình. Tương tự như vậy, bạn nên sử dụng khóa riêng của người nhận để giải mã và tin cậy của người gửi để xác minh.

Hơn nữa, bạn nên hiểu rằng việc tạo chữ ký không sử dụng "mã hóa bằng khóa riêng". Mặc dù tất cả các hoạt động RSA dựa trên lũy thừa mô-đun, sơ đồ đệm hoàn toàn khác nhau cho việc tạo chữ ký. Hơn nữa, khóa chung có các thuộc tính hoàn toàn khác với khóa riêng RSA trong tất cả các sử dụng thực tế của RSA.

Ví dụ: tôi muốn sử dụng khóa riêng của mình để tạo tin nhắn để chỉ tôi mới có thể là người gửi.

Đó là tài sản không thoái thác, có thể đạt được bằng cách ký.

Tôi muốn khóa công khai của mình được sử dụng để đọc tin nhắn và tôi không quan tâm ai đọc chúng.

Khóa công khai nên được xem xét bởi tất cả. Nếu bạn muốn mọi người đọc tin nhắn, thì bạn chỉ cần không mã hóa chúng.

Việc ký kết nói chung sẽ không ảnh hưởng đến nội dung của tin nhắn. Thông điệp được coi là tách biệt với chữ ký. Chính thức chữ ký như vậy được gọi là "chữ ký có phụ lục" trong đó phụ lục là thông điệp. Đó là một cái tên hơi kỳ lạ vì thông điệp được coi là quan trọng hơn chữ ký trên nó, nhưng vâng. Chỉ có một vài chữ ký cung cấp phục hồi tin nhắn (một phần); chúng không được sử dụng nhiều nữa và thường được coi là không dùng nữa.

Lưu ý rằng các giao thức chữ ký như CMS có thể triển khai định dạng chứa bao gồm cả thông báo và chữ ký. Trong trường hợp đó, trước tiên bạn cần lấy thông báo - vẫn chưa được mã hóa - ra khỏi vùng chứa, giống như giải nén tệp từ tệp lưu trữ .zip đơn giản. Vì vậy, tin nhắn có thể bị ẩn khỏi chế độ xem và không thể được sử dụng trực tiếp trong trường hợp đó.

Tôi muốn có thể mã hóa một số thông tin nhất định và sử dụng nó làm khóa sản phẩm cho phần mềm của mình. Tôi chỉ quan tâm rằng tôi là người duy nhất có thể tạo ra những thứ này.

Mã hóa được sử dụng để đạt được bảo mật. Trước đây, việc tạo chữ ký RSA thường được coi là "mã hóa bằng khóa riêng". Tuy nhiên, các hoạt động khá khác nhau như đã giải thích ở trên, và các tiêu chuẩn sau này cố gắng hết sức và tách mã hóa và tạo chữ ký.

Tôi muốn đưa khóa công khai của mình vào phần mềm để giải mã / đọc chữ ký của khóa. Tôi không quan tâm ai có thể đọc dữ liệu trong khóa, tôi chỉ quan tâm rằng tôi là người duy nhất có thể kiểm chứng được.

Vâng, điều này được gọi là thiết lập niềm tin vào khóa công khai. Tuy nhiên, bảo vệ mã chương trình của bạn rất khác với bảo vệ tin nhắn. Bạn có thể thực hiện ký mã nhưng sau đó bạn cần một cái gì đó để kiểm tra chữ ký bên ngoài mã của bạn . Có những hệ điều hành cung cấp điều này.

Có Microsoft Authenticode chẳng hạn. Các cửa hàng ứng dụng như cửa hàng ứng dụng iStore và Android có thể hoặc không sử dụng ký mã, nhưng họ cung cấp một số đảm bảo rằng ứng dụng của bạn không được sao chép hoặc ít nhất là không được nhân bản trong cửa hàng. Mật mã không phải lúc nào cũng là giải pháp.

Giữ cho mã của bạn không bị sao chép / thay đổi hoàn toàn khó hơn nhiều và bạn sẽ vững chắc trong lãnh thổ DRM nếu bạn đi theo cách đó.

Là ký hữu ích trong kịch bản này?

Chắc chắn rồi. Nó chắc chắn có thể giúp đảm bảo rằng các tin nhắn chỉ được ký bởi bạn, nếu có niềm tin vào khóa chung. Nếu nó có thể hữu ích cho việc xác thực mã ứng dụng / khóa công khai tích hợp của bạn thì hoàn toàn phụ thuộc vào môi trường mà bạn mong đợi để chạy mã.


"Trước đây, thế hệ chữ ký RSA thường được coi là" mã hóa bằng khóa riêng ". Tuy nhiên, các hoạt động hoàn toàn khác nhau như đã giải thích ở trên, và các tiêu chuẩn sau này cố gắng tách biệt mã hóa và tạo chữ ký. - điều này không rõ ràng với tôi. KeyPair có thể là pk hoặc sk và những gì mã hóa cái kia có thể giải mã. Nếu chúng ta đồng ý về điều đó, thì làm sao chúng ta có thể lập luận rằng việc ký và mã hóa là khác biệt theo bất kỳ cách có ý nghĩa nào? Cả hai mã hóa và sau đó chỉ có thể được giải mã bằng khóa khác. Tôi đã thấy các tài liệu tham khảo về chức năng ký, điều này có liên quan không?
Morgan

Khác biệt duy nhất tôi biết trong chức năng ký là băm tin nhắn trước khi mã hóa.
Morgan

4

Trong kịch bản của bạn, bạn không mã hóa theo nghĩa mã hóa bất đối xứng; Tôi muốn gọi nó là "mã hóa".

Vì vậy, bạn mã hóa dữ liệu của mình thành một số biểu diễn nhị phân, sau đó bạn ký bằng khóa riêng của mình. Nếu bạn không thể xác minh chữ ký thông qua khóa chung của mình, bạn biết rằng dữ liệu đã ký không được tạo bằng khóa riêng của bạn. ("xác minh" có nghĩa là dữ liệu không dấu không có ý nghĩa)


2

Về mặt chức năng, bạn sử dụng mã hóa khóa chung / riêng để đảm bảo chỉ người nhận mới có thể đọc tin nhắn của bạn. Tin nhắn được mã hóa bằng khóa chung của người nhận và được giải mã bằng khóa riêng của người nhận.

Việc ký bạn có thể sử dụng để cho người nhận biết bạn đã tạo tin nhắn và nó không thay đổi trong quá trình chuyển. Việc ký tin nhắn được thực hiện bằng khóa riêng của bạn. Người nhận có thể sử dụng khóa chung của bạn để kiểm tra tin nhắn chưa bị giả mạo.

Đối với thuật toán được sử dụng: liên quan đến hàm một chiều, xem ví dụ wikipedia . Một trong những thuật toán đầu tiên sử dụng số nguyên tố lớn nhưng nhiều hàm một chiều đã được phát minh kể từ đó.

Tìm kiếm 'Bob', 'Alice' và 'Mallory' để tìm các bài viết giới thiệu trên internet.


Bạn có thể nhận xét về trường hợp sử dụng của tôi? Tôi muốn sử dụng khóa riêng để mã hóa và khóa chung để cho phép mọi người và mọi người giải mã.
mmcdole

1
Không phải sự thật là tất cả mã hóa bất đối xứng đều dựa trên các số nguyên tố, đây chỉ là ví dụ nổi tiếng nhất (RSA); có các phương pháp khác như mật mã đường cong elliptic.
Michael Borgwardt

"Tin nhắn được mã hóa sau đó được mã hóa bằng khóa chung của người nhận." Câu đó không có nghĩa gì cả, hoặc ít nhất nó cần giải thích thêm. "Đã mã hóa rồi mã hóa" ???
Maarten Bodewes

Bạn đã quên mất Warner! :)
Dojo

1

Trả lời câu hỏi này trong nội dung mà người hỏi có ý định sử dụng giải pháp để cấp phép phần mềm, các yêu cầu là:

  1. Không bên thứ 3 nào có thể tạo khóa cấp phép từ dịch ngược ứng dụng
  2. Nội dung của khóa phần mềm không cần phải bảo mật
  3. Khóa phần mềm không thể đọc được

Chữ ký số sẽ giải quyết vấn đề này vì dữ liệu thô làm cho khóa có thể được ký bằng khóa riêng khiến nó không thể đọc được nhưng có thể được giải mã nếu được thiết kế ngược. Nhưng khóa riêng là an toàn, điều đó có nghĩa là không ai có thể tạo giấy phép cho phần mềm của bạn (đó là điểm chính).

Hãy nhớ rằng bạn không thể ngăn người có kỹ năng gỡ bỏ khóa phần mềm trên sản phẩm của bạn. Vì vậy, nếu họ phải hack từng phiên bản được phát hành. Nhưng bạn thực sự không muốn họ có thể tạo khóa mới cho sản phẩm của bạn có thể được chia sẻ cho tất cả các phiên bản.

Python Tài liệu PyNaCl có một ví dụ về 'Chữ ký số' sẽ phù hợp với mục đích. http://pynacl.readthedocs.org/en/latest/signing/

và nguyên nhân của dự án NaCl đến C ví dụ

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.