Một số chap nói như sau:

Tất cả những ai cố gắng tạo ra các số ngẫu nhiên bằng các phương tiện xác định, tất nhiên, sống trong tình trạng tội lỗi.

Điều đó luôn có nghĩa là bạn không thể tạo ra các số ngẫu nhiên thực sự chỉ bằng một máy tính. Và ông nói rằng khi máy tính có kích thước tương đương với một bộ vi xử lý Intel 8080 (~ 6000 van). Máy tính đã trở nên phức tạp hơn và tôi tin rằng tuyên bố của von Von Neumann có thể không còn đúng nữa. Xem xét rằng một thuật toán chỉ thực hiện phần mềm là không thể. Họ chạy trên phần cứng vật lý. Các bộ tạo số ngẫu nhiên thực sự và các nguồn entropy của chúng cũng được làm bằng phần cứng.

Đoạn Java này được đặt vào một vòng lặp:

      file.writeByte((byte) (System.nanoTime() & 0xff));

có thể tạo một tệp dữ liệu mà tôi đã thể hiện dưới dạng hình ảnh:

Bạn có thể thấy cấu trúc, nhưng với rất nhiều sự ngẫu nhiên là tốt. Điều đáng quan tâm là tệp PNG này có kích thước 232KB, nhưng chứa 250.000 pixel tỷ lệ xám. Mức nén PNG là tối đa. Đó chỉ là tỷ lệ nén 7%, tức là. khá không nén được. Điều thú vị là tập tin này là duy nhất. Mỗi thế hệ của tệp này là một mẫu hơi khác nhau và có độ nén ~ 7% tương tự. Tôi nhấn mạnh điều này vì nó quan trọng đối với lập luận của tôi. Đó là entropy ~ 7 bit / byte. Điều đó sẽ giảm tất nhiên khi sử dụng thuật toán nén mạnh hơn. Nhưng không giảm xuống bất cứ thứ gì gần 0 bit / byte. Một ấn tượng tốt hơn có thể có được bằng cách chụp ảnh trên và thay thế bản đồ màu của nó cho ngẫu nhiên: -

Hầu hết các cấu trúc (ở nửa trên) biến mất vì nó chỉ là chuỗi các giá trị tương tự nhưng khác biệt nhỏ. Đây có phải là một nguồn entropy thực sự được tạo ra chỉ bằng cách thực hiện một chương trình Java trên một hệ điều hành đa lấy? Không phải là một trình tạo số ngẫu nhiên phân phối đồng đều, nhưng nguồn entropy cho một? Một nguồn entropy được xây dựng bằng phần mềm chạy trên phần cứng vật lý chỉ là PC.

Bổ sung

Để xác nhận rằng mọi hình ảnh đều tạo ra entropy mới mà không có mẫu cố định chung cho tất cả, 10 hình ảnh liên tiếp đã được tạo. Chúng sau đó được nối và nén với trình lưu trữ mạnh nhất mà tôi có thể biên dịch (paq8px). Quá trình này sẽ loại bỏ tất cả các dữ liệu phổ biến, bao gồm cả tương quan tự động chỉ để lại các thay đổi / entropy.

Tệp được nối được nén tới ~ 66%, dẫn đến tốc độ entropy ~ 5,3 bit / byte hoặc 10,5Mbit / hình ảnh. Một số lượng đáng ngạc nhiên của entropy $\smile$

Bổ sung 2

Đã có ý kiến ​​tiêu cực rằng entropy của tôi bằng phương pháp thử nghiệm nén là thiếu sót, chỉ đưa ra một ước tính ràng buộc trên lỏng lẻo. Vì vậy, bây giờ tôi đã chạy tệp được nối bằng thử nghiệm đánh giá entropy mật mã chính thức của NIST, SP800-90B_EntropyAssessment . Điều này cũng tốt như đối với phép đo entropy không IID. Đây là báo cáo (xin lỗi câu hỏi này đang kéo dài, nhưng vấn đề rất phức tạp): -

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
    Correct: 3816
    P_avg (global): 0.00397508
    P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag 

Test: 100% complete
    Correct: 3974
    P_avg (global): 0.00413607
    P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
    Correct: 3913
    P_avg (global): 0.00407383
    P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
    Correct: 3866
    P_avg (global): 0.00402593
    P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735

Kết quả là NIST tin rằng tôi đã tạo ra 5,6 bit / byte entropy. Ước tính nén DIY của tôi đặt mức này ở mức 5,3 bit / byte, bảo thủ hơn một chút.

-> Bằng chứng dường như ủng hộ quan niệm rằng một máy tính chỉ chạy phần mềm có thể tạo ra entropy thực sự. Và rằng von Neumann đã sai (nhưng có lẽ đúng với thời gian của ông).

Tôi cung cấp các tài liệu tham khảo sau có thể hỗ trợ cho yêu cầu của tôi: -

Có bất kỳ mô hình ngẫu nhiên nào về tính không xác định trong tỷ lệ thực hiện chương trình không?

Phân tích WCET của các hệ thống thời gian thực cứng xác suất

Có một thuật toán phần mềm có thể tạo ra một mô hình hỗn loạn không xác định? và sự liên quan của hiệu ứng hỗn loạn.

Song song với nguyên lý bất định entropic lượng tử

Mục blog của Mitchsey Shipilёv liên quan đến hành vi hỗn loạn của nanoTime (). Âm mưu phân tán của anh ta không giống với tôi.

