Điểm:3

RSA: Bỏ thuật toán sang một bên, làm thế nào chúng ta biến một chuỗi thành một số nguyên và ngược lại?

lá cờ cn

Giả sử tôi muốn mã hóa tệp đơn giản.txt. Bước đầu tiên thực sự là biến nội dung của tệp đó (giả sử nó chỉ chứa chuỗi "Xin chào") thành một int. Tôi thấy mã python như thế này:

từ Crypto.Util.number nhập bytes_to_long
với open('plain.txt', 'rb') là f:
    cờ = f.read()

m = bytes_to_long(cờ)

Tuy nhiên, tôi không hiểu lắm chuyện gì đang xảy ra. Hơn nữa, khi bản mã đã được giải mã trở lại bản rõ nhưng vẫn ở dạng số, tôi không thấy long_to_byte hoặc bất cứ thứ gì để chuyển đổi số thành chuỗi. tôi hiểu rồi

nhập khẩu binascii
binascii.unhexlify('{:x}'.format(m))

Nó trông hoàn toàn khác với mã khác, nhưng nó vẫn hoạt động.Ai đó có thể giải thích các quy trình này cho tôi để tôi hiểu đầu vào và đầu ra của thuật toán mã hóa chứ không chỉ bản thân thuật toán đó không.

