2010-05-09 27 views
9

là mã này sẽ cung cấp cho tôi giá trị chính xác cho khóa RSA (giả sử rằng các hàm khác là chính xác)? im gặp khó khăn chương trình của tôi để giải mã đúng, như trong khối nhất định không được giải mã đúngđây có phải là cách chính xác để tạo khóa rsa không?

này là trong python:

import random 
def keygen(bits): 
    p = q = 3 
    while p == q: 
     p = random.randint(2**(bits/2-2),2**(bits/2)) 
     q = random.randint(2**(bits/2-2),2**(bits/2)) 
     p += not(p&1)        # changes the values from 
     q += not(q&1)        # even to odd 

     while MillerRabin(p) == False:   # checks for primality 
      p -= 2 
     while MillerRabin(q) == False: 
      q -= 2 
    n = p * q 
    tot = (p-1) * (q-1) 
    e = tot 
    while gcd(tot,e) != 1: 
     e = random.randint(3,tot-1) 
    d = getd(tot,e)      # gets the multiplicative inverse 
    while d<0:       # i can probably replace this with mod 
     d = d + tot 
    return e,d,n 

một bộ chìa khóa tạo:

e = 3daf16a37799d3b2c951c9baab30ad2d

d = 16873c0dd2825b2e8e6c2c68da3a5e25

n = dc2a732d64b83816a99448a2c2077ced

+0

Điều gì sai với 'M2Crypto.RSA.gen_key'? – jfs

+0

Có vẻ ổn với tôi, nếu có chút lạ. –

+4

Đây có phải là học thuật không? Bạn thực sự không muốn viết mật mã của riêng mình cho mã thực. –

Trả lời

5

Tôi cho rằng bạn đang làm điều này để vui chơi và học tập, chứ không phải cho những thứ cần bảo mật thực sự.

Dưới đây là một vài điều tôi nhận thấy (không theo thứ tự đặc biệt):

  1. Bạn đang không được bảo đảm rằng n sẽ có chiều dài bits. Nó có thể ngắn như bits - 4.

  2. random không phải là trình tạo số ngẫu nhiên an toàn mã hóa.

  3. Thông thường (và an toàn) để chọn số mũ công khai, e, đến 65537. Đây là số nguyên tố, vì vậy bạn có thể thay thế séc đồng thời bằng séc số chia.

  4. Hơi lạ khi tìm kiếm e bằng cách đặt e = tot (kiểm tra đồng thời bị ràng buộc là không thành công).

Nếu không thì có vẻ ổn. Chìa khóa dường như cũng hoạt động tốt. Bạn có ví dụ về một khối không giải mã chính xác không? Hãy nhớ rằng bạn chỉ có thể mã hóa dữ liệu nhỏ hơn n. Vì vậy, với khóa 128 bit (như trong ví dụ), bạn không thể mã hóa tất cả các số 128 bit.

16

