☰

/dev/random과 /dev/urandom을 사용하는 경우

tag-icon • tag-icon devices random
/dev/random과 /dev/urandom을 사용하는 경우

/dev/random또는 을 사용해야 합니까 /dev/urandom?

어떤 상황에서 다른 것보다 하나를 선호합니까?

답변1

긴 이야기 짧게

/dev/urandom가장 실용적인 목적 으로 .

더 긴 대답은 실행 중인 Unix의 종류에 따라 다릅니다.

리눅스

역사적으로 /dev/random그들은 /dev/urandom동시에 출시되었습니다.

@DavidSchwartz가 지적했듯이댓글에서, /dev/urandom대부분의 경우 선호됩니다. 그와 다른 사람들은 훌륭한 작품에 대한 링크도 제공합니다.에 관한 신화/dev/urandom추가 읽기를 위해 추천하는 기사입니다.

간단히 말해서:

  • 이것맨페이지오해의 소지가 있습니다.
  • 둘 다 만든 사람동일한 CSPRNG무작위성 생성(그림 2 및 그림 3)
  • /dev/random엔트로피가 소진되면 차단되므로 읽기로 인해 /dev/random프로세스 실행이 중지될 수 있습니다.
  • 엔트로피의 크기는 보수적으로 추정되지만 계산에는 포함되지 않습니다.
  • /dev/urandom절대 차단하지 마세요.
  • 드문 경우지만, 시작 직후,CSPRNG엔트로피가 충분하지 않아 적절하게 시딩할 수 없으며 /dev/urandom고품질의 무작위성이 생성되지 않을 수 있습니다.
  • CSPRNG가 처음에 올바르게 시드된 경우 엔트로피가 낮은 것은 문제가 되지 않습니다.
  • CSPRNG는 지속적으로 다시 시드됩니다.
  • Linux 4.8 이상에서는 /dev/urandom엔트로피 풀(by /dev/random)이 고갈되지 않지만 업스트림 CSPRNG 출력이 사용됩니다.
  • 사용 /dev/urandom.

규칙의 예외

Cryptozoology 스택 교환에Linux에서 /dev/randomover를 사용해야 하는 경우/dev/urandom @otus두 가지 사용 사례가 제공됩니다.:

  1. 낮은 엔트로피 장치에서 부팅한 직후, 적절한 시드를 위한 충분한 엔트로피가 생성되지 않은 경우 /dev/urandom.

  2. 정보이론적 보안으로 일회용 패드 생성

(1)이 걱정된다면,사용 가능한 엔트로피 확인/dev/random.

(2)를 해보시면 아실 거예요 :)

참고: 다음을 수행할 수 있습니다./dev/random 블록에서 읽는지 확인하세요.하지만 가능한 경쟁 조건에 유의하세요.

대안: 둘 다 사용하지 마세요!

@otus도 지적했어요getrandom()/dev/urandom시스템은 초기 시드 엔트로피를 사용할 수 없는 경우에만 읽고 차단합니다.

가지다/dev/urandom사용 문제 변경getrandom()/dev/xrandom하지만 이를 기반으로 새로운 장치를 만드는 것도 가능합니다 getrandom().

애플 시스템

상관없어 왜냐하면 위키피디아는 말한다:

macOS는 160비트를 사용합니다.톱풀SHA1을 기반으로 합니다. /dev/random과 /dev/urandom 사이에는 차이가 없습니다. 둘 다 동일하게 동작합니다. Apple의 iOS도 Yarrow를 사용합니다.

FreeBSD

상관없어 왜냐하면위키피디아는 말한다:

/dev/urandom링크만 있으면 /dev/random제대로 시드될 때까지만 차단됩니다.

이는 부팅 후 FreeBSD가 끝없는 임의의 장점 스트림을 제공하기 전에 충분한 시드 엔트로피가 수집될 때까지 기다릴 만큼 똑똑하다는 것을 의미합니다.

네트워크BSD

적절한 초기 시딩을 보장하기 위해 /dev/urandom시스템이 최소한 한 번 읽었다고 가정하고 를 사용하십시오 ./dev/random

이것rnd(4) 맨페이지에는 다음과 같은 내용이 있습니다.:

/dev/urandom절대 차단하지 마세요.

/dev/random때로는 차단됩니다. 시스템 상태가 예측 가능한 것으로 알려진 경우 시작 시 조기에 차단됩니다.

/dev/urandom애플리케이션은 시뮬레이션을 위한 암호화 키나 시드와 같이 무작위로 생성된 데이터가 필요할 때 읽어야 합니다.

시스템은 인터넷과 통신하거나 /dev/random예측 가능한 키 생성을 피하기 위해 암호화가 필요한 서비스를 실행하기 전에 시작부터 적어도 한 번은 현명하게 읽을 수 있도록 설계되어야 합니다.

답변2

이것은 일종의 "나도" 답변이지만 Tom Hale의 권장 사항을 강화합니다. Linux에서 완전히 작동합니다.

  • 사용/dev/urandom
  • 사용하지 마세요/dev/random

