RNGCryptoServiceProvider의 장단점

RNGCryptoServiceProvider의 장단점

---

사용의 장점과 단점은 무엇입니까 System.Security.Cryptography.RNGCryptoServiceProvider대는 System.Random. 나는 그것이 RNGCryptoServiceProvider'더 무작위 적' 이라는 것을 알고 있습니다. 즉, 해커에게는 덜 예측 가능합니다. 다른 장단점이 있습니까?

---

최신 정보:

응답에 따르면 RNGCryptoServiceProvider지금까지 사용하는 장단점은 다음과 같습니다.

장점

• RNGCryptoServiceProvider 더 강력한 암호화 난수이므로 암호화 키 등을 결정하는 데 더 적합합니다.

단점

• Random더 간단한 계산이기 때문에 더 빠릅니다. 암호화 임의성이 중요하지 않은 시뮬레이션 또는 긴 계산에 사용될 때이 방법을 사용해야합니다. 참고 : 시뮬레이션에 대한 자세한 내용 은 Kevin의 답변 을 참조하십시오. Random반드시 무작위가 아닌 다른 비 암호화 PRNG를 사용할 수도 있습니다.

---

강력한 암호화 기법 RNG는 더 많은 계산을 필요 --- 및 스펙트럼 흰색 수 있지만뿐만 아니라 시뮬레이션 또는 몬테 카를로 방법에 적합하지 않습니다, 그들은 모두 있기 때문에 --- 느립니다 할 시간이 더 걸릴, 그들은 수 있기 때문에 반복 할 수 없으므로 테스트에 좋습니다.

일반적으로 UUID와 같은 고유 번호를 원하거나 암호화를위한 키로 사용하고 속도와 시뮬레이션을 위해 결정적 PRNG를 사용하려는 경우 암호화 PRNG를 사용합니다.

---

System.Random 스레드로부터 안전하지 않습니다.

---

예, 하나만 더 있습니다. Charlie Martin이 쓴 것처럼 System.Random더 빠릅니다.

다음 정보를 추가하고 싶습니다.

는 RNGCryptoServiceProvider보안 표준을 준수 난수 발생기의 기본 구현입니다. 보안을 위해 랜덤 변수가 필요한 경우이 클래스 또는 동등한 클래스를 사용해야하지만 예측 가능성이 높으므로 System.Random을 사용하지 마십시오.

다른 모든 용도의 경우 더 높은 성능 System.Random과 동등한 클래스를 사용할 수 있습니다.

---

이전 답변 외에 :

System.Random부정확 한 시뮬레이션 결과 또는 수렴 실패로 인해 중대한 부정적인 결과가 발생하는 과학 및 공학용 시뮬레이션 또는 수치 솔버에 절대로 사용 해서는 안됩니다 . 이는 Microsoft의 구현이 여러 측면에서 심각한 결함이 있으며 호환성 문제로 인해 쉽게 수정할 수 없거나 수정하지 않을 것이기 때문입니다. 이 게시물을 참조하십시오  .

그래서:

• 생성 된 순서를 알고 shouldn't 공격자가 있으면 , 다음 사용 RNGCryptoServiceProvider또는 다른주의 깊게 설계, 구현 및 강력한 암호화 RNG를 확인하고, 이상적으로 사용하는 하드웨어 난수 가능한. 그렇지 않으면;

• 좋은 통계 속성이 필요한 시뮬레이션과 같은 응용 프로그램 인 경우 Mersenne Twister 와 같이 신중하게 설계되고 구현 된 비 암호화 PRNG를 사용하십시오 . (암호화 RNG는 이러한 경우 에도 정확 하지만 종종 너무 느리고 다루기 어렵습니다.)  그렇지 않으면;

• 무작위 슬라이드 쇼에서 다음에 표시 할 사진을 결정하는 것과 같이 숫자 사용이 완전히 사소한 경우 에만 을 사용하십시오System.Random.

---

나는 최근에 의료 기기에 대한 다양한 사용 패턴의 효과를 테스트하기위한 몬테카를로 시뮬레이션 작업을 할 때이 문제를 매우 명백하게 접했습니다. 시뮬레이션은 합리적으로 예상했던 것과 약간 반대 방향으로 가는 결과를 생성했습니다 .

때때로 당신이 무언가를 설명 할 수 없을 때, 그 뒤에 이유가 있고 그 이유는 매우 부담 스러울 수 있습니다!

다음 은 증가하는 시뮬레이션 배치에서 얻은 p 값의 플롯입니다 .

빨간색 및 자홍색 플롯은 연구중인 두 가지 출력 메트릭에서 두 사용 모델 간의 차이의 통계적 유의성을 보여줍니다.

The cyan plot is a particularly shocking result, because it represents p‑values for a characteristic of the random input to the simulation. (This was being plotted just to confirm the input wasnʼt faulty.) The input was, of course, by design the same between the two usage models under study, so there should not have been any statistically significant difference between the input to the two models. Yet here I was seeing better than 99.97% confidence that there was such a difference!!

Initially I thought there was something wrong in my code, but everything checked out. (In particular I confirmed that threads were not sharing System.Random instances.) When repeated testing found this unexpected result to be highly consistent, I started suspecting System.Random.

I replaced System.Random with a Mersenne Twister implementation — no other changes, — and immediately the output became drastically different, as shown here:

This chart reflects there being no statistically significant difference between the two usage models for the parameters being used in this particular test set. This was an expected result.

Note that in the first chart, the vertical log scale (on the p‑value) covers seven decades, whereas there is only a single decade in the second — demonstrating just how pronounced the statistical significance of the spurious discrepancies was! (The vertical scale indicates the probability the discrepancies could have arisen by chance.)

I suspect what was happening was that System.Random has some correlations over some fairly short generator cycle, and different patterns of internal randomness sampling between the two models under test (which had substantially different numbers of calls to Random.Next) caused these to affect the two models in distinct ways.

시뮬레이션 입력 은 모델이 내부 결정에 사용하는 것과 동일한 RNG 스트림에서 가져 오며, 이로 인해 이러한 샘플링 불일치가 입력에 영향을 미쳤습니다. (그렇지 않으면 예상치 못한 결과가 시뮬레이션되는 장치의 실제 속성이 아니라 소프트웨어 결함이라는 것을 깨닫지 못했을 수 있기 때문에 이것은 실제로 운이 좋았습니다!)

참고 URL : https://stackoverflow.com/questions/418817/pros-and-cons-of-rngcryptoserviceprovider