Chỉ vì bạn không thể thấy một mẫu không có nghĩa là không có mẫu nào tồn tại. Chỉ vì thuật toán nén không thể tìm thấy một mẫu không có nghĩa là không có mẫu nào tồn tại. Các thuật toán nén không phải là những viên đạn bạc có thể đo lường một cách kỳ diệu entropy thực sự của một nguồn; tất cả những gì họ cung cấp cho bạn là giới hạn trên của số lượng entropy. (Tương tự, bài kiểm tra NIST cũng chỉ cung cấp cho bạn giới hạn trên.) Hỗn loạn không phải là ngẫu nhiên.

Phải mất một phân tích và kiểm tra chi tiết hơn để bắt đầu có được sự tự tin về chất lượng ngẫu nhiên thu được theo cách này.

Có nhiều lý do để nghĩ rằng chúng ta có thể có được một số lượng ngẫu nhiên bằng cách khai thác jitter đồng hồ và sự trôi dạt giữa hai đồng hồ phần cứng , nhưng nó tinh tế và khó khăn, vì vậy bạn phải cẩn thận. Tôi không khuyên bạn nên cố gắng thực hiện của riêng bạn. Thay vào đó, tôi sẽ đề nghị bạn sử dụng một nguồn entropy chất lượng cao (thường được thực hiện trong hầu hết các hệ điều hành hiện đại). Để biết thêm chi tiết, xem thêm Wikipedia , đã đánh dấu và /crypto//q/483023531 (có vẻ như bạn đã biết).

Cuối cùng, một nhận xét về người mở của bạn:

"Bất cứ ai cố gắng tạo ra các số ngẫu nhiên bằng các phương tiện xác định, tất nhiên, sống trong tình trạng tội lỗi."

Điều đó luôn có nghĩa là bạn không thể tạo ra các số ngẫu nhiên thực sự chỉ bằng một máy tính.

Không, đó không phải là cách nó thường được thực hiện, và đó không phải là những gì nó đang nói. Điều đó nói rằng bạn không thể tạo ra các số ngẫu nhiên thực sự bằng các phương tiện xác định . Việc bạn có thể làm điều đó trên máy tính hay không phụ thuộc vào việc máy tính có mang tính quyết định hay không. Nếu máy tính có tính xác định hoặc chương trình của bạn chỉ sử dụng các thao tác xác định, bạn không thể. Tuy nhiên, nhiều máy tính chứa các yếu tố không xác định và nếu chương trình của bạn sử dụng chúng, cần phân tích chi tiết hơn trước khi bạn có thể quyết định liệu chúng có thể được sử dụng để tạo số ngẫu nhiên hay không. Trong trường hợp của bạn nanoTime()là không xác định.

Nếu bạn đang sử dụng một số nguồn entropy / ngẫu nhiên phần cứng, thì bạn không "cố gắng tạo ngẫu nhiên bằng các phương tiện xác định " (nhấn mạnh của tôi). Nếu bạn không sử dụng bất kỳ nguồn entropy / ngẫu nhiên phần cứng nào, thì một máy tính mạnh hơn chỉ có nghĩa là bạn có thể phạm nhiều tội hơn mỗi giây.

Tôi luôn hiểu câu trích dẫn có nghĩa là thuật toán xác định có lượng entropy cố định và mặc dù đầu ra có thể xuất hiện "ngẫu nhiên" nhưng nó không thể chứa nhiều entropy hơn đầu vào cung cấp. Từ quan điểm này, chúng tôi thấy rằng thuật toán của bạn nhập lậu vào entropy thông qua System.nanoTime()- hầu hết các định nghĩa của thuật toán "xác định" sẽ không cho phép gọi hàm này.

Các trích dẫn - trong khi pithy - về cơ bản là một tautology. Không có gì để từ chối và không có sự phát triển nào về phần cứng có thể khiến nó không còn đúng nữa. Đó không phải là về phần cứng, đó là về định nghĩa của một thuật toán xác định. Anh ta chỉ đơn giản là quan sát rằng tính quyết định và tính ngẫu nhiên là không tương thích. Đối với bất kỳ thuật toán xác định nào, toàn bộ hành vi của nó được dự đoán bởi các điều kiện bắt đầu của nó. Nếu bạn nghĩ rằng bạn đã tìm thấy một ngoại lệ, bạn sẽ hiểu nhầm ý nghĩa của nó là xác định.

Đúng là một quá trình chạy trên một máy tính dùng chung với một loạt bộ nhớ cache phức tạp và nhận được nhiều đầu vào mạng và phần cứng khác nhau có quyền truy cập nhiều entropy hơn so với chạy trên phần cứng đơn giản, chuyên dụng. Nhưng nếu quá trình đó truy cập vào entropy đó thì nó không còn mang tính quyết định và vì vậy trích dẫn không được áp dụng.

Tất cả những ai cố gắng tạo ra các số ngẫu nhiên bằng các phương tiện xác định, tất nhiên, sống trong tình trạng tội lỗi.

Khi bạn diễn giải "sống trong tình trạng tội lỗi" là "làm những điều vô nghĩa", thì điều đó hoàn toàn đúng.

Những gì bạn đã làm là sử dụng một phương pháp khá chậm System.nanoTime()để tạo ra sự ngẫu nhiên khá yếu. Bạn đo một số

... tốc độ entropy ~ 5,3 bit / byte ...

nhưng đây chỉ là giới hạn trên. Tất cả những gì bạn có thể nhận được là một giới hạn trên. Entropy thực có thể là các đơn đặt hàng có cường độ nhỏ hơn.

