Làm thế nào để đối phó với một trình tạo SecureRandom chậm?

Nếu bạn muốn một số ngẫu nhiên mạnh về mật mã trong Java, bạn sử dụng SecureRandom. Thật không may, SecureRandomcó thể rất chậm. Nếu nó sử dụng /dev/randomtrên Linux, nó có thể chặn việc chờ đủ entropy để xây dựng. Làm thế nào để bạn tránh bị phạt hiệu suất?

Có ai đã sử dụng Toán học không phổ biến như một giải pháp cho vấn đề này chưa?

Bất cứ ai cũng có thể xác nhận rằng vấn đề hiệu năng này đã được giải quyết trong JDK 6?

Nếu bạn muốn dữ liệu ngẫu nhiên thực sự, thì thật không may, bạn phải chờ nó. Điều này bao gồm hạt giống cho một SecureRandomPRNG. Toán học không phổ biến không thể thu thập dữ liệu ngẫu nhiên thực sự nhanh hơn SecureRandom, mặc dù nó có thể kết nối với internet để tải xuống dữ liệu hạt giống từ một trang web cụ thể. Tôi đoán là điều này khó có thể nhanh hơn /dev/randomnơi có sẵn.

Nếu bạn muốn PRNG, hãy làm một cái gì đó như thế này:

SecureRandom.getInstance("SHA1PRNG");

Chuỗi nào được hỗ trợ tùy thuộc vào SecureRandomnhà cung cấp SPI, nhưng bạn có thể liệt kê chúng bằng cách sử dụng Security.getProviders()và Provider.getService().

Sun rất thích SHA1PRNG, vì vậy nó có sẵn rộng rãi. Nó không đặc biệt nhanh khi PRNG đi, nhưng PRNG sẽ chỉ là những con số khủng khiếp, không chặn được phép đo entropy vật lý.

Ngoại lệ là nếu bạn không gọi setSeed()trước khi nhận dữ liệu, thì PRNG sẽ tự khởi động lại ngay lần đầu tiên bạn gọi next()hoặc nextBytes(). Nó thường sẽ làm điều này bằng cách sử dụng một lượng khá nhỏ dữ liệu ngẫu nhiên thực sự từ hệ thống. Cuộc gọi này có thể chặn, nhưng sẽ làm cho nguồn số ngẫu nhiên của bạn an toàn hơn nhiều so với bất kỳ biến thể nào của "băm thời gian hiện tại cùng với PID, thêm 27 và hy vọng điều tốt nhất". Tuy nhiên, nếu tất cả những gì bạn cần là số ngẫu nhiên cho một trò chơi hoặc nếu bạn muốn luồng được lặp lại trong tương lai bằng cách sử dụng cùng một hạt giống cho mục đích thử nghiệm, thì một hạt giống không an toàn vẫn hữu ích.

Bạn sẽ có thể chọn nhóm / dev / urandom nhanh hơn nhưng hơi kém an toàn trên Linux bằng cách sử dụng:

-Djava.security.egd=file:/dev/urandom

Tuy nhiên, điều này không hoạt động với Java 5 trở lên ( Java Bug 6202721 ). Công việc được đề xuất là sử dụng:

-Djava.security.egd=file:/dev/./urandom

(lưu ý thêm /./)

Trên Linux, việc triển khai mặc định SecureRandomlà NativePRNG(mã nguồn ở đây ), có xu hướng rất chậm. Trên Windows, mặc định là SHA1PRNG, như những người khác đã chỉ ra, bạn cũng có thể sử dụng trên Linux nếu bạn chỉ định rõ ràng.

NativePRNGkhác với SHA1PRNGvà Uncommons Toán AESCounterRNG ở chỗ nó liên tục nhận được entropy từ hệ điều hành (bằng cách đọc từ /dev/urandom). Các PRNG khác không thu được bất kỳ entropy bổ sung nào sau khi gieo hạt.

AESC gặpRNG nhanh hơn khoảng 10 lần SHA1PRNG, mà IIRC tự nó nhanh hơn hai hoặc ba lần NativePRNG.

Nếu bạn cần một PRNG nhanh hơn để có được entropy sau khi khởi tạo, hãy xem bạn có thể tìm thấy một triển khai Java của Fortuna không . PRNG cốt lõi của việc triển khai Fortuna giống hệt với AESC gặpRNG được sử dụng, nhưng cũng có một hệ thống tinh vi của việc gộp chung entropy và tạo lại tự động.

