@cypherpunks@lemmy.ml
@cypherpunks@lemmy.ml avatar

cypherpunks

@cypherpunks@lemmy.ml

cultural reviewer and dabbler in stylistic premonitions

This profile is from a federated server and may be incomplete. Browse more on the original instance.

cypherpunks, (edited )
@cypherpunks@lemmy.ml avatar

Works fine on Sync :,)

It sounds like Sync is either blocking users client-side (which would be confusing, since server-side blocks do exist), or it is trying and failing to add a block server-side but suppressing the server’s error message.

either way, it sounds like a bug.

do you know where the project’s github is so someone can open an issue about it? /s (explanation here on mouseover)

cypherpunks,
@cypherpunks@lemmy.ml avatar

Since he doesn’t mention it in his ‘fantastic’ reporting, OpenSSH 9.6 was released Monday that will patch this attack.

I am tempted to delete this post just for the article’s stupid clickbait headline, but it still will probably cause some people to go update their OpenSSH installs, so… meh.

Anyone who actually wants to know details of the vulnerability should read the website about it which is obviously much better than this article.

Also, since he doesn’t mention it, if on the Internet, the MITM would have to be installed at both end points (client side and server side) to be effective without the patch.

Huh? No. The attacker doesn’t need to be in two places or even near either end per se, they could be located at any fully on-path position between the client and server.

cypherpunks,
@cypherpunks@lemmy.ml avatar

If your local censor is not effectively blocking Tor, then you can just use Tor Browser to access lemmy.ml’s normal address via an exit node. Onion services don’t particularly help with circumventing censorship that is performed by the ISP of the user.

Onion services are useful for removing load from the exit nodes (since connections to them don’t need to go through exit nodes) and for having a self-authenticating address that doesn’t immediately reveal the location of the server. However, the location-hiding properties of onion services are not actually very strong at all (note that they used to be called hidden services and mostly aren’t anymore) and should not be relied upon. There are many adversaries who can locate a “hidden” service in a relatively short period of time. So, onion services are only potentially useful for resistance of censorship at the server’s location in the short-term and/or against weak adversaries.

cypherpunks,
@cypherpunks@lemmy.ml avatar
cypherpunks,
@cypherpunks@lemmy.ml avatar

oops you beat me to it, though i put it in the 50s (it started in 42 but i think its iconic phase was more in the 50s)

cypherpunks, (edited )
@cypherpunks@lemmy.ml avatar

i thought this might fit but the first episode was 1969 so it doesn’t really

cypherpunks,
@cypherpunks@lemmy.ml avatar

J.G. Hertzler and Vaughn Armstrong have entered the chat

cypherpunks,
@cypherpunks@lemmy.ml avatar

You have a few options.

My preferred way is to create an encrypted disk image using LUKS, backed by a sparse file. Sparse means that, while you’ll still need to specify a size for the encrypted volume, it won’t actually use the space on the underlying disk until you use the space on the encrypted volume. You could even make the encrypted volume bigger than your physical disk (though of course you’d get an error if you tried to actually use that extra space).

There are a few ways to setup a LUKS container; if you want to learn how to do it manually, this howto i just found looks like a good overview of the steps (though I wouldn’t recommend doing its final Setup auto mount section).

These days, you can also create a LUKS volume on a sparse file entirely using a GUI such as the GNOME Disks program. Using it, just click the hamburger menu and select “New Disk Image” and then with your new disk image selected click the gears menu and “Format Partition” and there should be a checkbox for LUKS on that screen. If you leave “Erase” turned off (which is the default), then the backing file will be sparse.

One downside to the sparse disk image approach is that when you delete files from the encrypted volume you will not regain that space on the outer disk automatically. It is possible to, but requires work to do so which I won’t try to document here.

Another approach which doesn’t have that downside is to use eCryptfs instead of LUKS. It stores each encrypted file separately (with an encrypted name) and thus doesn’t hide the directory structure or file sizes - only directory and file names and file contents are encrypted. It also appears to have not been updated since 2016, but, it is still included in various distributions so it is also an option. You can read about how to use it (and other caveats about it) on the arch wiki.

cypherpunks,
@cypherpunks@lemmy.ml avatar

that creates encrypted archives, but doesn’t provide a mountable filesystem (which is what OP means by “real-time”).

cypherpunks,
@cypherpunks@lemmy.ml avatar

tomb looks like a nice wrapper around LUKS but it doesn’t appear to support creating a sparse file, so, it will immediately use however much space you allocate to it.

(I think it doesn’t support a sparse backing file because I searched the word “sparse” on their github, and for the word “seek” (which is the dd argument for creating a sparse file) in the tomb bash script, and both searches yielded no results.)

  • All
  • Subscribed
  • Moderated
  • Favorites
  • localhost
  • All magazines
  • Loading…
    Loading the web debug toolbar…
    Attempt #