มีทางเลือกอื่นสำหรับ / dev / urandom หรือไม่

มีวิธีที่เร็วกว่า / dev / [u] สุ่มหรือไม่ บางครั้งฉันต้องทำสิ่งต่าง ๆ เช่น

cat / dev / urandom> / dev / sdb

อุปกรณ์แบบสุ่มมีความปลอดภัย "เกินไป" และไม่น่าเสียดายที่ช้าเกินไป ฉันรู้ว่ามีwipeและเครื่องมือที่คล้ายกันสำหรับการลบที่ปลอดภัย แต่ฉันคิดว่ายังมีวิธีการบางอย่างบนบอร์ดใน Linux

หากคุณต้องการลบ "ปลอดภัย" ของฮาร์ดไดรฟ์ (หรือไฟล์) คุณควรดูที่ยูทิลิตี้ฉีก

ตามที่ผู้โพสต์ก่อนหน้านี้ชี้ให้เห็นอุปกรณ์สุ่ม / dev / * นั้นถูกใช้เป็นแหล่งข้อมูลสุ่มขนาดเล็ก

น่าเสียดายที่ลีนุกซ์มีการใช้ urandom อย่างไม่ดี คุณสามารถใช้ aes256-ctr กับปุ่มสุ่มและรับการสุ่มหลอกหลายร้อยเมกะไบต์ต่อวินาทีหาก ​​CPU ของคุณรองรับ AES-NI (การเร่งความเร็วฮาร์ดแวร์) ฉันรอคอยที่จะเปลี่ยนไปใช้วิธีการที่ทันสมัยเช่นกัน

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

ลูกสุนัขตัวนี้ทำ 1.0 GB / s ในกล่องของฉัน (เทียบกับ 14 MB / s ของ / dev / urandom) มันใช้ urandom เพียงเพื่อสร้างรหัสผ่านแบบสุ่มจากนั้นทำการเข้ารหัส / dev / zero อย่างรวดเร็วโดยใช้คีย์นั้น นี่ควรเป็น PRNG ที่ปลอดภัยด้วยการเข้ารหัส แต่ฉันจะไม่รับประกัน

ในการทดสอบอย่างรวดเร็วภายใต้ Ubuntu 8.04 ใน Thinkpad T60p กับ T2500 CPU, 1GB ของข้อมูลแบบสุ่มจากopenssl randเป็น 3-4X /dev/urandomได้เร็วกว่า นั่นคือ,

time cat /dev/urandom | head -c 1000000000 > /dev/null

... ประมาณ 4 นาทีในขณะที่ ...

time openssl rand 1000000000 | head -c 1000000000 > /dev/null

... เพิ่งผ่านไป 1 นาที

ไม่แน่ใจว่ามีความแตกต่างของคุณภาพแบบสุ่มหรือไม่ แต่ก็อาจใช้ได้กับการเช็ด HD

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

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

การตั้งค่าการเข้ารหัสฮาร์ดดิสก์ Linux

หากคุณต้องการล้าง HD อย่างปลอดภัยมีหนึ่งเครื่องมือที่ทรงพลังมาก : DBAN

หากคุณต้องการลบอุปกรณ์บล็อกขนาดใหญ่ฉันก็พบว่ามันใช้งานได้ดีกว่าddและตัวทำแผนที่อุปกรณ์แทนการเปลี่ยนเส้นทางเอาต์พุตของข้อมูลแบบสุ่ม ต่อไปนี้จะจับคู่/dev/sdbกับ/dev/mapper/deviceToBeErasedการเข้ารหัสและถอดรหัสอย่างโปร่งใส ในการเติมอุปกรณ์ในส่วนท้ายที่เข้ารหัสศูนย์จะถูกคัดลอกไปยังด้านข้อความธรรมดาของ mapper ( /dev/mapper/deviceToBeErased)

cryptsetup --cipher aes-xts-plain64 --key-file /dev/random --keyfile-size 32 create deviceToBeErased /dev/sdb
dd if=/dev/zero of=/dev/mapper/deviceToBeErased bs=1M

ข้อมูลที่เข้ารหัส/dev/sdbนั้นรับประกันว่าจะไม่สามารถแยกออกจากข้อมูลสุ่มได้หากไม่มีจุดอ่อนที่ร้ายแรงใน AES กุญแจที่ใช้นั้นถูกจับจาก/dev/random(ไม่ต้องกังวล - ใช้เพียง 32 ไบต์)

ตรวจสอบ frandom

http://billauer.co.il/frandom.html

ตามการทดสอบของฉันมันเร็วที่สุด

ยิ่งเครื่องมือของคุณเร็วเท่าไหร่ผลลัพธ์ก็จะปลอดภัย การสร้างแบบแผนที่ดีต้องใช้เวลา

อย่างไรก็ตามคุณสามารถใช้บางอย่างเช่นdd if = / dev / zero of = / dev / sdbแต่เห็นได้ชัดว่าไม่ได้เป็นแบบสุ่มมันจะลบได้เร็วขึ้นมาก

ตัวเลือกอื่นอาจจะใช้วิธีนี้/ sbin / badblocks -c 10240 -s -w -t random -v / dev / sdbมันเร็วกว่า urandom แล้ว แต่ badblocks PRNG นั้นสุ่มน้อยกว่า