Nhiều bản phân phối Linux (chủ yếu dựa trên Debian) định cấu hình OpenJDK để sử dụng /dev/randomcho entropy.

/dev/random là theo định nghĩa chậm (và thậm chí có thể chặn).

Từ đây bạn có hai tùy chọn về cách bỏ chặn nó:

1. Cải thiện entropy, hoặc
2. Giảm yêu cầu ngẫu nhiên.

Lựa chọn 1, Cải thiện entropy

Để có được thành entropy hơn /dev/random, hãy thử các haveged daemon. Đó là một trình nền liên tục thu thập entropy HAVEGE và cũng hoạt động trong môi trường ảo hóa vì nó không yêu cầu bất kỳ phần cứng đặc biệt nào, chỉ có CPU và đồng hồ.

Trên Ubuntu / Debian:

apt-get install haveged
update-rc.d haveged defaults
service haveged start

Trên RHEL / CentOS:

yum install haveged
systemctl enable haveged
systemctl start haveged

Tùy chọn 2. Giảm yêu cầu ngẫu nhiên

Nếu vì một lý do nào đó, giải pháp trên không giúp ích được gì hoặc bạn không quan tâm đến tính ngẫu nhiên mạnh về mật mã, bạn có thể chuyển sang /dev/urandomthay thế, điều này được đảm bảo không chặn.

Để thực hiện nó trên toàn cầu, hãy chỉnh sửa tệp jre/lib/security/java.securitytrong cài đặt Java mặc định của bạn để sử dụng /dev/urandom(do một lỗi khác mà nó cần phải được chỉ định là /dev/./urandom).

Như thế này:

#securerandom.source=file:/dev/random
securerandom.source=file:/dev/./urandom

Sau đó, bạn sẽ không bao giờ phải chỉ định nó trên dòng lệnh.

Lưu ý: Nếu bạn làm mật mã, bạn cần entropy tốt. Trường hợp điển hình - vấn đề PRNG android làm giảm tính bảo mật của ví Bitcoin.

Tôi gặp vấn đề tương tự với các cuộc gọi để SecureRandomchặn khoảng 25 giây một lần trên máy chủ Debian không đầu. Tôi đã cài đặt havegedtrình nền để đảm bảo /dev/randomluôn được cập nhật, trên các máy chủ không đầu, bạn cần một cái gì đó như thế này để tạo ra entropy cần thiết. Các cuộc gọi của tôi đến SecureRandombây giờ có lẽ mất một phần nghìn giây.

Nếu bạn muốn sự ngẫu nhiên thực sự "mạnh về mật mã", thì bạn cần một nguồn entropy mạnh. /dev/randomchậm vì phải chờ các sự kiện hệ thống thu thập entropy (đọc đĩa, gói mạng, di chuyển chuột, nhấn phím, v.v.).

Một giải pháp nhanh hơn là một bộ tạo số ngẫu nhiên phần cứng. Bạn có thể đã có sẵn một bo mạch chủ; kiểm tra tài liệu hw_random để biết hướng dẫn về việc tìm ra nếu bạn có nó và cách sử dụng nó. Gói công cụ rng bao gồm một trình nền sẽ cung cấp entropy được tạo bằng phần cứng /dev/random.

Nếu một HRNG không có sẵn trên hệ thống của bạn và bạn sẵn sàng hy sinh sức mạnh của entropy để thực hiện, bạn sẽ muốn tạo ra một PRNG tốt với dữ liệu từ đó /dev/randomvà để PRNG thực hiện phần lớn công việc. Có một số PRNG được NIST phê duyệt được liệt kê trong SP800-90 rất dễ thực hiện.

Sử dụng Java 8, tôi thấy rằng trên cuộc gọi Linux SecureRandom.getInstanceStrong()sẽ cung cấp cho tôi NativePRNGBlockingthuật toán. Điều này thường sẽ chặn trong nhiều giây để tạo ra một vài byte muối.

Tôi chuyển sang yêu cầu rõ ràng NativePRNGNonBlockingthay vào đó, và như mong đợi từ cái tên, nó không còn bị chặn nữa. Tôi không biết ý nghĩa bảo mật của việc này là gì. Có lẽ phiên bản không chặn không thể đảm bảo lượng entropy được sử dụng.

Cập nhật : Ok, tôi tìm thấy lời giải thích tuyệt vời này .