Thay vào đó, hãy thử điền vào mảng bằng cách sử dụng hàm băm mật mã như MD5. Tính một chuỗi nhưmd5(0), md5(1), ... (từ mỗi giá trị được lấy một hoặc nhiều byte, điều này không thành vấn đề). Bạn sẽ không bị nén chút nào (vâng, MD5 bị hỏng, nhưng vẫn đủ tốt để tạo ra dữ liệu không thể nén được).

Chúng tôi có thể nói rằng không có entropy nào cả, nhưng bạn đo được 8 bit / byte.

Khi bạn thực sự cần một cái gì đó ngẫu nhiên, bạn không chỉ phải sử dụng nguồn CTNH, bạn còn phải biết chắc chắn thấp hơn về mức độ entropy mà nó thực sự tạo ra. Trong khi có lẽ có một số ngẫu nhiên trongnanoTime() , tôi không biết về bất kỳ thứ gì không tầm thường ràng buộc vào nó.

Khi bạn cần sự ngẫu nhiên cho mật mã, thì bạn thực sự phải dùng đến thứ gì đó được cung cấp bởi HĐH, ngôn ngữ của bạn hoặc một thư viện tốt. Các nhà cung cấp như vậy thu thập entropy từ nhiều nguồn và / hoặc CT chuyên dụng và một số công việc đã được đưa vào các ước tính entropy như vậy.

Lưu ý rằng bạn thường không cần bất kỳ entropy nào. Một PRNG tốt (xác định) được khởi tạo với một vài byte ngẫu nhiên có thể sử dụng cho mật mã, và do đó cũng cho mọi thứ khác.

Tôi nghĩ tôi muốn nói về ý nghĩa của "ngẫu nhiên". Hầu hết các câu trả lời ở đây đang nói về đầu ra của các quá trình ngẫu nhiên , so với đầu ra của các quá trình xác định. Đó là một ý nghĩa hoàn toàn tốt của "ngẫu nhiên", nhưng nó không phải là duy nhất.

Một vấn đề với đầu ra của các quy trình ngẫu nhiên là chúng khó phân biệt với đầu ra của các quy trình xác định: chúng không chứa "bản ghi" về mức độ ngẫu nhiên của nguồn. Một ví dụ cực đoan về điều này là một truyện tranh XKCD nổi tiếng , nơi một trình tạo số ngẫu nhiên luôn trả về 4, với một nhận xét mã cho rằng đó là ngẫu nhiên vì nó đến từ một cuộn chết.

Một cách tiếp cận khác để định nghĩa "tính ngẫu nhiên", được gọi là độ phức tạp Kolmogorov , dựa trên chính dữ liệu, bất kể nó được tạo ra như thế nào. Độ phức tạp Kolmogorov của một số dữ liệu (ví dụ: dãy số) là độ dài của chương trình máy tính ngắn nhất tạo ra dữ liệu đó: dữ liệu "ngẫu nhiên hơn" nếu độ phức tạp Kolmogorov cao hơn.

Việc bạn sử dụng các thuật toán nén như PNG và so sánh độ dài trước và sau khi nén, tương tự như ý tưởng về độ phức tạp Kolmogorov. Tuy nhiên, độ phức tạp Kolmogorov cho phép dữ liệu được mã hóa dưới dạng chương trình trong bất kỳ ngôn ngữ lập trình hoàn chỉnh Turing nào, thay vì định dạng giới hạn như PNG; "Giải nén" các mã hóa (chương trình) như vậy được thực hiện bằng cách chạy chúng, việc này có thể mất một lượng thời gian và bộ nhớ tùy ý (ví dụ: nhiều hơn khả dụng trong vũ trụ trừng phạt của chúng ta).

Định lý Rice nói với chúng ta rằng, nói chung, chúng ta không thể phân biệt giữa các chương trình lặp lại mãi mãi và các chương trình xuất dữ liệu của chúng ta. Do đó, rất khó để tìm thấy độ phức tạp Kolmogorov của một số dữ liệu: nếu chúng ta viết ra một chương trình tạo ra dữ liệu đó, thực sự có thể có một chương trình ngắn hơn (nghĩa là độ phức tạp thấp hơn), nhưng chúng ta đã không phát hiện ra vì chúng ta không thể phân biệt nó với một vòng lặp vô hạn. Do đó, độ phức tạp Kolmogorov là không thể tính toán được , mặc dù nếu chúng ta biết các số Busy-Beaver, chúng ta có thể tính toán nó bằng cách sử dụng chúng để ràng buộc lượng thời gian mà chúng ta kiểm tra mỗi chương trình.

Trong trường hợp dữ liệu mẫu của bạn, để tìm độ phức tạp Kolmogorov của nó (tức là "tính ngẫu nhiên nội tại"), chúng ta sẽ cần tìm chương trình xác định ngắn nhất tạo ra chuỗi byte tương tự và lấy độ dài của nó.

Bây giờ chúng tôi có thể trả lời câu hỏi của bạn từ quan điểm về độ phức tạp Kolmogorov và chúng tôi thấy rằng trích dẫn là chính xác: chúng tôi không thể tạo ra các số ngẫu nhiên (độ phức tạp Kolmogorov cao) bằng phương pháp xác định.

Tại sao không? Hãy tưởng tượng rằng chúng ta viết một chương trình máy tính nhỏ và chúng ta sử dụng nó để tạo ra một chuỗi các số ngẫu nhiên. Một trong những tình huống sau đây phải được áp dụng:

• Chúng tôi tạo ra một lượng lớn sản lượng. Tuy nhiên, vì chúng ta biết rằng đầu ra này được tạo ra bởi một chương trình nhỏ, đầu ra (theo định nghĩa) có độ phức tạp Kolmogorov thấp, và do đó nó không "ngẫu nhiên" theo nghĩa này.
• Chúng tôi tạo ra rất ít số mà việc viết tất cả chúng sẽ mất cùng một hoặc thậm chí ít hơn so với việc viết ra chương trình tạo ngắn của chúng tôi. Trong trường hợp này, các con số tương đối không thể nhấn được, điều này cho thấy chúng khá ngẫu nhiên theo nghĩa Kolmogorov. Tuy nhiên, vì lượng đầu ra tương đương với những gì chúng tôi đưa vào (mã nguồn của chương trình), thật công bằng khi nói rằng chương trình không "tạo ra" sự ngẫu nhiên, chúng tôi đã làm bằng cách chọn chương trình đó. Rốt cuộc, trong trường hợp này, chương trình tạo của chúng tôi cũng có thể chỉ là một danh sách các số chính xác này (ví dụ print([...])).

Trong cả hai trường hợp, chúng tôi không "tạo ra" tính ngẫu nhiên nhiều hơn mức chúng tôi đưa vào ("tính ngẫu nhiên" của mã nguồn chương trình tạo của chúng tôi). Chúng tôi có thể cố gắng khắc phục điều này bằng cách sử dụng chương trình tạo dài hơn, để tránh đầu ra có trình tạo ngắn, nhưng chỉ có hai cách để làm điều đó:

• Một cách có hệ thống "phình to" mã theo một cách nào đó. Tuy nhiên, độ phức tạp Kolmogorov không quan tâm đến chương trình cụ thể mà chúng tôi đã sử dụng để tạo dữ liệu: nó chỉ quan tâm đến bất kỳ chương trình tạo nào là nhỏ nhất. Sự phình to có hệ thống không thêm độ phức tạp Kolmogorov, bởi vì các mẫu như vậy trong mã có thể được tạo ra với một lượng mã rất nhỏ. Ví dụ: nếu chúng ta lấy run(shortGenerator)và thêm toàn bộ tải trọng hệ thống cần lấy run(bloatedGenerator), một trình tạo ngắn vẫn tồn tại ở dạng run(addBloat(shortGenerator)).
• Thêm sự phình to một cách không có hệ thống , tức là không có bất kỳ mẫu nào, do đó, một addBloathàm sẽ phải hoàn toàn giống như mã. Tuy nhiên, việc không có các mẫu chính xác là điều làm cho một cái gì đó ngẫu nhiên (độ phức tạp Kolmogorov cao). Do đó làm đầy chương trình tạo theo cách này làm tăng tính ngẫu nhiên (độ phức tạp Kolmogorov) của đầu ra, nhưng nó cũng làm tăng lượng ngẫu nhiên (độ phức tạp Kolmogorov) mà chúng ta phải cung cấp dưới dạng mã nguồn. Do đó, vẫn là chúng tôi, những người đang cung cấp "tính ngẫu nhiên" chứ không phải chương trình. Trong ví dụ trên về việc chỉ viết print([...]), thêm sự phình to không có hệ thống tương đương với việc chỉ viết thêm các số "ngẫu nhiên" trong danh sách được mã hóa cứng đó.

Nén không phải là một thử nghiệm chính xác về tính ngẫu nhiên, và cũng không nhìn vào một hình ảnh và nói "trông có vẻ ngẫu nhiên".

Tính ngẫu nhiên được kiểm tra bằng phương pháp thực nghiệm . Trên thực tế, có các bộ phần mềm / thuật toán được thiết kế đặc biệt để kiểm tra tính ngẫu nhiên, ví dụ TestU01 và các thử nghiệm Diehard .

Hơn nữa, hình ảnh của bạn trên thực tế là một chuỗi số 1D được ánh xạ lên một khoảng trắng, và do đó không phải là sự thể hiện tốt các mẫu nhất định có thể xuất hiện.

Nếu bạn kiểm tra pixel hình ảnh của mình theo pixel, rất có thể bạn sẽ tìm thấy nhiều mẫu ngắn có giá trị tăng trước khi giảm đột ngột. Nếu bạn định tạo một biểu đồ với giá trị x là số mẫu và giá trị y là giá trị thu được từ hàm 'ngẫu nhiên', rất có thể bạn sẽ thấy rằng dữ liệu của bạn trên thực tế trông giống như sóng răng cưa:

Đây là mô hình được tạo bởi các giá trị tăng theo số học mô-đun (mà tính toán của bạn là một ví dụ về: thời gian tăng với tốc độ gần như không đổi và & 0xFF đóng vai trò là mod 256).

Bạn đang nhầm lẫn khái niệm số ngẫu nhiên từ "số có vẻ là ngẫu nhiên".

Để hiểu được trích dẫn của von Neumann, chúng ta phải hiểu ý nghĩa của việc "tạo ra các số ngẫu nhiên". Câu trả lời của Warbo liên kết một XKCD xuất sắc đến cuối này:

Khi chúng ta nói về các số ngẫu nhiên, chúng ta không nói về các giá trị. Rõ ràng số 4 không ngẫu nhiên hơn số 3. Chúng ta đang nói về khả năng khả năng dự đoán giá trị này của bên thứ ba tốt hơn cơ hội ngẫu nhiên. Một số ngẫu nhiên là một số không dự đoán được. Đôi khi chúng ta sẽ thêm điều kiện này. Trình tạo số giả ngẫu nhiên được bảo mật bằng mật mã (CSPRNG) tạo ra các số không thể dự đoán được đặt cược hơn cơ hội ngẫu nhiên nếu kẻ tấn công không biết hạt giống / khóa, nhưng nếu chúng ta đang nói về các số thực sự ngẫu nhiên (không phải giả ngẫu nhiên), nó thường được định nghĩa là một số không thể dự đoán được, ngay cả với kiến ​​thức đầy đủ về hệ thống, bao gồm bất kỳ khóa nào.

Bây giờ, ví dụ của bạn, như nhiều người đã chỉ ra, không mang tính quyết định. Chương trình không chỉ định giá trị nào phát sinhSystem.nanoTime() . Do đó, nó không cùng loại với việc sử dụng CSPRNG để tạo các số ngẫu nhiên giả. Cái trước có thể là không xác định trong khi cái sau là xác định nếu giá trị của khóa là xác định. Cái trước chứa các hoạt động không được xác định là có giá trị xác định.

Tuy nhiên, bạn sẽ lưu ý rằng tôi đã nói nó có thể không đặc biệt. Xin lưu ý rằng System.nanoTime()không được thiết kế để cung cấp các giá trị cho mục đích này. Nó có thể hoặc không đủ không đặc biệt. Một ứng dụng có thể điều chỉnh đồng hồ hệ thống sao cho các cuộc gọi đến System.nanoTime()tất cả xảy ra trên bội số 256 nano giây (hoặc đóng). Hoặc bạn có thể đang làm việc trong Javascript, nơi các khai thác gần đây của Spectre đã khiến các trình duyệt lớn cố tình giảm độ phân giải của bộ định thời của họ. Trong những trường hợp này, "số ngẫu nhiên" của bạn có thể trở nên dễ đoán trước trong các môi trường mà bạn không có kế hoạch.

• Vì vậy, tạo số ngẫu nhiên với các quá trình xác định ... tội lỗi.
• Tạo số ngẫu nhiên với phần cứng ngẫu nhiên chuyên dụng ... không phải tội lỗi.
• Tạo số ngẫu nhiên với các khía cạnh không xác định của máy tính ... có thể là tội lỗi.

Tất cả phụ thuộc vào những gì bạn dự định. Nếu bạn đang mã hóa thư tình của mình cho Sponge Bob để em gái bạn không thể đọc chúng, thì những yêu cầu đặt ra cho cái gọi là số ngẫu nhiên của bạn là khá thấp. System.nanoTime()sử dụng như bạn đã làm có lẽ là đủ tốt. Nếu bạn đang bảo vệ bí mật hạt nhân chống lại một quốc gia nước ngoài tiên tiến đang tích cực tìm kiếm chúng, bạn có thể muốn xem xét sử dụng phần cứng được thiết kế để đáp ứng thách thức.

Tôi không nghĩ rằng bạn đã hiểu yêu cầu bồi thường. Vấn đề là nếu có một quy trình xác định để tạo ra một chuỗi số 'ngẫu nhiên' (hoặc bất cứ thứ gì, thực sự), thì việc tìm ra mẫu chỉ đơn thuần là nhiệm vụ tìm kiếm thủ tục này!

Do đó, luôn tồn tại một phương pháp xác định để dự đoán số nguyên tiếp theo. Đây chính xác là những gì chúng ta không mong đợi xảy ra nếu chúng ta giả sử ngẫu nhiên!

Bất kỳ tính xác định đủ phức tạp là không thể phân biệt với ngẫu nhiên.

- Từ trang người dùng của Wrzlprmft

Do đó, ngay cả khi một cái gì đó trông ngẫu nhiên, tại sao trên trái đất chúng ta sẽ mô hình hóa nó là 'ngẫu nhiên' nếu chúng ta có một quy trình xác định để tạo ra nó?

Điều này, tôi nghĩ, là vấn đề chính. Bạn chỉ thể hiện một số dạng không thể phân biệt của PRNG và 'tính ngẫu nhiên thực sự'.

Tuy nhiên, những khái niệm này do đó không bằng nhau. Trong đó, ngẫu nhiên là một khái niệm toán học, lý thuyết . Chúng tôi đã chỉ ra ở trên, về lý thuyết, coi PRNG là "sự ngẫu nhiên thực sự" dẫn đến một mâu thuẫn. Do đó, chúng không thể bằng nhau.

Tôi nghĩ rằng những người khác đã chỉ ra điều đó, nhưng nó không nhấn mạnh, vì vậy tôi cũng thêm vào cuộc thảo luận.

Như những người khác đã chỉ ra, có vấn đề đo entropy. Các thuật toán nén có thể cho bạn biết một cái gì đó, nhưng chúng là bất khả tri về nguồn. Vì bạn biết nhiều hơn về cách dữ liệu được tạo ra, có lẽ bạn có thể hiểu một thuật toán tốt hơn nhiều để nén nó, và điều đó có nghĩa là entropy thực sự thấp hơn nhiều.

Hơn nữa, bạn đang hiểu nhầm ý nghĩa của cụm từ "trên máy tính" và "xác định". Bạn chắc chắn có thể thực hiện thao tác không xác định trên máy tính.

