What you care about is whether the RNG is securely seeded or not. The old man page was incredibly confusing and misleading and has created a weird culture of fear around a simple issue. Instead,Ĭonsider BoringSSL (Adam Langley et al.) that does almost the same in Not a cryptographer or implementer of cryptographic interfaces. RNDGETENTCNT ioctl on a /dev/urandom file descriptor and sleepingĭon't take my word for the feasibility of this fallback method as I'm So if you're going to have to check the entropy count anyway, a lessĬonvoluted approach would be to repeatedly retrieve it via the The system could only be providing /dev/urandom. dev/random could be a symlink to /dev/urandom, so the call to pollģ. dev/urandom after waking up from poll if you're not also checkingĢ. So in an early userspace you're likely to be reading from an uninitialized proc/sys/kernel/random/read_wakeup_threshold is 64 by default ,īut the kernel only considers the pool initialized with >128 bits I don't think using poll on /dev/random is a good idea, here's why:ġ. If you can't just use getrandom(2), do the "poll /dev/random, then read /dev/urandom" dance and even the fearmonger's favorite issue to cite becomes a non-issue. And then you can guarantee that /dev/urandom is secure and nonblocking henceforth.
This is actually the best of both worlds: Although /dev/urandom on Linux will happily give you predictable values if you try to read from it before the RNG has been seeded on first boot, once /dev/random is "ready" to be read from once, you know that the entropy pool powering /dev/urandom has been seeded. This is what randombytes_buf() does in libsodium on older Linux kernels. This is essentially what getrandom(2) does. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. Once /dev/random is available, don't use /dev/random, use /dev/urandom. If you find that it is possible to compress an encrypted volume, that means your encryption implementation is not secure.> If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Even if you don't use Linux normally, you can just boot up a copy of Linux from a Live USB memory stick on the computer where your drives are attached, and make the backup.Įdit: To address your question about compression - You cannot compress an encrypted volume. I'd recommend running the backup operation using a Linux system. It won't ask if you are sure you know what you're doing, and it won't stop you it will just do whatever you ask.
Please be careful not to switch the "if" (input file) and "of" (output file) parameters. The "bs" parameter is just for "blocksize" and will help speed up the copy process. These commands will of course also work fine with a non-encrypted volume. Where "sdX" is the drive you are backing up, and "/path/to/file.img" is the image file destination. Where "sdX" is the drive you are reading from, and "sdY" is the drive you are cloning to.ĭd if=/dev/sdX of=/path/to/file.img bs=16M The actual command you run would look something like this:
#TRUECRYPT ALTERNATIVE 2016 REDDIT FREE#
This is because you cannot tell the difference between free space and used space on a properly encrypted volume. If your TrueCrypt volume is 200GB, the image file will be 200GB, even if only 40GB of the TrueCrypt volume is actually occupied. Please note that if you write to a file, the file will be the size of your entire TrueCrypt volume. With dd, you can clone your TrueCrypt drive to another drive, or you could write the entire contents into a file. I have successfully made backups of a TrueCrypt encrypted system drive using "dd" - the block copy utility found on unix-like systems.
0 kommentar(er)