Tóm lại, để tránh bị chặn, hãy sử dụng new SecureRandom(). Điều này sử dụng /dev/urandom, không chặn và về cơ bản là an toàn như /dev/random. Từ bài đăng: "Lần duy nhất bạn muốn gọi / dev / ngẫu nhiên là khi máy khởi động lần đầu và entropy chưa được tích lũy".

SecureRandom.getInstanceStrong() mang lại cho bạn RNG mạnh nhất tuyệt đối, nhưng nó chỉ an toàn khi sử dụng trong các tình huống mà một loạt các chặn sẽ không ảnh hưởng đến bạn.

Có một công cụ (ít nhất là trên Ubuntu) sẽ cung cấp tính ngẫu nhiên nhân tạo vào hệ thống của bạn. Lệnh này chỉ đơn giản là:

rngd -r /dev/urandom

và bạn có thể cần một sudo ở phía trước. Nếu bạn không có gói công cụ rng, bạn sẽ cần cài đặt nó. Tôi đã thử điều này, và nó chắc chắn đã giúp tôi!

Nguồn: matt vs thế giới

Tôi phải đối mặt với cùng một vấn đề . Sau một số Google với các cụm từ tìm kiếm phù hợp, tôi đã xem qua bài viết hay này trên DigitalOcean .

hasged là một giải pháp tiềm năng mà không ảnh hưởng đến an ninh.

Tôi chỉ đơn thuần trích dẫn phần có liên quan từ bài viết ở đây.

Dựa trên nguyên tắc HAVEGE và trước đây dựa trên thư viện liên kết của nó, đã cho phép tạo tính ngẫu nhiên dựa trên các biến thể trong thời gian thực thi mã trên bộ xử lý. Vì gần như không thể để một đoạn mã có cùng thời gian thực thi, ngay cả trong cùng một môi trường trên cùng một phần cứng, thời gian chạy một hoặc nhiều chương trình phải phù hợp để tạo nguồn ngẫu nhiên. Việc triển khai đã tạo hạt giống nguồn ngẫu nhiên của hệ thống của bạn (thường là / dev / ngẫu nhiên) bằng cách sử dụng các khác biệt trong bộ đếm dấu thời gian của bộ xử lý (TSC) sau khi thực hiện lặp lại nhiều lần

Cách cài đặt

Thực hiện theo các bước trong bài viết này. https://www.digitalocean.com/community/tutorials/how-to-setup-additable-entropy-for-cloud-servers-USE-haveged

Tôi đã đăng nó ở đây

Vấn đề bạn tham khảo /dev/randomkhông phải ở SecureRandomthuật toán, mà là nguồn ngẫu nhiên mà nó sử dụng. Hai là trực giao. Bạn nên tìm ra cái nào trong hai cái đang làm bạn chậm lại.

Trang Toán học không phổ biến mà bạn liên kết rõ ràng đề cập rằng chúng không giải quyết nguồn gốc của sự ngẫu nhiên.

Bạn có thể thử các nhà cung cấp JCE khác nhau, chẳng hạn như BouncyCastle, để xem việc triển khai của họ SecureRandomcó nhanh hơn không.

Một tìm kiếm ngắn gọn cũng cho thấy các bản vá Linux thay thế việc triển khai mặc định bằng Fortuna. Tôi không biết nhiều về điều này, nhưng bạn có thể điều tra.

Tôi cũng nên đề cập rằng mặc dù rất nguy hiểm khi sử dụng SecureRandomthuật toán và / hoặc nguồn ngẫu nhiên được triển khai kém , bạn có thể cuộn Nhà cung cấp JCE của riêng mình với cách triển khai tùy chỉnh SecureRandomSpi. Bạn sẽ cần trải qua một quá trình với Sun để được nhà cung cấp của bạn ký hợp đồng, nhưng thực sự nó khá đơn giản; họ chỉ cần bạn fax cho họ một biểu mẫu cho biết bạn biết về các hạn chế xuất khẩu của Hoa Kỳ đối với các thư viện tiền điện tử.

Sử dụng ngẫu nhiên an toàn làm nguồn khởi tạo cho thuật toán định kỳ; bạn có thể sử dụng một twister Mersenne cho công việc hàng loạt thay vì một trong UncommonMath, đã xuất hiện được một thời gian và được chứng minh tốt hơn so với prng khác

http://en.wikipedia.org/wiki/Mersenne_twister

Đảm bảo làm mới ngay bây giờ và sau đó là ngẫu nhiên an toàn được sử dụng để khởi tạo, ví dụ: bạn có thể có một ngẫu nhiên an toàn được tạo cho mỗi khách hàng, sử dụng một trình tạo ngẫu nhiên giả ngẫu nhiên mersenne cho mỗi khách hàng, đạt được mức độ ngẫu nhiên đủ cao

Theo tài liệu này , các thuật toán khác nhau được SecureRandom sử dụng theo thứ tự ưu tiên:

• Trên hầu hết các hệ thống * NIX
  1. Bản địa
  2. SHA1PRNG
  3. Khóa bản địa
  4. NativePRNGNonBlocking
• Trên các hệ thống Windows
  1. SHA1PRNG
  2. Windows-PRNG

Vì bạn đã hỏi về Linux, tôi bỏ qua việc triển khai Windows và cả SunPKCS11 chỉ thực sự có sẵn trên Solaris, trừ khi bạn tự cài đặt nó - và sau đó bạn sẽ không hỏi điều này.

Theo những tài liệu tương tự, những thuật toán này sử dụng là gì

SHA1PRNG
Việc gieo hạt ban đầu hiện được thực hiện thông qua sự kết hợp của các thuộc tính hệ thống và thiết bị thu thập entropy java.security.

NativePRNG
nextBytes() sử dụng /dev/urandom
generateSeed()sử dụng/dev/random

NativePRNGBlocking
nextBytes() và generateSeed()sử dụng/dev/random

NativePRNGNonBlocking
nextBytes() và generateSeed()sử dụng/dev/urandom

Điều đó có nghĩa là nếu bạn sử dụng SecureRandom random = new SecureRandom(), nó sẽ đi xuống danh sách đó cho đến khi nó tìm thấy một hoạt động, thường sẽ là NativePRNG. Và điều đó có nghĩa là nó tự tạo hạt giống từ /dev/random(hoặc sử dụng nó nếu bạn tạo rõ ràng một hạt giống), sau đó sử dụng /dev/urandomđể nhận các byte, ints, double, booleans, what-have-yous tiếp theo.

Vì /dev/randomlà chặn (nó chặn cho đến khi nó có đủ entropy trong nhóm entropy), điều đó có thể cản trở hiệu suất.

Một giải pháp cho điều đó là sử dụng một cái gì đó như đã tạo ra đủ entropy, một giải pháp khác là sử dụng /dev/urandomthay thế. Mặc dù bạn có thể thiết lập điều đó cho toàn bộ jvm, một giải pháp tốt hơn là thực hiện nó cho trường hợp cụ thể này SecureRandombằng cách sử dụng SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking"). Lưu ý rằng phương thức đó có thể ném NoSuchAlerskymException nếu NativePRNGNonBlocking, vì vậy hãy chuẩn bị để dự phòng về mặc định.

SecureRandom random;
try {
    random = SecureRandom.getInstance("NativePRNGNonBlocking");
} catch (NoSuchAlgorithmException nsae) {
    random = new SecureRandom();
}

Cũng lưu ý rằng trên các hệ thống * nix khác, /dev/urandomcó thể hoạt động khác đi .

Là /dev/urandomđủ ngẫu nhiên?

Sự khôn ngoan thông thường có nó là chỉ /dev/randomđủ ngẫu nhiên. Tuy nhiên, một số tiếng nói khác nhau. Trong "Cách đúng để sử dụng SecureRandom" và "Huyền thoại về / dev / urandom" , người ta cho rằng điều đó /dev/urandom/cũng tốt như vậy.

Người dùng trên ngăn xếp Bảo mật thông tin đồng ý với điều đó . Về cơ bản, nếu bạn phải hỏi, /dev/urandomtốt cho mục đích của bạn.

Tôi đã không tự mình chống lại vấn đề này, nhưng tôi đã tạo ra một chuỗi khi bắt đầu chương trình ngay lập tức cố gắng tạo ra một hạt giống, sau đó chết. Phương thức mà bạn gọi cho randoms sẽ tham gia vào luồng đó nếu nó còn sống nên cuộc gọi đầu tiên chỉ chặn nếu nó xảy ra rất sớm trong quá trình thực thi chương trình.