Hơn nữa, trên thực tế, bạn chỉ cần làm điều đó , nhưng nó không rõ ràng ngay từ cái nhìn đầu tiên.

Một thuật toán xác định điển hình cho việc tạo số ngẫu nhiên là nghĩa là. PRNG giống như máy phát đồng quy tuyến tính. Họ là nhà nước. Trạng thái bên trong có nghĩa là ít entropy hơn vì trạng thái tiếp theo được xác định bởi trước đó. Tôi sẽ không hiểu về điều đó, nó có thể rõ ràng với bạn. Điểm quan trọng là thuật toán xác định đầy đủ chỉ phụ thuộc vào trạng thái trước đó, bất kể nó sẽ là gì.

Bây giờ hãy nhìn vào thuật toán của bạn. Nó dựa trên cái gì? Bạn có bao nhiêu nhà nước? Là nó quyết định?

  file.writeByte((byte) (System.nanoTime() & 0xff));

Chúng ta hãy bỏ qua file.writevà bất kỳ vấn đề nào về bộ đệm xả, chờ I / O (bạn đã thử thêm tiếng ồn lớn vào cáp cứng trong giây lát chưa? Không? Hey bạn có thể làm điều đó không Hãy tập trung vào nguồn, nó quan trọng hơn.

Thời gian là một loại của một nhà nước. Nó khác nhau, nhưng hầu hết là như nhau. Đó là lý do tại sao bạn cố gắng phá vỡ nó và lấy & 0xFF để giảm nhiều nhất trạng thái. Nhưng bạn đã không bỏ qua tất cả, một số trạng thái của lần đọc trước có thể bị rò rỉ sang lần tiếp theo, vì vậy nó chắc chắn không hoàn toàn không xác định *)

Nhưng chúng tôi không quan tâm đến điều đó. Để "chứng minh" rằng trích dẫn là sai:

Tất cả những ai cố gắng tạo ra các số ngẫu nhiên bằng các phương tiện xác định, tất nhiên, sống trong tình trạng tội lỗi.

Bạn cần phải chứng minh nó bằng một phương tiện xác định.
Điều chúng tôi quan tâm là: liệu thuật toán của bạn có chắc chắn hoàn toàn quyết định không?

.. và rõ ràng là không phải vậy.

  System.nanoTime() & 0xff

Đó là một phép đo thời gian. Thời gian và đo lường . Phần đo có thể làm cho nó xác định, nếu giá trị được lưu trữ. Tôi cho rằng nó không phải, nếu không chức năng này sẽ không có ý nghĩa. Sau đó, nếu nó được đọc nhanh chóng từ nguồn, chúng ta có giá trị dựa trên thời gian. Vì ( tôi một lần nữa giả định ) bạn đã không chạy nó trên một phần cứng dành riêng cho một tác vụ, nên đôi khi bạn có thể bị đá chuyển ngữ cảnh. Ngay cả khi bạn có một phần cứng chuyên dụng duy nhất, đo thời gian vẫn có thể không mang tính quyết định, do nhiệt độ / độ ẩm trôi trong nguồn thời gian, thời gian chạy xe buýt, v.v.

Tôi hoàn toàn đồng ý rằng tôi đang ở đây. Những chiếc xe tải sẽ không lớn đến mức tạo ra nhiều ảnh hưởng (mặc dù thực tế nanotimechúng có thể). Quan trọng hơn, nanotimecó nghĩa là phải nhanh chóng. Nó không đọc từ nguồn thời gian thực. Nó dựa trên số chỉ dẫn / chu kỳ bên trong của bộ xử lý. Điều đó thực sự mang tính quyết định, nếu bạn đảm bảo không có chuyển đổi ngữ cảnh.

Quan điểm của tôi là, có thể rất khó để chạy một thuật toán xác định thực sự 100% nếu bạn căn cứ đúng thời gian và bạn không có quyền từ chối trích dẫn đó trừ khi bạn có phương tiện xác định đầy đủ.

*) Thật thú vị, bạn có thể có thể tăng sự ngẫu nhiên thực tế nếu bạn đi theo cách khó khăn. Làm & 0x01, từng chút một và luồng - chờ một thời gian đáng chú ý, trước khi đọc từng bit. Việc tạo dữ liệu theo cách đó sẽ kéo dài một cách nực cười, nhưng tôi thực sự sẽ cho rằng nó có thể được coi là gần như thực sự ngẫu nhiên, IIF bạn đang chạy trên phi RTOS và IFF trong mỗi 'thời gian đáng chú ý' đủ cao để đảm bảo rằng bên dưới Hệ điều hành đã đi ngủ hoặc chuyển sang ngữ cảnh sang một nhiệm vụ khác.

Tôi nghĩ rằng câu trả lời bạn cần bắt đầu với nhận xét này, chính bạn đã đưa ra để trả lời một câu trả lời khác:

Mẫu này là kết quả của sự tương tác giữa Java, JVM, HĐH, CPU + bộ nhớ cache, đĩa cứng, nhạc Trance tôi đang phát trực tuyến tiêu thụ chu kỳ CPU / RAM và mọi thứ ở giữa. Mẫu đơn giản phát sinh từ một dòng mã Java bên trong một vòng lặp for / next. Một phần quan trọng của entropy đến từ các mạch phần cứng cơ bản.

Bạn đã nhận ra điều này, tôi nghĩ: bạn đã không sử dụng các phương tiện xác định để tạo ra mô hình.

