What is the quickest way to generate lots of random data on the command line? Usually when I had to wipe hard-drives I would simply use dd to copy from /dev/urandom over the device. However, `/dev/urandom is quite slow and wiping hard-disks can take a long time that way. So, I decided to benchmark a few methods to generate long random streams that are usable in such scenarios.
The benchmark is based on the dd command. For example:
$ dd if=/dev/urandom of=/dev/null bs=4k count=1M
This command will copy a 4GB of random bytes from /dev/urandom over /dev/null. This is probably the simplest method to create a large stream of random bytes, and as it turns out, also the slowest.
The second construct I tried is to use OpenSSL to create a stream of random data which I can read with dd and then write to the target. For example the following would use AES-128 with a random key:
Let’s breakup this command: openssl rand -hex 32 will generate a random encryption key to be used by the AES encryption. openssl enc -aes-128-ctr -in /dev/zero -pass stdin -nosalt does the actual encryption. It reads the (random) key from stdin and then uses it to encrypt /dev/zero using AES-128 in counter mode. As /dev/zero in an endless stream of zeros, it will simply output an endless stream of (pseudo-)random data. We can also repeat the same command only swapping aes-128-ctr with aes-256-ctr. For most (all?) usage scenarios it doesn’t provided any added security benefits but does have a (small) performance penalty.
Apart from AES, which is a block cipher, we can also try to use actual stream ciphers like the old rc4 and the modern chacha20.
Additionally, many new CPUs come with AES-NI extension which speeds up AES operations considerably. We can repeat the benchmark while disabling AES-NI to see how the different methods will perform if used a CPU that doesn’t support AES-NI.
Finally, I’ve repeated the test with /dev/zero as input, just to have an upper-limit in terms of performance to compare against.
Benchmark results, time (in seconds) to create 4GB of random data
The results clearly show that you should avoid /dev/urandom. It’s simply not suitable for this task and doesn’t perform well. The various methods of using OpenSSL perform much better. The best performance is achieved by the two AES variants, with aes-128-ctr being the fastest. However, if AES-NI is not supported by the CPU, AES takes a huge performance hit, and is even slower than the (not-so-)good and old RC4. However, ChaCha20 (a modern stream cipher) performs within 30% of AES if AES-NI is available, but if AES-NI is not supported ChaCha20 outperforms the AES variants. So, unless you know AES-NI is supported ChaCha20 is the safe choice.
This short tutorial will guide you in encrypting a drive with cryptsetup and LUKS scheme.
Before starting, if the device had previous data on it, it’s best to delete any filesystem signatures that may be on it. Assuming that the drive we operate is /dev/sda you can use the following command to remove the signatures:
$ sudo wipefs --all /dev/sda --no-act
Remove the --no-act flag to actually modify the disk.
The next step is to actually format the drive using LUKS. This is done using the cryptsetup utility.
$ sudo cryptsetup luksFormat --type=luks2 /dev/sda
This will overwrite data on /dev/sda irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda:
The command will prompt you to enter a passphrase for the encryption and should take a few seconds to complete.
The next step is to add an appropriate entry to crypttab which will simplify starting the dm-crypt mapping later. Add the following line to /etc/crypttab:
where the UUID is obtained through lsblk /dev/sda -o UUID or a similar command. The archive_crypt is the name for the mapped device. It will appear as /dev/mapper/archive_crypt when the device is mapped. The none parameter specifies that no keyfile is used and the system should prompt for an encryption passphrase instead. The noauto, means not to attempt to load the device automatically upon boot. discard should be used if the underlying device is an SSD.
You can test everything works so far by opening and loading the LUKS device:
$ sudo cryptdisks_start archive_crypt
While the device is now encrypted, there is a possible leakage of metadata such as used blocks as an attacker can discern used vs unused blocks by examining the physical drive. This and other side-channel leaks can be mitigated by simply wiping the contents of the encrypted device.
My boot process was pretty slow in a new setup I had. It would stop for about 30 seconds and then give the following error:
Gave up waiting for suspend/resume device
Turns out I had a resumable device listed in /etc/initramfs-tools/conf.d/resume even though my swap is both encrypted with random keys and too small. Editing that file and setting RESUME=none and running sudo update-initramfs -u fixed the issue.
This post outlines how I backported rtl8812au-dkms from Ubuntu Focal for Debian Buster and added support for the TP-Link Archer T4U v2 card to it. If you are only interested in the resulting .deb file skip to the end.
The TP-Link Archer T4U v2 is an AC1300 WiFi USB adapter. TP-Link provides drivers but they are built only for old kernel versions (<=3.19) and do not supoort DKMS, which makes upgrading a hassle.
Ubuntu provides the rtl8812au-dkms package which support the chipset in the Archer T4Uv2, but it doesn’t recognize the TP-Link product. So I set out to backport it to Debian Buster and make it support the Archer T4Uv2.
We start by fetching the rtl8812au source package from Ubuntu.
$ dget --allow-unauthenticated http://archive.ubuntu.com/ubuntu/pool/universe/r/rtl8812au/rtl8812au_22.214.171.12475.20140902+dfsg-0ubuntu12.dsc
$ cd rtl8812au-126.96.36.19975.20140902+dfsg/
$ sed -i s/dh-modaliases// debian/control
$ sed -i s/,modaliases// debian/rules
$ mk-build-deps ./debian/control --install --root-cmd sudo --remove
The sed lines remove reference to the dh-modaliases build dependency which Debian doesn’t have. I’m not really sure why they needed it for this package, but removing it didn’t hurt.
Next we add a new patch using quilt to support the Archer T4Uv2. We extract the 2357:010d USB vid:pid pair of the adapter using lsusb.
$ quilt push -a
$ quilt new add_archer_t4uv2.patch
$ quilt add os_dep/linux/usb_intf.c
$ vim os_dep/linux/usb_intf.c
The change we’ll be making to os_dep/linux/usb_intf.c is outlined by the following patch:
Some application rely on Internet Explorer to provide HTML rendering capabilities. Wine implements the same functionality based on a custom version of Mozilla’s Gecko rendering engine (the same engine used in Firefox). In Debian Jessie you have a package called libwine-gecko-2.24 (the version is part of the name) which provides this rendering engine for Wine. However, different versions of Wine require different versions of wine-gecko. The package provided in Debian Jessie, matches the Wine version provided by wine-development from the main Jessie repository (1.7.29). Unfortunately wine-development from the jessie-backports if of version 1.9.8 and requires wine-gecko of version 2.44 which is not provided by any Debian repository. This will lead to errors like
Could not load wine-gecko. HTML rendering will be disabled.
and blank spaces where HTML content would be rendered in many applications.
The solution would be to manually install the required version of wine-gecko. We start by downloading the MSI binaries provided by Wine
Most Israelis are literate in English, and for a large percentage of them, English is also the preferred language when it comes to computers. They prefer English, as it solves right-to-left issues and general inconsistencies (it might be annoying when some programs are translated ands some not). The downside is, that currently, the existing English locales are not suitable for Israel, as there are cultural differences:
American English spelling is more common in Israel.
The metric system is used, along with the relevant paper sizes (“A4” instead of Letter).
Dates are written in dd/mm/YYYY format, unlike in the USA.
The first day of week, and also the first workday is Sunday.
The currency used is ILS (₪).
So, up until now users had to choose locales such as en_US or en_GB and compromise on some stuff. To solve this issue, and create a truly suitable English locale for Israel, I wrote a localedef file for the en_IL locale.
To install the new locale, copy the en_IL file from the gist below and place under /usr/share/i18n/locales/en_IL (no extension). Next
Now, complete the installation by running dpkg-reconfigure locales and enable en_IL.UTF-8 from the list, and set it as the default locale.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sometimes a package that you need is not available for Debian Jessie, but you can find it for Sid (unstable). You may be tempted to try to install it manually, by downloading the binary deb package, but it will most likely fail due to binary incompatibilities with different libraries’ versions you have. The better method will be to get the source package used to build the binary package, and build it yourself. Most of the time the process is not as hard as it sounds.
First, a short preliminary setup is needed Add the following lines to /etc/apt/sources.list:
deb http://http.debian.net/debian jessie-backports main
deb-src http://httpredir.debian.org/debian unstable main contrib
You can replace unstable with testing if you prefer to use packages from testing. Update the lists of packages
sudo apt-get update
Next you need, to get the build dependencies for your package. The example below uses the package lyx:
sudo apt-get build-dep lyx/unstable
Now you are ready to fetch and build the source package:
sudo apt-get source -b lyx/unstable
Finally, you will see in the current directory the resulting DEBs. Simply install them: