The attack worked, the password is cmF0dGEK.

This was obtained by generating 32 possible plaintexts for the first 10 bytes of system.zip (based on the different values in the headers of ~300 zip files on my system), plus three null bytes for the high bytes of compressed size, file name length and extra field length.

The inner zip files are just stored, uncompressed:

Archive: update.zip
Index Encryption Compression CRC32    Uncompressed  Packed size Name
----- ---------- ----------- -------- ------------ ------------ ----------------
    0 ZipCrypto  Store       d1bca061     65761967     65761979 system_lib.zip
    1 ZipCrypto  Deflate     64a3f383         2183          741 config.json
    2 ZipCrypto  Store       3731280f     89300292     89300304 app.zip
    3 ZipCrypto  Store       a2bd64f5    135518964    135518976 app_lib.zip
    4 ZipCrypto  Store       700eb186      5996410      5996422 system.zip

So 12 bytes from the original content.

The entries in update.zip are encrypted using the weak ZipCrypto scheme, which is known to be seriously flawed. If you feel motivated, and can guess at least 12 bytes of plaintext for an entry, it is possible to recover the internal state of the generator, which is enough to decipher the data entirely, as well as other entries which were encrypted with the same password. The bkcrack project implements this attack.

Since some of the entries are zip files themselves, it is within the realm of possibility to guess 12 bytes of plaintext. Parts of the zip local file header are pretty static, and you can use some of the values from the local file header of update.zip itself. Still, this would require a bit of luck / inspired guesswork.

The insight is that c^2 + d^2 factors as (c + id)(c - id) in the Gaussian integers, and shuffling factors in its square and multiplying gives both sides of the identity.

This is a special case of the Brahmagupta–Fibonacci identity.

According to the identity, (c^2 + d^2)^2 = (c^2 - d^2)^2 + (2cd)^2 which are the expressions you found for a and b (modulo sign)

Options:

• Just start it from the terminal with torsocks
• Use application-specific proxy settings
• Since torsocks simply uses LD_PRELOAD, you could try to make this apply globally by adding the torsocks library to ld.so.preload. Just put the path returned by torsocks show in /etc/ld.so.preload.

Either use the --proxy option of yt-dlp, or use torsocks to transparently torify any application.

singlelogin.re still worked for me recently.

Source

You can take the package from the Ubuntu PPA, which is generally updated quickly, and rebuild for Debian using the instructions here.

According to Wikipedia:

In March or April 2023, it dimmed to magnitude 12.3. A similar dimming occurred in the year before the 1946 outburst, indicating that it will likely erupt between April and September 2024.

Yes, for example, syncing on a kernel panic could lead to data corruption (which is why we don’t do that). For the same reason REISUB is not recommended anymore: The default advice for a locked-up system should be SysRq B.

Edit i2psnark.upbw.max in i2psnark.config (this can be in a number of locations based on install type and platform - just search for it).

Or you can remove the maxlength and size attributes from the text input, it will save just fine.

https://linux-tc-notes.sourceforge.net/tc/doc/cls_u32.txt:

The base operation of the u32 filter is actually very simple. It extracts a bit field from a 32 bit word in the packet, and if it is equal to a value supplied by you it has a match. The 32 bit word must lie at a 32 bit boundary.

There is no central naming authority in I2P. All hostnames are local. (Naming and Address Book)

Therefore, if an url doesn’t work, it isn’t in your local address book.

You can add mappings yourself if you know the destination or b32 address, or make use of subscriptions. In this case, add http://i2p-projekt.i2p/hosts.txt and http://notbob.i2p/hosts.txt to your address book subscriptions, the latter contains the destination for mysu.i2p.

Try perhaps the solution in https://unix.stackexchange.com/questions/648084/docker-interface-tears-down-wifi-internet

Yes this is sane and one of the main use cases for encrypted lease sets. Encrypted lease sets make it impossible for unauthorized users to connect to your hidden services.

If you know beforehand that only one client needs to be able to connect, choose “DH” as a security strategy, and share the client’s key with the server. This article explains these concepts in detail.

If you don’t care about anonymity (given the 0-hop tunnels), you could also stick both hosts on an overlay network like Yggdrasil. This may or may not be more convenient / performant based on the number of services you want to expose.

I think glider can do this, with -strategy rr (Round Robin mode). I have not used it in this way myself, so you might need to experiment a little. Proxychains can also do this, but it doesn’t present a socks5 interface itself (it uses LD_PRELOAD, so it won’t work everywhere).

Argon2id (cryptsetup default) and Argon2i PBKDFs are not supported (GRUB bug #59409), only PBKDF2 is.

There is this patch, although I have not tested it myself. There is always cryptsetup luksAddKey --pbkdf pbkdf2.

GRUB works just fine with LUKS2 these days. There is no need to switch bootloaders.

Consider the string abc. From the end, moving backwards, when does it match \w+, and what does it match? When it reaches c, it matches c. And from the front, moving forwards? When it reaches a, it matches abc. This is why it acts differently.