sẽ python SystemRandom/os.urandom luôn có đủ dữ liệu ngẫu nhiên cho crypto tốt

Question

Tôi có một bộ tạo mật khẩu:

import random, string 

def gen_pass(): 
    foo = random.SystemRandom() 
    length = 64 
    chars = string.letters + string.digits 
    return ''.join(foo.choice(chars) for _ in xrange(length)) 

Theo các tài liệu, sử dụng SystemRandom os.urandom trong đó sử dụng/dev/urandom để ném ra ngẫu nhiên bit cryto. Trong Linux, bạn có thể nhận các bit ngẫu nhiên từ/dev/urandom hoặc/dev/random, cả hai đều sử dụng bất kỳ entropy nào mà hạt nhân có thể thực hiện được. Số lượng entropy có sẵn có thể được kiểm tra bằng đuôi/proc/sys/kernel/random/entropy_avail, điều này sẽ trả về một con số như: 129. Số entropy càng nhiều. Sự khác biệt giữa/dev/urandom và/dev/random là/dev/random sẽ chỉ nhổ ra bit nếu entropy_avail đủ cao (như ít nhất 60) và/dev/urandom sẽ luôn nhổ ra các bit. Các tài liệu nói rằng/dev/urandom là tốt cho mật mã và bạn chỉ phải sử dụng/dev/ngẫu nhiên cho ssl certs và tương tự.

Câu hỏi của tôi sẽ tốt cho việc tạo mật khẩu cấp mật mã mạnh mẽ? Nếu tôi gọi hàm này càng nhanh càng tốt, tôi sẽ ngừng nhận các bit cryto mạnh tại một số điểm vì hồ entropy bị cạn kiệt?

Câu hỏi cũng có thể là lý do tại sao/dev/urandom luôn luôn tạo ra các bit cryto mạnh và không quan tâm đến entropy_avail? Có thể là/dev/urandom được thiết kế sao cho băng thông của nó bị giới hạn bởi số chu kỳ bạn có thể đoán sẽ tương quan với số lượng entropy, nhưng đây là suy đoán và tôi không thể tìm thấy câu trả lời.

Đây cũng là câu hỏi ngăn xếp đầu tiên của tôi, vì vậy hãy phê bình tôi. Tôi lo ngại rằng tôi đã đưa ra nhiều bối cảnh khi ai đó biết câu trả lời có thể biết nền.

Cảm ơn

cập nhật

tôi đã viết một số mã để xem xét các hồ bơi entropy trong khi /dev/urandom đã được đọc từ:

import subprocess 
import time 

from pygooglechart import Chart 
from pygooglechart import SimpleLineChart 
from pygooglechart import Axis 

def check_entropy(): 
    arg = ['cat', '/proc/sys/kernel/random/entropy_avail'] 
    ps = subprocess.Popen(arg,stdout=subprocess.PIPE) 
    return int(ps.communicate()[0]) 

def run(number_of_tests,resolution,entropy = []): 
    i = 0 
    while i < number_of_tests:   
     time.sleep(resolution) 
     entropy += [check_entropy()] 
     i += 1 
    graph(entropy,int(number_of_tests*resolution)) 

def graph(entropy,rng):  
    max_y = 200  
    chart = SimpleLineChart(600, 375, y_range=[0, max_y]) 
    chart.add_data(entropy) 
    chart.set_colours(['0000FF']) 
    left_axis = range(0, max_y + 1, 32) 
    left_axis[0] = 'entropy' 
    chart.set_axis_labels(Axis.LEFT, left_axis)  
    chart.set_axis_labels(Axis.BOTTOM,['time in second']+get_x_axis(rng)) 
    chart.download('line-stripes.png') 

def get_x_axis(rng): 
    global modnum   
    if len(filter(lambda x:x%modnum == 0,range(rng + 1)[1:])) > 10: 
     modnum += 1 
     return get_x_axis(rng) 
    return filter(lambda x:x%modnum == 0,range(rng + 1)[1:]) 

modnum = 1 
run(500,.1) 

Nếu chạy này và cũng chạy:

while 1 > 0: 
    gen_pass() 

Sau đó, tôi khá reliablly có được một đồ thị trông như thế này:

Làm đồ thị khi chạy cat /dev/urandom trông smiler và cat /dev/random giọt off để không có gì và vẫn thấp rất nhanh chóng (điều này cũng chỉ đọc ra như một byte mỗi 3 giây hoặc lâu hơn)

cập nhật

Nếu tôi chạy thử nghiệm tương tự nhưng với sáu trường hợp của gen_pass(), tôi có được điều này:

Vì vậy, có vẻ như một cái gì đó là làm cho nó là trường hợp mà tôi có đủ entropy. Tôi nên đo tốc độ tạo mật khẩu và đảm bảo rằng nó đang thực sự bị giới hạn, bởi vì nếu nó không phải là sau đó một cái gì đó fishy có thể đang xảy ra.

cập nhật

Tôi thấy điều này email chain

này nói rằng urandom sẽ ngừng kéo entropy khi hồ bơi chỉ có 128 bit trong đó. Điều này rất phù hợp với các kết quả trên và có nghĩa là trong các bài kiểm tra đó tôi thường xuyên tạo ra các mật khẩu rác.

Giả định của tôi trước đó là nếu entropy_avail đủ cao (nói trên 64 bit) thì đầu ra /dev/urnadom là tốt. Đây không phải là trường hợp có vẻ như là /dev/urandom được thiết kế để rời khỏi entropy thêm cho /dev/random trong trường hợp cần.

Bây giờ tôi cần phải tìm ra số lượng bit ngẫu nhiên thực mà một cuộc gọi SystemRandom cần.

Answer 1

Có sự khác biệt nhỏ giữa đầu ra của /dev/random và /dev/urandom. Như đã được chỉ ra, /dev/urandom không chặn. Đó là bởi vì nó nhận được kết quả từ một trình tạo số giả ngẫu nhiên, được tạo thành từ các số ngẫu nhiên 'thực' trong /dev/random.

Đầu ra của /dev/urandom sẽ hầu như luôn luôn là ngẫu nhiên - đó là một PRNG chất lượng cao với một hạt giống ngẫu nhiên. Nếu bạn thực sự cần một nguồn dữ liệu ngẫu nhiên tốt hơn, bạn có thể xem xét việc tạo một hệ thống với trình tạo số ngẫu nhiên phần cứng - netbook của tôi có VIA C7, nó có thể tạo ra khá nhiều dữ liệu ngẫu nhiên đúng cách. kb/s trong số/dev/random, 545kb/s trong số/dev/urandom).

Là một sang một bên, nếu bạn đang tạo mật khẩu thì bạn có thể muốn xem pwgen - nó làm cho mật khẩu phát âm tốt đẹp cho bạn :).

Answer 2

/dev/random/ sẽ chặn đọc nếu cần thêm entropy. /dev/urandom/ thì không. Vì vậy, có, nếu bạn sử dụng nó quá nhanh, bạn sẽ chạy thấp trên entropy. Có lẽ vẫn còn khá khó để đoán, tất nhiên, nhưng nếu bạn đang thực sự quan tâm bạn có thể đọc byte từ /dev/random/ thay thế. Lý tưởng nhất là, với vòng lặp đọc không chặn và chỉ báo tiến trình để bạn có thể di chuyển chuột xung quanh và tạo entropy nếu cần.

Answer 3

Bạn có thể muốn đọc về việc tại sao/dev/urandom là con đường để đi:

http://www.2uo.de/myths-about-urandom/