วิธีที่รวดเร็วในการสุ่ม HD?

14

ฉันได้อ่านเกี่ยวกับวิธีทำให้ฮาร์ดไดรฟ์ปลอดภัยสำหรับการเข้ารหัสและหนึ่งในขั้นตอนคือการเขียนบิตสุ่มไปยังไดรฟ์เพื่อให้ข้อมูลที่เข้ารหัสแยกไม่ออกจากส่วนที่เหลือของข้อมูลบนฮาร์ดไดรฟ์

อย่างไรก็ตามเมื่อฉันพยายามใช้dd if=/dev/urandom of=/dev/sdaในอดีตที่ผ่านมาการทางพิเศษแห่งประเทศไทยกำลังมองหาในลำดับของวัน ฉันเห็นบางอย่างเกี่ยวกับการใช้badblocksแทน urandom แต่ดูเหมือนจะไม่ได้ช่วยอะไรมากมาย ฉันต้องการทราบว่ามีวิธีใดบ้างที่อาจช่วยให้ฉันเร่งความเร็วเช่นตัวเลือกddหรืออย่างอื่นที่ฉันอาจหายไปหรือหากความเร็วนั้นเป็นข้อ จำกัด ของ HD

encryption dd random

— bitflips
แหล่งที่มา

เปลี่ยนขนาดบล็อกของคุณให้เป็นมิตรกับฮาร์ดไดรฟ์มากขึ้น dd bs=1Mตัวอย่างเช่น.

— แพทริค

คุณได้ความเร็วเท่าไร ใช้เวลาสักครู่ในการเขียนทั้ง 3TB (ตัวอย่าง) HDD ตรวจสอบiostat -kx 10เพื่อดูว่ามีอะไรว่าง%% บนไดรฟ์

— Derobert

5

shred -v -n 1 /dev/overwritethisรวดเร็ว มันเกี่ยวกับกรณีเดียวที่shredมีประโยชน์กับบางสิ่งบางอย่างจริงๆ

— frostschutz

@derobert: ฉันไม่สามารถพูดได้อย่างแน่นอนว่ามันเร็วแค่ไหน แต่ฉันออกไปไม่กี่ชั่วโมงกลับมาและมันก็เสร็จประมาณ 10% สำหรับ HD 500G ภายในของฉันในครั้งแรกที่ฉันลองทำ ขอบคุณสำหรับเคล็ดลับ "iostat" btw

— bitflips

@ แพทริก: ฉันลอง bs = 4M เรียงลำดับของสุ่มสี่สุ่มห้าเนื่องจากฉันเห็นว่าในคู่มือสำหรับวิธีการใส่แผ่นซีดี Arch บน usb มันช่วยเล็กน้อย แต่ก็ยังค่อนข้างช้า

— bitflips

14

dd if=/dev/urandom of=/dev/sdaหรือเพียงแค่ cat /dev/urandom >/dev/sdaไม่ได้เป็นวิธีที่เร็วที่สุดที่จะเติมดิสก์ที่มีข้อมูลแบบสุ่ม Linux /dev/urandomไม่ได้เป็น RNG เข้ารหัสที่เร็วที่สุด มีทางเลือกอื่นสำหรับ / dev / urandom หรือไม่ มีข้อเสนอแนะบางอย่าง โดยเฉพาะอย่างยิ่ง OpenSSL มี PRNG เข้ารหัสลับที่เร็วกว่า:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

โปรดทราบว่าในท้ายที่สุดไม่ว่าจะมีการปรับปรุงหรือไม่ขึ้นอยู่กับส่วนใดเป็นคอขวด: ซีพียูหรือดิสก์

ข่าวดีก็คือว่าการเติมดิสก์ด้วยข้อมูลแบบสุ่มนั้นไม่มีประโยชน์ส่วนใหญ่ ครั้งแรกที่จะปัดเป่าตำนานทั่วไปเช็ดด้วยเลขศูนย์เป็นเพียงที่ดีกับฮาร์ดแวร์ของวันนี้ ด้วยเทคโนโลยีฮาร์ดดิสก์ในปี 1980 การเขียนทับฮาร์ดดิสก์ด้วยค่าศูนย์เหลือค่าใช้จ่ายเล็กน้อยซึ่งสามารถกู้คืนได้ด้วยฮาร์ดแวร์ที่มีราคาค่อนข้างแพง การเขียนทับหลายครั้งด้วยข้อมูลแบบสุ่ม (“ Gutmann เช็ด”) เป็นสิ่งที่จำเป็น ทุกวันนี้แม้แต่การเขียนทับทับศูนย์ด้วยข้อมูลเดียวก็ทำให้ข้อมูลที่ไม่สามารถกู้คืนได้จริงแม้ในสภาพห้องปฏิบัติการ

