Czy SecureRandom wątek jest bezpieczny? To znaczy, po zainicjowaniu go, czy można uzyskać dostęp do następnego losowego numeru, aby był bezpieczny dla wątków? Badanie kodu źródłowego zdaje się wskazywać, że tak jest, i this bug report wydaje się wskazywać, że jego brak dokumentacji jako bezpiecznego wątku jest problemem javadoc. Czy ktoś potwierdził, że w rzeczywistości jest bezpieczny dla wątków?Czy bezpieczny wątek SecureRandom jest bezpieczny?
Tak, jest. Rozciąga Random, który zawsze miał faktyczną realizację threadsafe, a od Java 7, explicitly guarantees threadsafety.
Jeżeli wiele wątków są za pomocą pojedynczego SecureRandom, nie może być twierdzenie, że boli wydajność. Z drugiej strony inicjowanie instancji SecureRandom może być stosunkowo powolne. To, czy najlepiej jest dzielić się globalnym RNG, czy utworzyć nowy dla każdego wątku, będzie zależeć od twojej aplikacji. Klasa ThreadLocalRandom może być używana jako wzorzec do dostarczania rozwiązania obsługującego SecureRandom.
Tak. Jest całkowicie bezpieczny dla wątków. Właściwie to narzekałbym, że zamek jest zbyt agresywny. Całość engineNextBytes() jest zsynchronizowana.
Szczerze mówiąc, nie wiedziałbym, czy to nie jest bezpieczne. Zagadnienie wątków prawdopodobnie wprowadza więcej losowości :)
To * Bezpieczne * Losowe, bardzo ważne jest, aby używać go dokładnie. Nie sądzę, że wprowadza większą losowość. Na przykład. Bezpieczny losowy wątek może wytworzyć tę samą losową liczbę w kilku wątkach - może to oznaczać, że jeden wątek mógłby ukraść liczbę wygenerowaną dla innego wątku, może zostać wykorzystany przez hakera. – kan
Obecna implementacja SecureRandom jest bezpieczna dla wątków, w szczególności dwie metody mutowania nextBytes(bytes[]) i setSeed(byte[]) są zsynchronizowane.
Cóż, o ile mogłem powiedzieć, wszystkie metody mutacji są ostatecznie kierowane przez te dwie metody, i SecureRandom przesłania kilka metod w Random, aby to zapewnić. Który działa, ale może być kruchy, jeśli implementacja zostanie zmieniona w przyszłości.
Najpierw należy ręcznie przeprowadzić synchronizację na instancji SecureRandom. Oznacza to, że każdy stos wywołań zyska dwie blokady na tym samym obiekcie, ale zazwyczaj jest to bardzo tanie w nowoczesnych maszynach JVM. Oznacza to, że nie ma wiele szkód w jednoznacznym synchronizowaniu się. Na przykład:
SecureRandom rnd = ...;
byte[] b = new byte[NRANDOM_BYTES];
synchronized (rnd) {
rnd.nextBytes(b);
}
Dziękujemy za aktualizację. Dziwnie, błąd jest oznaczony jako zamknięty, "nie naprawi". Ale i tak to naprawili. No cóż, nie zazdroszczę im wielkości ich bazy danych błędów. – Yishai
Inicjalizacja 'SecureRandom' może być nie tylko powolna, ale może się zawiesić z powodu braku entropii –
@WalterTross Hang? Widziałem, że systemy zabierają 10 lub 15 minut, ale nigdy nie widziałem, żeby ktoś wisiał. Implementacja, która nie gwarantuje kontynuacji zasilania puli entropii, choć powoli, wydaje się być błędem w systemie operacyjnym. – erickson