Về mặt toán học, bạn n, ed dường như tôn trọng các quy tắc RSA (tức là cho mọi thủ r mà chia n, r không chia nd là một nghịch đảo của e modulo r-1). Tuy nhiên, RSA là một chút nhiều hơn thế; nó cũng yêu cầu một số quy tắc đệm, điều chỉnh cách một thông điệp (một chuỗi các byte) được chuyển đổi thành một số nguyên modulo n và ngược lại. Đệm tiêu chuẩn (xem PKCS#1) ngụ ý rằng ít nhất 11 byte được thêm vào thư và kết quả vẫn không còn là n. Do đó, với mô-đun 128-bit giống như mô-đun bạn hiển thị, thời lượng tin nhắn đầu vào tối đa để mã hóa sẽ là 5 byte.

Ngoài ra, một số triển khai RSA sẽ từ chối hoạt động với khóa RSA quá nhỏ để bảo mật. Mô-đun 128 bit có thể là nhân tố trong vài giây (xem this page cho một applet Java hệ số hóa, sử dụng ECM và sàng thứ hai để tính các số tương đối nhỏ như của bạn). Kỷ lục hiện tại về hệ số hóa là 768 bit; chiều dài modulus ít nhất 1024 bit được khuyến nghị cho bảo mật ngắn hạn. Việc triển khai RSA điển hình sẽ chấp nhận sử dụng các khóa 512 bit, nhưng nhiều người sẽ từ chối mọi thứ ngắn hơn.

Một vấn đề khác có thể là theo thứ tự tương đối là pq. Các phương trình được trình bày trong PKCS # 1 giả định rằng p> q (nếu không, có phép trừ thêm để thực hiện trong phần CRT). Nếu bạn có p < q, thì một số triển khai có thể làm sai (tôi đã gặp phải điều đó với việc thực thi chuẩn RSA của Microsoft trong Windows). Chỉ cần so sánh p với q và đổi chúng nếu cần. Tuy nhiên, trên thực tế, một số triển khai RSA phổ biến sẽ từ chối khóa RSA sao cho số mũ công khai e không khớp với số nguyên 32 bit (bao gồm triển khai RSA được sử dụng trong Windows, cụ thể là Internet) Explorer để kết nối với các trang web HTTPS - vì vậy khi tôi viết "phổ biến", tôi có nghĩa là nó). Bảo mật RSA dường như không bị ảnh hưởng bởi sự lựa chọn của e, do đó, thông thường phải chọn một số e nhỏ, tăng tốc phần sử dụng khóa công khai (ví dụ: mã hóa, trái với giải mã hoặc xác minh chữ ký , trái ngược với thế hệ chữ ký). e = 3 là điều tốt nhất bạn có thể làm, nhưng vì lý do truyền thống (bao gồm cả sự hiểu lầm lịch sử về điểm yếu bị cáo buộc), e = 65537 thường được sử dụng. Bạn chỉ cần có e tương đối chính với p-1q-1. Trong triển khai thực tế, trước tiên bạn chọn e, sau đó lặp trong thế hệ cho pq miễn là chúng không khớp với quy tắc bổ sung đó.

Từ quan điểm bảo mật của xem:

  • quá trình tạo của bạn không phải là thống nhất, trong đó một số nguyên thủ sẽ được lựa chọn thường xuyên hơn những người khác. Cụ thể, một số p chính như vậy mà p + 2 cũng là nguyên tố hầu như không bao giờ được chọn. Với một kích thước mô đun thích hợp, nên không phải là một vấn đề (loại đặc biệt của thiên vị đã được nghiên cứu và phát hiện ra không phải là một vấn đề lớn) nhưng nó là quan hệ công chúng xấu dù sao.

  • bạn n có thể nhỏ một chút so với kích thước mục tiêu của bạn, trong trường hợp cả hai pq gần cận dưới của phạm vi thế hệ của họ.Một cách đơn giản để tránh điều đó là để hạn chế phạm vi để [sqrt (2) * 2 b-1, 2 b] cho cả pq.

  • Tôi không thể xác minh cho bảo mật của mô-đun random bạn sử dụng. An an toàn mã hóa trình tạo số ngẫu nhiên không phải là điều dễ dàng để thực hiện.

  • Nói chung, thực hiện đúng RSA mà không bị rò rỉ thông tin bí mật thông qua các kênh phụ khác nhau (thời gian, sử dụng bộ nhớ cache ...) không phải là một nhiệm vụ dễ dàng. Nếu bạn muốn bảo mật trong một thiết lập thực tế, bạn thực sự cần thực hiện thực sự sử dụng gói hiện có. Tôi tin rằng Python có cách để giao tiếp với OpenSSL.

+0

'ngẫu nhiên' không an toàn về mặt mã hóa; nó sử dụng Mersenne Twister, có thể bị phá vỡ bằng cách đọc vài trăm giá trị. –

Các vấn đề liên quan