/dev/random ใช้เอนโทรปีของระบบจำนวนมากและสร้างกระแสข้อมูลที่ช้าเท่านั้น

/dev/urandom มีความปลอดภัยน้อยลงและเร็วขึ้น แต่ยังคงมุ่งเน้นไปที่กลุ่มข้อมูลขนาดเล็ก - ไม่ได้หมายถึงการให้สตรีมตัวเลขความเร็วสูงแบบต่อเนื่อง

คุณควรให้ PRNG ของการออกแบบของคุณเองและเมล็ดมันด้วยอะไรบางอย่างจากหรือ/dev/random /dev/urandomหากคุณต้องการสุ่มเพิ่มขึ้นเล็กน้อยให้หยอดมันเป็นระยะ - ทุกๆสองสาม MB (หรือความยาวของ prng ของคุณ) การรับ 4 ไบต์ (ค่า 32 บิต) จาก urandom หรือ Random นั้นเร็วพอที่คุณจะสามารถทำสิ่งนี้ได้ทุก ๆ 1k ของข้อมูล (ทำการประมวลผล prng ของคุณทุกๆ 1k) และรับผลลัพธ์แบบสุ่มมากในขณะที่ไปอย่างรวดเร็วมาก

อดัม

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

จัดรูปแบบด้วย LUKS และ dd บนโวลุ่มที่เข้ารหัส จากนั้นใช้ / dev / urandom เพื่อล้างส่วนหัว LUKS

หากคุณมีฮาร์ดแวร์ AES รองรับนี่เป็นวิธีแก้ปัญหาที่รวดเร็วมาก

สั้น ๆ :

cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX cryptodev
dd if=/dev/zero bs=1M of=/dev/mapper/cryptodev
cryptsetup luksClose cryptodev
# wipe the luks header.  Yes, it uses /dev/urandom but only for 2MB of data:
dd if=/dev/urandom bs=1M count=2 of=/dev/sdX

ทำ!

ดูบล็อกของฉัน: เติมดิสก์อย่างรวดเร็วด้วยบิตสุ่ม (โดยไม่ต้อง / dev / urandom)

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

ในตัวอย่างนี้ฉันลบ harddrive เชิงกล 500GB ในเวลาเพียง 102 นาที แม้ว่าจะเต็มไปด้วยส่วนที่จัดสรรใหม่:

root@ubuntu:~# hdparm --security-set-pass Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
root@ubuntu:~# time hdparm --security-erase-enhanced Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_ERASE command, password="Eins", user=user

real    102m22.395s
user    0m0.001s
sys     0m0.010s

root@ubuntu:~# smartctl --all /dev/sdaj | grep Reallocated
  5 Reallocated_Sector_Ct   0x0033   036   036   036    Pre-fail Always   FAILING_NOW 1327 

คุณสามารถดูรายละเอียดเพิ่มเติมได้ที่ata.wiki.kernel.orgอย่างไรก็ตามตัวอย่างของพวกเขาไม่ได้ใช้ --security-erase-enhanced ซึ่งจำเป็นต้องลบเซกเตอร์ที่ถูกจัดสรรใหม่ก่อนที่จะกล่าวถึง

ในทางปฏิบัติอาจไม่มีความจำเป็นในการ seed ดิสก์ทั้งหมดจากสตรีมแบบสุ่มอย่างต่อเนื่อง

คุณสามารถสร้างกลุ่มข้อมูลแบบสุ่มขนาดเล็กแล้วค่อยทำซ้ำไปเรื่อย ๆ บนดิสก์

เพียงตรวจสอบให้แน่ใจว่าก้อนข้อมูลไม่ได้เป็นขนาดบล็อกหลายเท่าของดิสก์เพื่อให้แน่ใจว่าคุณไม่ได้เขียนทับบล็อกข้อมูลที่มีความสัมพันธ์กับข้อมูลสุ่มบิตเดียวกัน ขนาดก้อนที่มีจำนวนเฉพาะในช่วง ~ 1MB ควรทำอย่างดี

เพื่อความปลอดภัยที่เพิ่มขึ้นเพียงทำสองสามครั้งโดยใช้ขนาดก้อนที่แตกต่างกันในแต่ละครั้ง

ยูทิลิตี้ 'ฉีก' เป็นเรื่องง่ายและรวดเร็ว หากแอตทริบิวต์ SMART ของไดรฟ์ระบุเซกเตอร์ที่ถูกจัดสรรอีกครั้งศูนย์ 'shred' น่าจะปลอดภัยเพียงพอ

อย่างไรก็ตามหากไดรฟ์มีการจัดสรรเซกเตอร์ใหม่ข้อมูลในเซกเตอร์ที่เสียหายจะไม่ถูกเขียนทับ หากตำแหน่งที่เสียหายมีข้อมูลที่ละเอียดอ่อนก่อนที่จะถูกจัดสรรใหม่ 'ฉีกขาด' อาจไม่ดีพอ เซกเตอร์ 'ไม่ดี' อาจอ่านได้โดยรีเซ็ตแผนที่การจัดสรรของไดรฟ์และอ่านซ้ำ

ความสามารถในการรีเซ็ตแผนที่การจัดสรรเซกเตอร์เสียนั้นแตกต่างกันไปขึ้นอยู่กับผู้ผลิตและรุ่นของไดรฟ์

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

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

(head -c 4096 /dev/urandom; cat /dev/sdb/) > /dev/sdb