BigInteger의 .isProbablePrime ()의 가능한 사용 사례는 무엇입니까?

방법BigInteger.isProbablePrime() 은 아주 이상합니다. 문서에서 이것은 숫자가 확률로 소수인지 여부를 알려줍니다 . 1 - 1 / 2^arg여기서는 arg정수 인수입니다.

JDK에 꽤 오랫동안 존재 해 왔기 때문에 반드시 사용해야합니다. 컴퓨터 과학과 알고리즘 (및 수학)에 대한 나의 제한된 지식은 숫자가 "아마도"소수인지 정확히 소수인지 아닌지를 아는 것이 실제로 의미가 없다는 것을 말해줍니다.

그렇다면이 방법을 사용하려는 가능한 시나리오는 무엇입니까? 암호화?

예,이 방법은 암호화에 사용할 수 있습니다. RSA 암호화 는 때때로 1024 비트 (약 300 자리) 정도의 거대한 소수를 찾는 것을 포함합니다. RSA의 보안은 이러한 소수 중 2 개를 곱한 숫자를 인수 분해하는 것이 매우 어렵고 시간이 많이 소요된다는 사실에 달려 있습니다. 그러나 그것이 작동하기 위해서는 그들이 프라임이어야합니다.

이 숫자가 소수임을 증명하는 것도 어렵다는 것이 밝혀졌습니다. 그러나에서 사용하는 소수 검정 중 하나 인 Miller-Rabin 소수 검정isProbablePrime 은 숫자가 복합인지 또는 결론을 제공하지 않음을 감지합니다. 이 테스트 n시간을 실행하면 이 숫자가 실제로 합성 될 확률이 ^{2n 분} 의 1이라는 결론을 내릴 수 있습니다 . 이를 실행 100시간은 2 (1)의 허용 가능한 위험을 산출한다 ⁽¹⁰⁰⁾ 이 복합 수 있음을.

테스트 결과 정수가 소수 가 아니라고 표시 되면 100 %라고 확신 할 수 있습니다.

테스트에서 정수가 "가능한 소수"라고 말하면 의심을 품을 수 있습니다. 다양한 "베이스"로 테스트를 반복하면 소수 (다중 염기에 대해 강력한 의사 프라임이 됨)를 "모방"하는 데 잘못된 성공 확률을 원하는만큼 작게 만들 수 있습니다.

테스트의 유용성은 속도와 단순성에 있습니다. 최종 답변으로 "가능한 소수"의 상태에 반드시 만족할 필요는 없지만 소수성 테스트의 큰 총을 가져 오기 전에이 루틴 을 사용하여 거의 모든 합성 숫자에 시간을 낭비하는 것을 피할 수 있습니다.

정수 인수 분해의 어려움에 대한 비교는 붉은 청어와 같습니다. 정수의 소수성은 다항식 시간에 결정될 수 있으며 실제로 Miller-Rabin 테스트를 충분히 많은 염기로 확장하는 것이 결정적이라는 증거가 있습니다 (가능한 소수와 반대로 소수를 감지). Generalized Riemann Hypothesis를 가정하므로 (더 비싼) AKS 소수성 검정 만큼 확실하지 않습니다 .

의 표준 사용 사례 BigInteger.isProbablePrime(int)는 암호화입니다. 특히 RSA 와 같은 특정 암호화 알고리즘 에는 무작위로 선택된 큰 소수가 필요합니다. 그러나 중요하게도 이러한 알고리즘은이 숫자 가 소수 가되도록 보장 할 필요가 없습니다 . 매우 높은 확률 로 소수 여야 합니다.

얼마나 높습니까? 음, 암호화 응용 프로그램에서 일반적으로 .isProbablePrime()128에서 256 사이의 인수를 사용하여 호출합니다. 따라서 비 프라임 번호가 이러한 테스트를 통과 할 확률은 2 ¹²⁸ 또는 2 ²⁵⁶ 중 1 미만 입니다.

이를 관점에서 살펴 보겠습니다. 컴퓨터가 100 억 대이고 각 컴퓨터가 초당 100 억 개의 가능한 소수 (최신 CPU에서 숫자 당 1 클럭주기 미만을 의미 함)를 생성하고 해당 숫자의 소수를으로 테스트 한 .isProbablePrime(128)경우 평균적으로 1 천억 년 에 한 번씩 소수가 아닌 숫자가 한 번씩 빠져 나갈 것으로 예상 합니다.