Kinh nghiệm của tôi chỉ là khởi tạo PRNG chậm chứ không phải tạo dữ liệu ngẫu nhiên sau đó. Hãy thử một chiến lược khởi tạo háo hức hơn. Vì chúng rất tốn kém để tạo ra, hãy coi nó như một đĩa đơn và sử dụng lại cùng một ví dụ. Nếu có quá nhiều tranh chấp luồng cho một thể hiện, gộp chúng hoặc biến chúng thành luồng cục bộ.

Đừng thỏa hiệp về việc tạo số ngẫu nhiên. Một điểm yếu ở đó làm tổn hại tất cả an ninh của bạn.

Tôi không thấy nhiều máy phát điện dựa trên nguyên tử phân rã COTS, nhưng có một số kế hoạch cho chúng, nếu bạn thực sự cần nhiều dữ liệu ngẫu nhiên. Một trang web luôn có những điều thú vị để xem, bao gồm HotBits, là Fourmilab của John Walker's.

Có vẻ như bạn nên rõ ràng hơn về các yêu cầu RNG của bạn. Yêu cầu RNG mật mã mạnh nhất (theo tôi hiểu) sẽ là ngay cả khi bạn biết thuật toán được sử dụng để tạo chúng và bạn biết tất cả các số ngẫu nhiên được tạo trước đó, bạn không thể nhận được bất kỳ thông tin hữu ích nào về bất kỳ số ngẫu nhiên nào được tạo trong tương lai, mà không tốn một lượng sức mạnh tính toán không thực tế.

Nếu bạn không cần sự đảm bảo đầy đủ về tính ngẫu nhiên này thì có thể có sự đánh đổi hiệu suất phù hợp. Tôi có xu hướng đồng ý với phản hồi của Dan Dyer về AESC gặpRNG từ Uncommons-Maths hoặc Fortuna (một trong những tác giả của nó là Bruce Schneier, một chuyên gia về mật mã học). Tôi chưa bao giờ sử dụng nhưng những ý tưởng có vẻ có uy tín từ cái nhìn đầu tiên.

Tôi nghĩ rằng nếu bạn có thể tạo một hạt ngẫu nhiên ban đầu theo định kỳ (ví dụ một lần mỗi ngày hoặc mỗi giờ hoặc bất cứ điều gì), bạn có thể sử dụng một mật mã luồng nhanh để tạo các số ngẫu nhiên từ các đoạn liên tiếp của luồng (nếu mật mã luồng sử dụng XOR thì chỉ cần truyền vào một luồng null hoặc lấy trực tiếp các bit XOR). ECRYPT của eStreamdự án có rất nhiều thông tin tốt bao gồm cả điểm chuẩn hiệu suất. Điều này sẽ không duy trì entropy giữa các điểm mà bạn bổ sung kịp thời, vì vậy nếu ai đó biết một trong các số ngẫu nhiên và thuật toán bạn đã sử dụng, về mặt kỹ thuật có thể, với rất nhiều sức mạnh tính toán, để phá vỡ mật mã luồng và đoán trạng thái bên trong của nó để có thể dự đoán các số ngẫu nhiên trong tương lai. Nhưng bạn phải quyết định liệu rủi ro đó và hậu quả của nó có đủ để biện minh cho chi phí duy trì entropy hay không.

Chỉnh sửa: đây là một số ghi chú khóa học mật mã trên RNG tôi tìm thấy trên mạng 'trông rất phù hợp với chủ đề này.

Nếu phần cứng của bạn hỗ trợ, hãy thử sử dụng Java RdRand Utility mà tôi là tác giả.

Nó dựa trên RDRANDhướng dẫn của Intel và nhanh hơn khoảng 10 lần so với SecureRandomvà không có vấn đề về băng thông để thực hiện khối lượng lớn.

Lưu ý rằng việc triển khai này chỉ hoạt động trên các CPU cung cấp hướng dẫn (nghĩa là khi rdrandcờ bộ xử lý được đặt). Bạn cần phải khởi tạo nó một cách rõ ràng thông qua hàm RdRandRandom()tạo; không có cụ thể Providerđã được thực hiện.

Một cái gì đó khác để xem xét là thuộc tính securandom.source trong tệp lib / security / java.security

Có thể có một lợi ích hiệu suất khi sử dụng / dev / urandom thay vì / dev / ngẫu nhiên. Hãy nhớ rằng nếu chất lượng của các số ngẫu nhiên là quan trọng, đừng tạo ra sự thỏa hiệp làm mất an ninh.