Bạn đã sử dụng máy tính, một phần không đáng kể trong số đó là xác định, nhưng entropy đến từ các nguồn không xác định bên ngoài (hoặc ít nhất, không xác định cho tất cả các mục đích và mục đích thực tế tại thời điểm này): bạn hoặc thế giới bên ngoài tương tác với máy tính (và ở mức độ thấp hơn, bất kỳ sự không hoàn hảo vật lý nào trong phần cứng máy tính có thể ảnh hưởng đến thời gian của mọi thứ).

Nhân tiện, đây là một phần lớn trong cách các hệ điều hành hiện đại gieo mầm cho các bộ tạo số ngẫu nhiên có sẵn cho các chương trình: bằng cách khai thác entropy trong các tương tác với phần cứng của nó và người dùng mà chúng tôi hy vọng không thể đoán trước được kẻ tấn công.

Nhân tiện, entropy thế giới bên ngoài thực sự là một vấn đề phải được xử lý cho đến ngày nay trong mật mã được mã hóa tốt: các máy tính có hành vi có thể dự đoán đượckhi khởi động và trong thời gian chạy, chẳng hạn như những thiết bị có bộ nhớ chỉ đọc hoặc khởi động từ mạng và có môi trường mạng có thể dự đoán được (không được gắn vào mạng hoặc khối lượng công việc trên mạng đủ thấp để mọi thứ được phân phối trong một lượng thời gian đáng tin cậy) và chạy cùng một bộ phần mềm hạn chế với hành vi gần như nhất quán, có thể ước tính quá mức entropy mà chúng nhận được từ các thành phần giả định không thể đoán trước này và cuối cùng tạo ra những con số dễ đoán hơn nhiều hơn là bạn có trên một trạm làm việc điển hình đang làm tất cả các loại công cụ khác cho bạn (phát nhạc, đồng bộ hóa với dropbox, bất cứ thứ gì) trong nền.

Tôi nghĩ rằng hầu hết các câu trả lời đang tập trung vào việc kiểm tra tám bit đo thời gian cuối cùng tính bằng nano giây được thực hiện trong một vòng lặp có phải là một cách tốt để thu hoạch entropy đó hay không. Đây là một câu hỏi rất quan trọng để trả lời đúng trước khi bạn sử dụng phương pháp trong ví dụ của bạn như một sơ đồ tạo số ngẫu nhiên trong thực tế , nhưng đó là một câu hỏi riêng biệt với những gì tôi nghĩ bạn đang hỏi về.

Để thêm vào các câu trả lời trước đây, đây là một cách dễ dàng để suy nghĩ về câu hỏi này.

Đó là tất cả về sự khác biệt giữa ngẫu nhiên và xác định . Chúng ta sẽ đến Von Neumann và những gì anh ấy đã nói sau đó.

Số ngẫu nhiên

Một trình tạo số ngẫu nhiên thực sự sẽ không có mẫu, thậm chí không bị ẩn trong nền, mà chúng ta có thể sử dụng để dự đoán số tiếp theo được đưa ra cho đến nay. Trong một thế giới lý tưởng, bạn có thể biết mọi thứ cần biết trong vũ trụ vật lý, và về hệ thống, nano giây tính bằng nano giây, và sẽ vẫn vô dụng khi thử và dự đoán số tiếp theo được tạo ra.

Đó là một trường hợp lý tưởng - về mặt thực tế, chúng tôi đạt được điều đó bằng cách trộn lẫn nhiều nguồn "không phải là xấp xỉ xấu" với ngẫu nhiên, hoặc thực sự ngẫu nhiên, hoặc kết hợp một cách toán học đủ để bạn có thể chứng minh rằng chúng rất gần với toán học và thiếu thiên vị cho bất kỳ số lượng hoặc mẫu cụ thể.

• Các nguồn "tốt" là những thứ tương tự như chờ đợi quá trình phân rã phóng xạ hoặc quá trình lượng tử khác vốn không thể đoán trước được. Đầu ra từ một chất bán dẫn nhạy cảm với nhiệt. Tiếng ồn ngẫu nhiên trong một diode hoặc vật liệu điện khác. Đếm các photon từ mặt trời.

• Kết hợp với điều này, chúng tôi cũng có thể thêm một số thứ mà chúng tôi cho là "không tệ" giúp ích vì chúng không có bất kỳ kết nối nào với chúng: Chờ đợi gói mouseclick hoặc gói mạng tiếp theo. Cuối cùng của microtime trên tập tin tiếp theo ghi. Đầu ra của hàm tạo số giả ngẫu nhiên "đã biết nhưng khá ngẫu nhiên". Entropy trước từ sử dụng số ngẫu nhiên trước đó.

Mục đích ở đây, là để có được một con số mà vẫn không thể dự đoán được , bất cứ điều gì trong vũ trụ mà bạn biết , và có khả năng thống kê như thế này, không có mô hình toán học, thiên vị hoặc dự đoán có thể phát hiện được về mặt toán học, và không có mối tương quan nào với một sự kiện có thể được theo dõi và sử dụng để dự đoán. (Hoặc nếu tương quan với một sự kiện, thì nó được thực hiện theo cách làm cho kết nối trở nên cực kỳ khó khăn, chẳng hạn như "chỉ số nano giây chỉ sau lần nhấp chuột cuối cùng")

Số xác định