kelalaka avatar
lá cờ in
Chào mừng bạn đến với Cryptography.SE. Đây là sự cố giải mã mã hóa và không có chủ đề ở đây. Bên cạnh đó, bạn đang làm sai. Người ta nên giải mã hoàn toàn ngược lại với mã hóa được áp dụng,
fgrieu avatar
lá cờ ng
Một chuyển đổi byte thành int phổ biến là [OS2IP trong PKCS#1](https://pkcs1.grieu.fr#page=9).Đơn giản hóa mô tả một chút, coi byte là chữ số trong cơ số 256 (nghĩa là số nguyên từ 0 đến 255, giống như các chữ số thông thường trong cơ số 10 là từ 0 đến 9), sau đó chuyển đổi $n$ byte $X_1,X_2â¦X_n $ (từ đầu tiên/trái đến cuối cùng/phải) thành số nguyên $\displaystyle\sum_{1â¤iâ¤n} 256^{n-i}X_i$. Lưu ý rằng hiếm khi được sử dụng cho _text_ bên ngoài ngữ cảnh CTF. Thay vào đó, nó được sử dụng [mã hóa kết hợp](https://en.wikipedia.org/wiki/Hybrid_cryptosystem).
lá cờ cn
Một cải tiến cho câu hỏi sẽ là xóa từ RSA khỏi câu hỏi. Nội dung thực tế không có gì để làm với nó. Và trên thực tế, RSA hầu như không bao giờ được sử dụng trực tiếp để mã hóa dữ liệu mà sử dụng mã hóa lai.
Maarten Bodewes avatar
lá cờ in
Tôi đã cố gắng trả lời làm thế nào loại điều này thường hoạt động. Nếu bạn đang nói về RSA trong sách giáo khoa thì thông thường một hoặc nhiều byte được chuyển thành một số nguyên giữa 0 và mô đun, sau đó áp dụng phép lũy thừa mô đun. Giải mã có nghĩa là tách bản mã thành các khối có cùng kích thước với môđun, giải mã và sau đó giải mã lại. Có quá ít chi tiết trong câu hỏi để chỉ ra nhiều hơn thế này.
Điểm:7
lá cờ in

Về cơ bản có hai bước để làm điều này:

  1. mã hóa văn bản thành byte - điều này thường yêu cầu mã hóa ký tự như mã hóa UTF-8 hoặc Latin;
  2. mã hóa các byte thành số nguyên - đây là một phần của hoạt động mã hóa trong RSA như được chỉ định trong PKCS#1 và được thực hiện bằng chức năng có tên là OS2IP.

Trong trường hợp của bạn, văn bản rõ ràng đã được mã hóa thành byte; Rốt cuộc, các tệp bao gồm các byte và bạn đang mở tệp dưới dạng tệp nhị phân (b trong cờ rb).

OS2IP có nghĩa là chuỗi octet thành số nguyên nguyên thủy. Một chuỗi octet không gì khác hơn là một mảng byte. Nếu các byte đã ở đúng dạng thì đó chỉ là vấn đề phiên dịch các byte dưới dạng số, vì máy tính luôn xử lý mọi thứ dưới dạng nhị phân.

Mặc dù vậy, trong RSA OS2IP dựa trên PKCS#1 không được sử dụng trực tiếp: trước tiên, một phần đệm liên quan đến bảo mật được áp dụng. Đây sẽ là phần đệm được xác định PKCS#1 v1.5 hoặc phần đệm OAEP. Thêm phần đệm có nghĩa là một lượng chi phí không đáng kể được thêm vào trước khi thông báo được áp dụng; lượng bản rõ nhỏ hơn nhiều so với mô đun RSA.


Đây là một lý do tại sao các tệp thường không được mã hóa trực tiếp bằng RSA. Lý do chính khác là mã hóa RSA và đặc biệt là các hoạt động giải mã rất kém hiệu quả so với ví dụ. Mã hóa dựa trên AES. Thay vào đó, chúng tôi sử dụng một giao thức chẳng hạn như PGP thực hiện mã hóa lai. RSA trong chế độ hoạt động an toàn có một chi phí hoạt động nhất định và mức tối đa cho mỗi hoạt động, do đó, thông thường, khóa đối xứng được mã hóa hoặc dẫn xuất bằng RSA thay thế; khóa đối xứng này sau đó được sử dụng để mã hóa dữ liệu. Các mật mã đối xứng như AES hoạt động trực tiếp trên dữ liệu nhị phân, do đó, bên cạnh việc xử lý IV ​​và phần đệm, dữ liệu có thể được mã hóa trực tiếp mà không cần chuyển đổi.

lá cờ us
Đoán xem, OS2IP giả định các giới hạn độ dài đối với việc chuyển đổi từng chuỗi octet một, do đó, xuất phát từ luồng byte ở bước 2. OS2IP được thực hiện trước bằng cách phân mảnh thành các gói, trong đó kích thước gói phụ thuộc vào độ dài khóa và chế độ đệm.
Maarten Bodewes avatar
lá cờ in
Không, OS2IP thường không đi trước bằng cách phân mảnh thành các gói; đối với RSA, bạn không sử dụng chế độ CBC hoặc thậm chí là chế độ ECB, bạn chỉ cần mã hóa một tin nhắn có cùng kích thước. Tôi đã thêm một số chi tiết vào câu trả lời.
lá cờ us
Hiểu không. Đó là lý do tại sao một số thư viện, ví dụ: JCE thậm chí không phản ánh kích thước tối đa mà bạn có thể chuyển sang phương thức mã hóa vì bạn không cần nó.
Maarten Bodewes avatar
lá cờ in
Meh, dù sao thì JCA cũng không trả lại nhiều thông tin meta như vậy. Tôi không chắc tại sao lại như vậy, thật dễ dàng để tính toán chi phí so với mô-đun, ví dụ: chỉ 11 byte (để bảo mật tối thiểu) cho PKCSv1 1.5 và tốt, [nó khác với OAEP](https://crypto.stackexchange.com/a/42100/1172).
lá cờ us
Rất tiếc, hãy xem hai nhận xét của tôi đã bị kiểm duyệt. Hãy coi đây là sự xác nhận. Có, cách dễ nhất để tìm tải trọng tối đa là đặt một thông báo có độ dài mô-đun và phân tích cú pháp ngoại lệ được đưa ra, một cách chính xác theo PKCSv1/OS2IP.
lá cờ cn
Tôi không khuyên dùng phần đệm PKCS#1 v1.5, do các cuộc tấn công Bleichenbacher khác nhau (cuộc tấn công ROBOT là cuộc tấn công gần đây nhất mà tôi biết). Phiên bản 1.5 đã được phát hành và không được dùng nữa (bởi phiên bản 2.0) trong cùng năm, vào năm 1998, do phần đệm này bị hỏng trong cùng năm đó. Ngay cả khi nó vẫn được sử dụng trong thực tế, phần đệm này thường đi kèm với một cảnh báo như "không bao giờ sử dụng phần đệm này, không dành cho mã hóa, trao đổi khóa hoặc chữ ký".
lá cờ us
@tylo OS2IP không chạm vào phần đệm. Liên quan đến Bleichenbacher, hãy xem xét ý tưởng rằng một số phần đệm không có thật với các hằng số trong đầu ra đã được cố ý thiết lập.
lá cờ cn
@SamGinrich Tôi không ngụ ý, đúng vậy. Câu trả lời chỉ nêu rõ rằng theo thông số PKCS#1, phần đệm V1.5 được sử dụng. Và theo tôi, điều này phải luôn đi kèm với một cảnh báo như "không sử dụng cái này". Ngay cả trong một số trường hợp sử dụng cụ thể, phần đệm V1.5 vẫn có thể sử dụng được - điều đó sẽ phải được chứng minh, đòi hỏi kiến ​​thức chuyên sâu về chủ đề và có khả năng xảy ra lỗi do con người. Lời khuyên với rủi ro tổng thể tối thiểu là hoàn toàn không sử dụng/cho phép phần đệm đó.
lá cờ us
@tylo Đồng ý với lời khuyên của bạn. Có một cộng đồng quan tâm đến vấn đề bảo mật, trong đó khía cạnh này nên được ưu tiên số 1. Ở đây trong Mật mã học, tôi mong đợi một cuộc thảo luận về một khái niệm thuật toán không đầy đủ và không có tư duy tốt. Mặc dù, tôi đã thú nhận với các chi tiết của một số biến thể thuật toán nhất định, nhưng tôi không mong đợi bạn nhận bất kỳ lời khuyên nào từ tôi mà không đưa ra lời giải thích có thể theo dõi hoặc ít nhất là một tài liệu tham khảo về điều đó.
Maarten Bodewes avatar
lá cờ in
Bạn không thể áp dụng các chế độ mật mã khối khác ngoài ECB cho RSA *với phần đệm an toàn* - ít nhất là không phải không có sự thay đổi. Và nó sẽ luôn dẫn đến chi phí khác. Rõ ràng là nó cũng kém hiệu quả hơn nhiều, đặc biệt là trong quá trình giải mã. Thiếu hiệu quả và mở rộng thông điệp là những nhược điểm khách quan hơn là những nhược điểm chính trị nếu bạn hỏi tôi.
lá cờ us
Tôi nghĩ rằng hầu hết người dùng ở đây để giúp đỡ mọi người và tôi là một trong số họ.

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