เมื่อคุณกำลังเข้ารหัสพาร์ติชันการกรอกข้อมูลด้วยดิสก์แบบสุ่มนั้นไม่จำเป็นสำหรับการรักษาความลับของข้อมูลที่เข้ารหัส มันจะมีประโยชน์ก็ต่อเมื่อคุณต้องการสร้างพื้นที่ที่ใช้โดยข้อมูลที่เข้ารหัสซึ่งแยกไม่ออกจากพื้นที่ที่ไม่ได้ใช้ การสร้างโวลุ่มที่เข้ารหัสด้านบนของคอนเทนเนอร์ที่ไม่ได้สุ่มเผยให้เห็นว่าบล็อกดิสก์ใดที่เคยใช้โดยโวลุ่มที่เข้ารหัส สิ่งนี้ให้คำแนะนำที่ดีเกี่ยวกับขนาดสูงสุดของระบบไฟล์ (แม้ว่าเมื่อเวลาผ่านไปมันจะกลายเป็นการประมาณที่แย่ลงและแย่ลง) และอีกเล็กน้อย

— Gilles 'หยุดความชั่วร้าย'
แหล่งที่มา

4

Gutmann เป็นตำนานอย่างครบถ้วนฉันไม่คิดว่าจริง ๆ แล้วมันเคยถูกสร้างขึ้นมาสำหรับฮาร์ดดิสก์ยุค 80 เช่นกัน ประชดคือการที่ไดรฟ์ฉลาดขึ้นคุณควรใช้ข้อมูลแบบสุ่มทุกวันนี้เพื่อให้แน่ใจว่าไดรฟ์ถูกบังคับให้เขียนแทนที่จะเป็นเซกเตอร์ว่าง (ตัดแต่ง) หรือบีบอัดข้อมูล เลขศูนย์จะดีถ้าพวกเขากำลังเขียนจริง

— frostschutz

1

@mellowmaroon ใช่cat /dev/zeroเกือบจะเพียงพอแล้ว จะไม่เพียงพอหากคุณต้องการซ่อนพื้นที่ว่างในวอลลุ่มเข้ารหัส

— Gilles 'ดังนั้น - หยุดความชั่วร้าย'

1

@mellowmaroon มันไร้ประโยชน์มาก eavesdropper จะรู้ว่าคุณมีข้อมูลไม่เกิน X MB (และอาจน้อยกว่านี้เพราะพื้นที่ก่อนหน้านี้เคยใช้ แต่ตอนนี้ว่างไม่สามารถแยกออกจากพื้นที่ใช้แล้ว) ได้อย่างไร นอกจากนี้ที่ตั้งของพื้นที่ว่างอาจเปิดเผยประเภทของระบบไฟล์ (สำเนา superblock); ที่ไม่ค่อยมีความกังวล (โดยทั่วไปจะปรากฏในข้อความ/etc/fstabนอกเสียจากว่าคุณจะเข้ารหัสพาร์ติชันรูทและแม้จะไม่มีตัวเลือกที่น่าเชื่อถือจำนวนมากก็ตาม)

— Gilles 'หยุดความชั่วร้าย'

2

@Gilles ปัญหาที่ฉันพบใน Ubuntu 13.10 นั้นopenssl randดูเหมือนว่าจะมีขีด จำกัด บนจำนวนไบต์ที่มันจะสร้าง หากคุณเกินขีด จำกัด นั้นเช่น 'openssl rand 810000000000

, then no random output is generated. Only a brief "help" text is printed. I'm trying to random (pretty much) fill a 3TB hard drive. Not sure if there is a way to get

openssl` เพื่อสร้างไบต์สุ่มจำนวนมาก

— ไม่มีเหตุผล John

1

สำหรับปัญหาขีด จำกัด บนของจอห์นที่ไม่มีเหตุผล 810 พันล้านไบต์ออกมาประมาณ 754 GB วิธีแบ่งพาร์ติชันดิสก์ของคุณออกเป็นหลายพาร์ติชั่น 700 GB แล้วรันopenssl randคำสั่งในแต่ละพาร์ติชั่นโดยเริ่มจาก sda5 หรืออะไรก็ตามและทำงานย้อนหลังเป็น sda1 และสุดท้าย sda?

— jia103

6

openssl ดูเหมือนจะไม่ทำงานสำหรับฉัน ฉันได้รับ "ตัวเลือกที่ไม่รู้จัก" และปัญหาอื่น ๆ ด้วยวิธีแก้ไข ดังนั้นฉันจึงไปกับโปรแกรม fio

fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0

ซึ่งดูเหมือนว่าจะใช้เวลา 3 ชั่วโมงในการทำ 19TB ข้าม 24 HDDs ดังนั้นประมาณ 1,800 MB / s

smp-016:~ # fdisk -l /dev/md0
Disk /dev/md0: 18890.1 GB, 18890060464128 bytes

smp-016:~ # fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0
fill: (g=0): rw=write, bs=512M-512M/512M-512M/512M-512M, ioengine=libaio, iodepth=4
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [2.7% done] [0KB/1536MB/0KB /s] [0/3/0 iops] [eta 03h:01m:11s]

ฉันหวังว่านี่เป็นข้อมูลสุ่มจริง หน้าคนบอกว่า fio "ค่าเริ่มต้น: เติมบัฟเฟอร์ด้วยข้อมูลแบบสุ่ม" http://linux.die.net/man/1/fio

ฉันไม่ได้ทำเพื่อความปลอดภัย / การเข้ารหัสเพียงพยายามให้แน่ใจว่าการทดสอบที่อ่านในภายหลังของฉันเป็นข้อมูลจริงไม่ใช่ไม่ใช่แค่ 0 คำสั่ง fio เดียวกันนี้สามารถใช้สำหรับการกำหนดเงื่อนไขล่วงหน้า SSD / NVMe เช่นเดียวกับการใช้ / dev / ศูนย์สามารถนำไปสู่การบีบอัดระดับดิสก์ "โกง" เท่าไหร่เขียนจริง แม้ว่าฉันจะเพิ่มการ-loops=2ตั้งค่าสถานะถ้าเป็น SSD ใหม่สำหรับการเปรียบเทียบ

หากคุณต้องการให้มีความปลอดภัยคุณสามารถใช้-randrepeat=boolตัวเลือกได้เนื่องจากจะสลับ "Seed ตัวสร้างตัวเลขสุ่มในวิธีที่คาดการณ์ได้ดังนั้นผลลัพธ์จะสามารถทำซ้ำได้ในการเริ่มต้น: จริง" แต่ฉันยังไม่ แน่นอนว่าจะปลอดภัย

นอกจากนี้ HDD ระดับองค์กรบางตัวยังมี SED (Self Encrypting Drives) และจะช่วยให้คุณสามารถหมุนคีย์เข้ารหัสเพื่อลบข้อมูลทั้งหมดที่เขียนได้ทันทีและปลอดภัย

สุดท้ายฉันเคยใช้ DBAN (หรือที่รู้จักในชื่อ Darik's Boot and Nuke) ซึ่งมีตัวเลือกการบูต CD และ USB และ "เป็นโครงการโอเพ่นซอร์สที่โฮสต์บน SourceForge โปรแกรมถูกออกแบบมาเพื่อลบฮาร์ดดิสก์อย่างปลอดภัยจนกว่าข้อมูลจะถูกลบอย่างถาวร ถูกลบและไม่สามารถกู้คืนได้อีกต่อไป "

— TaylorSanchez
แหล่งที่มา

1

ขนาด = 100% ไม่ได้ผลสำหรับฉัน แต่ fill_device = 1 (หรือ fill_fs = 1) ทำ

— d.jamison

ฉันคิดว่ามันจะขึ้นอยู่กับว่าคุณให้มันเป็นอุปกรณ์ระดับบล็อกหรือระบบไฟล์เพื่อเติมเต็ม ด้วยอุปกรณ์ระดับบล็อกมันรู้ว่ามันใหญ่ขนาดไหนและขนาดนั้นเป็นเปอร์เซ็นต์ของขนาดอุปกรณ์ ที่ fill_device ไปที่ใดจนกว่าจะได้รับข้อผิดพลาดแบบเต็มของอุปกรณ์ ฉันคิดว่าการตั้งค่าสถานะ fill_device อาจไม่เขียนทับไฟล์ใด ๆ เพียงแค่พื้นที่ที่ไม่ได้ใช้ ฉันไม่ได้ทำการทดสอบเพราะฉันมักจะหลีกเลี่ยงระบบไฟล์เว้นแต่จำเป็นเมื่อทำการทดสอบอุปกรณ์

— TaylorSanchez

6

คุณสามารถให้ OpenSSL เข้ารหัส/dev/zeroด้วยรหัสผ่านแบบสุ่มให้ข้อมูลปลอมที่ดีรวดเร็ว (หาก CPU ของคุณรองรับการเร่งความเร็ว)

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd of=/dev/sda

คุณสามารถส่งผ่านสิ่งนี้pvเพื่อรับความคืบหน้า / ETA คำสั่งที่ฉันใช้อยู่ในขณะนี้ (ในรูทเชลล์) คือ:

DISK="sda"
DISKSIZE=$(</proc/partitions awk '$4=="'"$DISK"'" {print sprintf("%.0f",$3*1024)}')
apt-get install pv
openssl enc -aes-256-ctr -nosalt \
  -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
  < /dev/zero |
  pv --progress --eta --rate --bytes --size "$DISKSIZE" |
  dd of=/dev/"$DISK" bs=2M

ฉันได้ความคิดนี้จากคำตอบนี้หลังจากมีปัญหาเช่นเดียวกับจอห์นที่ไม่มีเหตุผลผู้ให้ความเห็นเกี่ยวกับคำตอบของ Gilles ข้างต้น นี่เป็นการเพิ่มความเร็วในการลบของฉันไปยังอาเรย์ RAID ใหม่ของฉันจาก 11 MB / s เป็นประมาณ 300 MB / s สิ่งที่ต้องใช้เวลาหนึ่งสัปดาห์ลดลงเป็น 10 ชั่วโมง

ฉันจะเพิ่มว่าคุณควรจะสามารถใช้ มากกว่าคำสั่งที่ซับซ้อนมากขึ้นข้างต้น แต่มีข้อผิดพลาดที่จะช่วยให้การผลิตเพียง 16 MB ของการส่งออก (ข้อผิดพลาดนี้ถูกยื่นเมื่อเดือนมกราคม 2559)openssl rand #of_bytesopenssl enc ...ssl

และตามคำตอบสำหรับคำถามนี้และต่อเนื่องที่จะสมมติว่า CPU เป็นคอขวดอาจเป็นไปได้ที่จะเพิ่มความเร็วได้อีกด้วยการเรียกใช้opensslกระบวนการแบบขนานหลายกระบวนการบนแกนแยกต่างหากรวมกันโดยใช้ FIFO

— tremby
แหล่งที่มา

ไม่แน่ใจว่าจำเป็นต้องแก้ไขหรือไม่ คำตอบอื่น ๆ openssl randคำถามนี้ขอแนะนำ

— tremby

2

มาตรฐาน:: dd if=/dev/urandom18MiB / s openssl enc,: ~ 180MiB / s fio,: 169MiB / s, openssl randไม่รองรับ> 754GB

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt </dev/zero | pv --progress --eta --rate --bytes --size $(</proc/partitions awk '$4=="sda" {print sprintf("%.0f",$3*1024)}') | dd of=/dev/sda bs=2M

โปรดทราบว่าถ้าคุณยังต้องการการคำนวณอัตโนมัติขนาดใช้: ระวังsdaมีอยู่สองครั้งในคำสั่งนี้

— KrisWebDev

0

เติมคำตอบของมาร์โกสิ่งที่คุณต้องการคือเครื่องสร้างตัวเลขสุ่มที่เร็วกว่า

คุณสามารถใช้โปรแกรมง่ายๆที่สะท้อนตัวเลขสุ่มจากห้องสมุดที่ดีเช่นและการใช้งานที่หนึ่งในboost::randomdd

หากคุณเลือกเพิ่มคุณสามารถใช้ตัวอย่างนี้เปลี่ยนexperimentฟังก์ชันตามความต้องการของคุณ

— RSFalcon7
แหล่งที่มา

โซลูชันบูสต์ของคุณเร็วขึ้นเท่าใด มาตรฐานที่ไม่ใช่ทางวิทยาศาสตร์อย่างรวดเร็วในเครื่องของฉันให้ความเร็วเท่า/dev/urandomกันทุกประการ

— Marco

boost::randomไม่เสนอ crypto RNG ใช่ไหม หากคุณกำลังใช้ RNG ที่ไม่ได้เข้ารหัสคุณอาจใช้เลขศูนย์อย่างน้อยที่สุดคุณจะไม่ได้รับความปลอดภัย

— Gilles 'หยุดความชั่วร้าย'

ฉันไม่สามารถระบุได้อย่างชัดเจนว่าboost::randomเครื่องกำเนิดเร็วขึ้นเท่าไหร่วิธีเดียวที่จะรู้ได้อย่างแน่นอนคือการวัดอัลกอริธึมที่เร็วที่สุดกับพวกเขา/dev/urandom

— RSFalcon7

0

คอขวดถ้าไม่ใช่ขนาดบล็อกหรือฮาร์ดไดรฟ์ แต่เป็นการสร้างตัวเลขสุ่มหลอกแบบช้า /dev/urandomเป็นขนาดที่เร็วกว่าเมื่อเทียบกับ/dev/randomเนื่องจากมันไม่ได้บล็อคบนเอนโทรปีต่ำ

คุณสามารถยืนยันได้โดยการวัดผลลัพธ์ดิบของตัวเลขสุ่มหลอกของคุณ:

pv /dev/urandom >/dev/null

อัตรานี้จะช้ากว่าอัตราการเขียนของฮาร์ดไดรฟ์มาก โซลูชันที่ถูกต้องนั้นขึ้นอยู่กับระดับความปลอดภัยที่คุณต้องการ หากคุณต้องการความปลอดภัยสูงให้ใช้ตัวสร้างแบบสุ่มฮาร์ดแวร์เร็วหรือยอมรับความเร็วช้า หากความต้องการด้านความปลอดภัยของคุณไม่สูงคุณสามารถบันทึกข้อมูลสองสาม MiB และเขียนสตริงนั้นซ้ำไปยังไดรฟ์ หรืออาจจะเขียนเลขศูนย์จาก/dev/zeroตัวเลือกก็ได้

สรุป

/dev/random - การรักษาความปลอดภัยช้ามาก
/dev/urandom- ~~น้อย~~ secure¹ช้า
RNG ฮาร์ดแวร์ - การรักษาความปลอดภัยได้อย่างรวดเร็วและมีราคาแพงมาก
( /dev/zero - ไม่สุ่มที่ทุกอย่างรวดเร็วมาก)

¹ _{ข้อมูลอ้างอิงจาก / dev / urandom ปลอดภัยสำหรับรหัสเข้าสู่ระบบหรือไม่? คือเป็นที่ปลอดภัย/dev/urandom /dev/randomขอบคุณ Gilles ที่ชี้เรื่องนี้ออกมา}

— มาร์โก
แหล่งที่มา

urandomเขาได้ใช้

— แพทริค

จริง ประเด็นของฉันคือแม้แต่ urandom ก็ช้าเกินไปสำหรับความต้องการของเขานั่นคือเหตุผลที่เขาต้องการโซลูชันที่แตกต่างจาก urandom

— Marco

/dev/randomไม่มีการเพิ่มการรักษาความปลอดภัยในการใช้

— Gilles 'หยุดความชั่วร้าย'

@Gilles ขอบคุณสำหรับลิงค์ หน้า man ระบุอย่างชัดเจน: ... ด้วยเหตุนี้หากมีเอนโทรปีไม่เพียงพอในกลุ่มเอนโทรปีค่าที่ส่งคืนจะมีความเสี่ยงในทางทฤษฎีต่อการถูกโจมตีแบบเข้ารหัสลับ…นั่นคือเหตุผลที่ฉันจัดว่ามันปลอดภัยน้อยกว่า

— Marco

0

ฉันพยายามเติม HDD USB ภายนอกขนาด 4TB dd if=/dev/urandom of=/dev/sdX status=progressซึ่งช้าเกินไป (โดยไม่คำนึงถึงbs=การตั้งค่า) และดูเหมือนว่าopensslจะมีขีด จำกัด จำนวนข้อมูลแบบสุ่มที่จะส่งออก (อย่างน้อยสำหรับรุ่น 1.0.2p) ตัวเลือกที่ดีที่สุดที่ฉันพบคือความคิดเห็นจาก frostschutz ที่จะใช้shredเช่นเดียวกับใน:

shred -v -n 1 /dev/sdX

ตรวจสอบให้แน่ใจว่าใช้งาน-n 1มิฉะนั้นอุปกรณ์จะเริ่มต้นเขียนอุปกรณ์เกิน 3 ครั้ง (รวมถึงสิ่ง-vที่แสดงความคืบหน้า) ฉันไม่คิดว่าคุณภาพของตัวเลขสุ่มหลอกนั้นสูง แต่ก็เพียงพอแล้วที่ฉันจะเตรียม HDD แบบพกพาที่มีความจุสูงสำหรับการเข้ารหัส

— drgibbon
แหล่งที่มา