Linux Kernel Crypto 메일링 리스트의 Theodore Ts'o에 따르면 /dev/random이 버전은 10년 동안 더 이상 사용되지 않습니다. ~에서Re: [RFC PATCH v12 3/4] Linux 난수 생성기:

실제로 /dev/random을 사용하는 사람은 없습니다. 이는 본질적으로 더 이상 사용되지 않는 인터페이스입니다. 10년 넘게 권장되는 기본 인터페이스는 /dev/urandom이었으며 이제는 getrandom(2)입니다.

정기적으로 테스트 /dev/random하지만 자주 고장이 납니다. 이 테스트는 세 단계를 수행합니다. (1) /dev/random비차단 모드에서 10K 바이트를 요청하여 소진합니다. (2) 차단 모드에서 16바이트를 요청합니다. (3) 청크를 압축하여 무작위인지 확인합니다(가난한 사람의 테스트). 테스트를 완료하는 데 몇 분 정도 걸립니다.

rng-tools이 문제는 Debain 시스템(i686, x86_64, ARM 및 MIPS)에서 너무 심각하여 GCC Compile Farm 의 테스트 시스템에 이 패키지를 설치하도록 요청했습니다 . ~에서gcc67 및 gcc68에 rng-tools 설치:

gcc67 및 gcc68에 rng-tools 설치를 요청하고 싶습니다. 이는 Debian 시스템이며 /dev/random은 장치를 사용하여 라이브러리를 테스트할 때 rng-tools가 없으면 엔트로피 소모로 인해 어려움을 겪습니다.

BSD와 OS X는 괜찮아 보입니다. 문제는 확실히 Linux에 있습니다.

Linux는 생성기 오류를 기록하지 않는다는 점도 언급할 가치가 있습니다. 그들은 이러한 항목이 시스템 로그를 채우는 것을 원하지 않습니다. 현재까지 대부분의 결함은 조용하고 대부분의 사용자가 감지하지 못했습니다.

커널이 적어도 하나의 실패 메시지를 인쇄하므로 이는 빠르게 변경됩니다. ~에서[패치] 무작위: 컴파일러 경고를 무음으로 하고 경합을 수정합니다.커널 암호화 메일링 리스트:

특히, 나는 depends on DEBUG_KERNEL이러한 유용한 경고가 다른 커널 개발자를 짜증나게 할 뿐이라는 것을 의미합니다. 이것이 바로 우리가 원하는 것일 수도 있습니다. 다양한 관련 개발자가 특정 하위 시스템에서 경고가 표시되면 문제를 해결하려는 동기가 더 커집니다. 일반 사용자는 DEBUG_KERNEL을 사용하지 않으므로 배포 커널의 일반 사용자는 경고나 스팸 메시지를 전혀 볼 수 없습니다.

모든 메시지를 억제하는 것은 보안 엔지니어링 관점에서 나쁜 생각이라고 생각합니다.

많은 사람들이 디버그 커널을 실행하지 않습니다. 이러한 문제에 대해 알고 싶어하거나 알아야 하는 대부분의 사용자는 문제가 발생하고 있다는 사실을 깨닫지 못할 것입니다. 생각해 보십시오. 우리는 systemd 문제의 원인이 dmesg 문제라는 것을 배웠습니다.

모든 구성에 대해 모든 메시지를 억제하면 필요한 것보다 더 넓은 네트워크가 캐스팅됩니다. 감지되고 수정될 수 있는 구성은 눈에 띄지 않을 수 있습니다. 문제가 노출되지 않으면 문제를 해결할 수 없습니다.

커널이 일부 조직에 대한 정책 결정을 내리는 것 같습니다. 사실상 수리가 불가능한 하드웨어를 보유한 경우 조직은 위험에 따라 무엇을 해야 할지 결정해야 합니다. 위험을 감수하기로 결정하거나 하드웨어를 업데이트하기로 결정할 수도 있습니다. 그러나 문제에 대한 정보가 없으면 실행 가능한 프로젝트가 있다는 사실조차 깨닫지 못할 수도 있습니다.

결국 스레드 후반에 도달한 절충안은 호출 모듈당 최소한 하나의 dmesg를 갖는 것이었습니다.

답변3

/dev/urandom전통적으로 와 사이의 유일한 차이점은 /dev/random커널이 시스템에 엔트로피가 없다고 생각할 때 발생하는 것입니다( /dev/random닫기 실패, /dev/urandom열기 실패). 두 드라이버 모두 add_disk_randomness(), 및 에서 add_interrupt_randomness()엔트로피를 얻습니다 add_input_randomness(). /drivers/char/random.c자세히보다.

추가 편집: Linux 4.8부터 /dev/urandomCSPRNG를 사용하도록 재설계되었습니다.

그렇다면 언제 실패를 꺼야 할까요? 모든 유형의 암호화 사용, 특히 DRBG 시드에 적합합니다. /dev/urandom충분한 엔트로피 없이 RSA 키를 생성할 때 RSA 키를 사용하는 결과를 설명하는 매우 좋은 논문이 있습니다 . 읽다당신의 P와 Q를 찾아보세요.

관련 정보