stevedoria.net

Nick Sullivan¹ writes:

You can compute how much energy is needed to break a cryptographic algorithm and compare that with how much water that energy could boil. This is a kind of a cryptographic carbon footprint. By this measure, breaking a 228-bit RSA key requires less energy than it takes to boil a teaspoon of water. Comparatively, breaking a 228-bit elliptic curve key requires enough energy to boil all the water on earth. For this level of security with RSA, you’d need a key with 2,380 bits.

ED25519 uses a 256-bit elliptic curve key.

Release notes for OpenSSH 8.3 announce that ssh-rsa is disabled by default in future releases. It is a good time to adopt ed25519 for public key authentication.

I successfully installed Debian 10.4 on the Dell Mini 9 (Inspiron 910).

Facing discontinuation of support for 32-bit x86 systems after Lubuntu 18.04 LTS, I was pressured to find another GNU/Linux distribution. I wanted to avoid future transitions and found several pages on the Internet suggesting that Debian is known for long term support of many architectures.

I tried the Debian 10.4 LXQt (non-free) LiveCD, debian-live-10.4.0-i386-lxqt+nonfree.iso, before continuing with installation.

The wired network card has no issues, but the wireless network card does. I encountered the following errors when booting the LiveCD:

[26.504] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[26.562] b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1
[26.562] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2062, Revision 2, Version 0
[26.576] Broadcom 43xx driver loaded [ Features: PNLS ]
[26.624] b43 ssb0:0: firmware: failed to load b43/ucode15.fw (-2)
[26.624] b43 ssb0:0: Direct firmware load for b43/ucode15.fw failed with error -2

Before migrating from Lubuntu 18.04 LTS to Debian 10.4, I created an archive of the /usr/lib/firmware/b43 files from my Lubuntu installation for copying onto the new Debian installation.

I avoided having to enable the non-free repository and installing additional packages by simply copying the b43 files after installation. Rebooting after copying the files allows for the firmware to be loaded:

[24.419] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[24.475] b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1
[24.475] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2062, Revision 2, Version 0
[24.496] Broadcom 43xx driver loaded [ Features: PNLS ]
[24.540] b43 ssb0:0: firmware: direct-loading firmware b43/ucode15.fw
[24.541] b43 ssb0:0: firmware: direct-loading firmware b43/lp0initvals15.fw
[24.544] b43 ssb0:0: firmware: direct-loading firmware b43/lp0bsinitvals15.fw
[24.630] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'

connman is used to manage the wireless network card. Graphical user interface front-ends to connman were finicky. I proceeded with using connmanctl.

My Dell Mini 9 is usually an isolated computer. I disabled the connman service so that it does not connect to the wireless network automatically during boot:

$ sudo systemctl disable connman

When I update the software, I start the connman service for temporary connectivity to the wireless network with the following command:

$ sudo systemctl start connman

All features of my Dell Mini 9 are now functioning without any issues.

A nonce is a value, N, that is used only once: N_once. Nonces or nonce values are encountered in cryptography.

The initialization vector used for AES in CBC mode are typically nonces:

C₁ = CIPH_K(P₁ ⊕ N_once)
C_j = CIPH_K(P_j ⊕ C_j-1) for 2 <= j <= n

Here, cipher block 1 is the result of the cipher block function keyed on K applied to the XOR value of plaintext block 1 and a nonce. The following cipher blocks are the result of the cipher block function keyed on K applied to the XOR value of the corresponding plaintext blocks and the previous cipher block.

There is a potential segmentation fault when executing ‘make test’ while building apr-1.7.0. The following lines are output:

...
testatomic          : -Line 413: Failed creating threads
-/bin/sh: line 2: XXXXX Segmentation fault      ./$prog -v
...
Programs failed: testall
make[1]: *** [check] Error 139
make[1]: Leaving directory `.../apr-1.7.0/test'
make: *** [check] Error 2

The segmentation fault is caused by a call to apr_thread_join() on an invalid apr_thread_t instance in test_atomics_threaded(). The problematic functions, test_atomics_threaded() and test_atomics_threaded64(), continue processing even when apr_thread_create() returns an error value.

The segmentation fault is avoided and the remaining tests are executed if either of the following is performed on …/apr-1.7.0/test/testatomic.c:

1. Comment out the following lines:

abts_run_test(suite, test_atomics_threaded, NULL);
abts_run_test(suite, test_atomics_threaded64, NULL);

2. Update NUM_THREADS with a smaller number, for example:

#define NUM_THREADS 25

A lack of memory resources is the underlying cause of this segmentation fault. Reducing the number of threads created for these tests allows testing the atomic operations as intended.

fciv.py is a Python module that I implemented to generate file integrity data in a format used by Microsoft File Checksum Integrity Verifier. My use case involves copying files from a Linux workstation to a Microsoft Windows workstation. I wanted to generate integrity data on Linux using Python 3 and verify file integrity on Microsoft Windows without installing 3rd party software.

FCIV file content is generated with the following Python snippet:

import fciv
digests = fciv.fciv_compute('mydirectory/**')
fciv.fciv_write(digests)

With the output of the generation script redirected to a file named ‘fciv.xml’, the following snippet performs verification:

import fciv
reference_digests = fciv.fciv_read('fciv.xml')
actual_digests = fciv.fciv_compute('mydirectory/**')
fciv.fciv_verify(actual_digests, reference_digests)

The verification performed by fciv.py reports mismatches between expected and actual file checksums. Files missing from and files in addition to that of the verification data are also reported.