Khi chúng tôi thiết kế PRNG bằng mật mã, chúng tôi không chỉ muốn vượt qua các bài kiểm tra thống kê. Tiêu chuẩn vàng ở đây là bài kiểm tra bit tiếp theo, cho biết rằng với tất cả đầu ra cho đến một điểm nhất định, việc đoán bit tiếp theo chỉ dễ dàng hơn không đáng kể. Đây không phải là một bài kiểm tra thống kê, mà là một bài kiểm tra ngụ ý rằng kẻ tấn công có đầy đủ kiến thức về thuật toán và khả năng phân tích mã hóa nó, nhưng vẫn không thể tìm ra giải pháp tốt hơn so với vũ phu.
Để hiển thị một ví dụ về CSPRNG không an toàn có thể vượt qua bất kỳ bài kiểm tra thống kê nào nhưng sẽ không vượt qua bài kiểm tra bit tiếp theo, hãy tưởng tượng một hạt giống bí mật $S$, một hàm băm an toàn $ H(x) $và một PRNG xuất ra $H(S) || H(H(S)) || H(H(H(S))) || ... $. Vì hàm băm của chúng ta được bảo mật nên đầu ra của nó xuất hiện ngẫu nhiên, nhưng trên thực tế rất dễ đoán đầu ra tiếp theo dựa trên đầu ra hiện có.
Tất nhiên, hoàn toàn có thể tạo một CSPRNG xuất ra các byte đơn tại một thời điểm. RC4 là mật mã dòng có thiết kế này và đã được sử dụng CSPRNG trong nhiều hệ thống, mặc dù nó không còn được coi là an toàn nữa. Chúng tôi cũng có thể thiết kế các CSPRNG khác an toàn và hướng theo byte. Tuy nhiên, trên thực tế, hoạt động trên các khối dữ liệu lớn hơn thường hiệu quả hơn, đó là lý do tại sao các thuật toán như ChaCha20 hoặc NIST DRBG có xu hướng được sử dụng thường xuyên hơn.
Đối với lợi ích của PRNG nhanh không mã hóa, có rất ít lý do để sử dụng chúng. ChaCha20 có thể xuất dữ liệu với tốc độ 3 GB/giây trên hệ thống của tôi và nó được bảo mật bằng mật mã. Trong trường hợp không chắc là tốc độ này không đủ nhanh, số lượng vòng nhỏ hơn có thể được sử dụng (ví dụ: ChaCha12) và hiệu suất sẽ tốt hơn trong khi vẫn được bảo mật bằng mật mã. Việc tạo số ngẫu nhiên bằng thuật toán phù hợp hầu như không bao giờ là nút cổ chai, do đó, sử dụng CSPRNG, sẽ luôn vượt qua bài kiểm tra bit tiếp theo và do đó có chất lượng cao nhất có thể, là đủ trong hầu hết các trường hợp.