Các nhà toán học có thể chứng minh những điều về công thức và chức năng. Vì vậy, có thể chứng minh rằng một hàm, khi được gọi liên tục, sẽ không đưa ra bất kỳ sự thiên vị hoặc ưu tiên nào cho bất kỳ mẫu nào, ngoài mẫu đơn giản "đây là các đầu ra của hàm đó nếu được gọi liên tục".

Vì vậy, ví dụ, nếu bạn chọn một số có giá trị từ 1 đến 10 triệu, hãy viết số đó thành nhị phân và "băm" nó nhiều lần, bạn sẽ nhận được một chuỗi các chữ số trông khá ngẫu nhiên. Nó gần như ngẫu nhiên - nhưng thực sự không phải là ngẫu nhiên. Bạn có thể dự đoán được đưa ra thuật toán và bất kỳ trạng thái nào, số tiếp theo sẽ là gì.

Chúng tôi gọi nó là "giả danh" bởi vì nó có vẻ và chủ yếu là ngẫu nhiên, ngay cả khi nó không phải là.

Đây là một ví dụ tốt. Hãy suy nghĩ về chuỗi "số ngẫu nhiên" gồm 3 chữ số: 983, 367, 336, 244, 065, 664, 308, 602, 139, 494, 639, 522, 473, 719, 070, 217. Hãy nói rằng tôi nói với bạn Tôi có thể tạo ra một triệu số theo cùng một cách. Sau đó, bạn có thể chuyển cho một nhà thống kê, người sẽ xác nhận (nói) rằng chúng được phân phối đều hoặc bất cứ điều gì có thể. Không có mô hình dự đoán rõ ràng. Chúng trông khá ngẫu nhiên, phải không? Nhưng bây giờ tôi nói với bạn rằng họ thực sự

chữ số thứ 500 + của Pi, được nhóm lại trong 3 giây.

Đột nhiên, tuy nhiên ngẫu nhiên

chữ số của Pi

có thể, bạn có thể dự đoán ngay rằng 2 số tiếp theo sẽ là 986 và 094.

Để rõ ràng, tôi không biết chính xác làm thế nào ngẫu nhiên

chữ số của Pi

là Nó sẽ được nghiên cứu và câu trả lời nổi tiếng. Nhưng vấn đề là ở chỗ: Về nguyên tắc, kết luận tương tự là đúng đối với bất kỳ nguồn nào được tạo ra theo quy trình xác định .

Ở giữa

Ở giữa hai, là một loạt các "điều trông ngẫu nhiên và thường ngẫu nhiên ở một mức độ nào đó". Càng nhiều ngẫu nhiên và gần ngẫu nhiên người ta có thể trộn lẫn, đầu ra càng ít có khả năng có bất kỳ mẫu nào được phát hiện hoặc bất kỳ đầu ra nào được dự đoán, về mặt toán học.

Quay lại với von Neumann và câu hỏi của bạn

Như bạn có thể thấy, các đầu ra xác định có thể trông ngẫu nhiên, nhưng thậm chí, có thể được phân phối ngẫu nhiên. Họ thậm chí có thể sử dụng dữ liệu "bí mật" hoặc thay đổi nhanh mà chúng ta không có hy vọng thực tế để biết. Nhưng miễn là nó mang tính quyết định, các con số vẫn không bao giờ thực sự là ngẫu nhiên . Họ chỉ có thể "đủ gần đến ngẫu nhiên mà chúng tôi rất vui khi quên đi sự khác biệt".

Đó là ý nghĩa của trích dẫn bạn đã đưa ra. Một quá trình xác định chỉ không thể đưa ra số ngẫu nhiên. Nó chỉ có thể đưa ra những con số có vẻ như và hoạt động khá giống những con số ngẫu nhiên.

Bây giờ chúng ta có thể viết lại câu hỏi của bạn như thế này: "Đầu ra của máy tính của tôi (hoặc bất kỳ hiện đại) nào có thể nhìn và hành xử hoàn toàn ngẫu nhiên, điều đó có nghĩa là trích dẫn của von Neumann đã lỗi thời và không chính xác?"

Vấn đề vẫn là đây: Ngay cả khi đầu ra của máy tính của bạn có thể nhìn và hoạt động ngẫu nhiên, nó vẫn có thể không thực sự ngẫu nhiên . Nếu nó chỉ được tính toán một cách xác định, điều đó có nghĩa là không có gì không phải là nguyên nhân gây ra hậu quả về gettinbg cho số tiếp theo (nghĩa là "xác định" theo nghĩa này). Chúng tôi bắt đầu với một số dữ liệu hiện có (đã biết), chúng tôi áp dụng một quy trình đã biết (phức tạp hoặc lộn xộn hoặc bất cứ điều gì) và chúng tôi nhận được những gì có vẻ như là một "số ngẫu nhiên" mới. Nhưng nó không phải là ngẫu nhiên, bởi vì quá trình này mang tính quyết định.

Nếu bạn nói rằng phương pháp của bạn sẽ bao gồm một trình tạo ngẫu nhiên phần cứng thực sự, để khắc phục điều đó (như một số ngẫu nhiên được tạo ra từ sự phân rã phóng xạ hoặc tiếng ồn trong chất bán dẫn), thì giờ đây câu trả lời của bạn có thể là ngẫu nhiên - nhưng phương pháp của bạn theo định nghĩa không còn mang tính quyết định , chính xác bởi vì bạn không thể dự đoán các đầu ra (hoặc hiệu ứng) được cung cấp cho đầu vào / dữ liệu ban đầu (nguyên nhân) nữa .

Von Neumann thắng cả hai cách, gần như theo định nghĩa!