대량의 의사 난수 데이터를 예측 가능하게 생성

대량의 의사 난수 데이터를 예측 가능하게 생성

저렴한 2TB HDD(개당 60€)를 구입했는데 사용하기 전에 읽을 때 입력한 데이터가 반환되는지 확인하고 싶었습니다. 나는 여기에 넣은 대용량 파일을 복사하고 그들이 반환한 데이터의 해시를 확인하여 저렴한 썸 드라이브를 검사했습니다(실제 저장 용량이 소진된 후 방금 데이터를 삭제한 드라이브를 찾았습니다). 안타깝게도 2TB 파일이 없습니다.

이제 2TB의 의사 난수 데이터를 생성하여 디스크에 쓰고 디스크에 해시하려고 합니다. 그런 다음 동일한 데이터를 해시 함수에 직접 쓰고 이 방식으로 생성해야 하는 해시 값을 얻고 싶습니다. 의사 난수 함수는 어떤 방식으로든 암호화 방식으로 안전할 필요는 없으며 단지 높은 엔트로피 데이터를 빠르게 생성하기만 하면 됩니다.

숫자가 포함된 변수를 해시하고 해시 값을 stdout에 인쇄하고 변수를 증가시키고 반복하는 스크립트를 작성하면 빠른 CPU에서도 데이터 속도가 너무 느립니다. 5배 더 느립니다(60kByte/s도 안 됨).

지금 나는할 수 있다이렇게 해 보았지만 tee매우 나쁜 생각인 것 같아서 동일한 데이터를 반복해서 재현할 수 없습니다.

이상적으로는 몇 가지 짧은 인수(숫자, 문자열, 상관 없음)를 프로그램에 전달하고 표준 출력에서 ​​임의로 많은 양의 데이터를 얻으며 데이터는 모든 호출에서 동일합니다.

답변1

0(***)을 암호화하면 됩니다.

암호화는 정확히 당신이 원하는 것입니다. 암호화된 0은 임의의 데이터처럼 보입니다. 복호화 후 다시 0으로 변경합니다. 키를 알고 동일한 비밀번호 설정(**)을 계속 사용하는 한 결정적이고 반복 가능하며 되돌릴 수 있습니다.

임의의 데이터로 드라이브를 덮어쓰는 예 cryptsetup:

cryptsetup open --type plain --cipher aes-xts-plain64 /dev/deletedisk cryptodeletedisk
# overwrite with zeroes
pv < /dev/zero > /dev/mapper/cryptodeletedisk
# verify (also drop caches or power cycle)
echo 3 > /proc/sys/vm/drop_caches
pv < /dev/mapper/cryptodeletedisk | cmp - /dev/zero
### alternatively, run badblocks in destructive mode:
badblocks -w -b 4096 -t 0 -v -s /dev/mapper/cryptodeletedisk

이는 AES-NI를 사용하는 최신 시스템의 디스크 속도를 최대한 활용해야 합니다.

오류가 발견되지 않으면 드라이브가 무작위 데이터로 완전히 덮어씌워졌고 다시 읽을 때 올바른 데이터가 반환된 것입니다.


동일한 무작위 데이터를 반복적으로 전송하기 위해 cryptsetup을 사용하는 예입니다(실제 저장 장치는 포함되지 않음).

이 예에서는 /dev/zero이를 데이터 소스로 사용하지 않고 정확히 0이 있는 임의로 큰 스파스 파일을 만들 수 있다는 사실을 활용합니다.

# truncate -s 1E exabyte_of_zero
# cryptsetup open --type plain --cipher aes-xts-plain64 --readonly exabyte_of_zero exabyte_of_random
Enter passphrase for exabyte_of_zero: yourseed
# hexdump -C -n 64 /dev/mapper/exabyte_of_random
# cat /dev/mapper/exabyte_of_random | something_that_wanted_random_data

이는 파일 시스템이 스파스 파일을 지원하고 부작용이 없는 경우에만 작동합니다(tmpfs에서는 작동하지 않음).

참고: 이는 단지 예일 뿐이며 실제로 이러한 가상 EB 장치를 생성하면 부작용이 발생할 수 있습니다. 사용 사례에 적합한 크기로 크기를 제한하고, 백업 스크립트가 파일을 선택하여 압축하지 않는 위치에 파일을 저장하세요.


cryptsetup읽기 가능한 블록 장치가 제공되고 검색 가능하므로 이를 사용하여 파일 중간 어딘가에서 데이터 비교를 시작할 수도 있습니다. 또한 이를 사용하여 임의 오프셋에서 임의 데이터를 분석하고 그것이 실제로 임의인지, 반복되지 않는지 확인할 수 있습니다(*). 기존 PRNG에서는 일반적으로 모든 것을 처음부터 다시 생성해야 합니다.


cryptsetup루트 권한이 필요합니다(결과적인 장치 매퍼 장치는 다른 사용자가 읽을 수 있게 만들 수 있지만).

루트 액세스가 없으면 openssl0을 암호화하여 임의의 데이터를 생성할 수 있습니다. (댓글에는 이미 언급되어 있습니다.)

$ openssl enc -pbkdf2 -aes-256-ctr -nosalt \
      -pass pass:yourseed < /dev/zero \
      | hexdump -C -n 64
00000000  62 5e 3d cd 39 dc d6 a2  bb 73 2d 0f 63 b1 f1 75  |b^=.9....s-.c..u|
00000010  4d 84 f5 75 cb b6 1e 33  9c e8 41 9c 76 4b 7e 12  |M..u...3..A.vK~.|
00000020  c2 90 d5 93 2d a9 9e a0  48 bd b8 3e a5 1a d6 f7  |....-...H..>....|
00000030  2c a6 e0 07 4d 5a 45 31  13 dc ef 97 df 76 c5 b8  |,...MZE1.....v..|
00000040

이 접근 방식도 제안됩니다.coreutils 문서무작위 데이터 소스방법으로는"시드 값이 주어지면 반복 가능한 임의의 양의 의사 난수 데이터를 생성합니다.".


암호화된 0 대신 기존 PRNG를 사용할 수도 있습니다. 나는 그것을 제공하는 표준 도구를 모른다는 것입니다. 따라서 이 방법에는 원하는 PRNG 알고리즘/라이브러리를 선택하고 몇 줄의 코드를 작성하여 데이터를 생성하는 작업이 포함됩니다.

shred좋은 PRNG가 있지만 직접 시드하거나 파이프할 수 없으므로 여기서는 사용할 수 없습니다.

tee단일 임의 소스의 데이터를 여러 프로세스로 다중화하는 것이 가능하지만 데이터가 즉시 병렬로 소비되어야 합니다(예:두 개의 병렬 텍스트 파일 섞기), 따라서 이는 데이터가 동일해야 하지만 나중에 다시 재현할 필요가 없는 경우에만 적용됩니다.


(*) 암호화 시 올바른 비밀번호 설정을 선택하는 것이 매우 중요합니다. 예를 들어 aes-xts-plain2TB의 데이터가 복제된 후에는 에 있으므로 aes-xts-plain64더 이상 사용하지 마십시오 aes-xts-plain.

(**) 비밀번호 설정이 다르면 결과도 달라집니다. 이 답변에 표시된 명령은 일부 기본 설정에 의존하므로 장기적으로 데이터가 동일하지 않을 수 있습니다. 예를 들어 cryptsetup은 256비트 또는 512비트 키를 사용할 수 있지만 openssl은 기본 반복 횟수를 사용합니다.

(***) 0을 암호화하는 이유는 커널이 모든 수의 0에 대해 고성능 데이터 소스를 제공하기 때문입니다. 그렇지 않으면 다른 암호화 모드도 동일하게 작동합니다.

답변2

데이터 무결성이 정말로 걱정된다면 무결성 검사 기능이 내장된 ZFS를 사용하세요. 새 하드웨어는 괜찮을 수도 있지만 몇 년 후에는 나빠질 수도 있습니다.

https://changelog.complete.org/archives/9769-silent-data-corruption-is-real

Here’s something you never want to see:

ZFS has detected a checksum error:

   eid: 138
 class: checksum
  host: alexandria
  time: 2017-01-29 18:08:10-0600
 vtype: disk

이는 드라이브에 데이터 오류가 있음을 의미합니다. 그러나 이는 일반적인 데이터 오류보다 더 나쁩니다. 하드웨어에서 감지하지 못하는 오류입니다. 대부분의 파일 시스템과 달리 ZFS 및 btrfs는 드라이브에 기록된 모든 데이터 블록(데이터 및 메타데이터)에 체크섬을 기록하고 읽을 때 체크섬을 확인합니다. 대부분의 파일 시스템은 이론적으로 하드웨어가 모든 오류를 감지해야 하기 때문에 이를 수행하지 않습니다. 그러나 실제로는 항상 그런 것은 아니며 이로 인해 소리 없이 데이터가 손상될 수 있습니다. 이것이 가능할 때마다 ZFS를 사용하는 이유입니다.

관련 정보