즉, 즉, 사건이 될 것입니다 경우 그 100 억 컴퓨터 수 어떻게 든 경험이없는 수십억 년의 수백에 대한 모든 실행 어떤 하드웨어 오류를. 그러나 실제로 는 임의의 우주선이 적절한 시간과 장소에 컴퓨터를 공격하여.isProbablePrime(128) 다른 감지 가능한 효과를 유발하지 않고 반환 값 을 거짓에서 참 으로 뒤집을 가능성이 훨씬 더 높습니다. 그 확실성 수준에서 확률 적 소수성 테스트를 실제로 통과하는 소수.

물론 무작위 우주선 및 기타 하드웨어 결함의 동일한 위험이 AKS 와 같은 결정 론적 소수성 테스트에도 적용됩니다 . 따라서 실제로 이러한 테스트조차도 임의의 하드웨어 오류로 인해 (매우 작은) 기준 오 탐률이 있습니다 (구현 버그와 같은 다른 모든 가능한 오류 원인은 말할 것도 없음).

테스트를 충분히 여러 번 반복하여 사용 된 Miller-Rabin 소수성 테스트 의 본질적인 위양성 비율을 .isProbablePrime()이 기준 비율보다 훨씬 아래로 내리는 것이 쉽기 때문에, 여러 번 반복해도 Miller-Rabin 테스트는 여전히 AKS와 같이 가장 잘 알려진 결정 론적 소수성 테스트보다 실제로 훨씬 빠르며 암호화 응용 프로그램의 표준 소수성 테스트로 남아 있습니다.

(게다가 실수로 RSA 계수의 요소 중 하나로 강력한 유사 프라임을 우연히 선택한 경우에도 일반적으로 치명적인 오류가 발생하지는 않습니다. 일반적으로 이러한 유사 프라임은 약 길이의 절반, 즉 멀티 프라임 RSA 키로 끝날 것임을 의미합니다 . 인자가 너무 작지 않은 한 ( 프라임 테스트가이를 포착 했어야 함) RSA 알고리즘은 여전히 잘 작동하며, 같은 길이의 일반 RSA 키보다 특정 유형의 공격에 대해 다소 약하지만 키 길이를 불필요하게 줄이지 않으면 키는 여전히 상당히 안전해야합니다.)

가능한 사용 사례는 주어진 숫자의 소수성을 테스트하는 것입니다 (그 자체로 많은 용도가있는 테스트에서). isProbablePrime알고리즘은 숫자가 실패 그렇다면, 훨씬 더 빨리 정확한 알고리즘에 비해 실행 isProbablePrime한 후 하나 개의 필요가 더 비싼 알고리즘을 실행하는 비용에 가지.

가능한 소수를 찾는 것은 암호화에서 중요한 문제입니다. 가능한 k 비트 소수를 찾기위한 합리적인 전략은 임의의 k 비트 숫자를 반복적으로 선택하고 isProbablePrime().

더 자세한 내용 은 Handbook of Applied Cryptography의 섹션 4.4.1을 참조하십시오 .

또한 Brandt 및 Damgård의 증분 검색에 의한 가능한 소수 생성을 참조하십시오 .

RSA 키 생성과 같은 알고리즘은 숫자가 소수인지 아닌지를 결정할 수있는 능력에 의존합니다.

그러나이 isProbablePrime방법이 JDK에 추가 된 시점 (1997 년 2 월)에는 숫자가 합리적인 시간 내에 소수인지 여부를 결정적으로 결정할 수있는 입증 된 방법이 없었습니다. 당시 가장 잘 알려진 접근 방식은 Miller-Rabin 알고리즘 이었습니다. 확률 론적 알고리즘은 때때로 오탐 (즉, 프라임이 아닌 것을 소수로보고)을 제공하지만 비용을 들여 오탐 가능성을 줄 이도록 조정할 수 있습니다. 런타임이 약간 증가합니다.

그 이후로 2002 년 8 월에 발견 된 AKS 알고리즘 과 같이 숫자가 합리적으로 신속하게 소수인지 여부를 결정 론적으로 결정할 수있는 알고리즘 이 발견되었습니다. 그러나 이러한 알고리즘은 여전히 ​​Miller-Rabin만큼 빠르지 않습니다.

더 좋은 질문은 isPrime2002 년 이후 JDK에 메소드가 추가 되지 않은 이유 일 것 입니다.