nextgens

The original freenet design was replicating content as it was requested. You had no way of locating "all" the copies as they would get cached "along the way" elsewhere on the keyspace when you request them.

That property was useful both for improving availability AND censorship resistance: you could not attempt to "locate" where the blocks are without spreading them.

My naive understanding of the new design is that you can have contracts that are replicated... but they still cluster around the same place in the keyspace so any capable active adversary can actively deny access to content trivially. Did I misunderstand something here?

Thank you for the downvotes.

You're moving the debate here. The question was "How are the goals different?" from the project leader (who ought to know better), not whether moving them makes sense.

You're getting this wrong.

He has forked the project (to something that does not share the same goals so "fork" is arguable here), took the name, the cash and the goodwill.

We went from "we have enough donations/donators" to "how do we pay for the upcoming AWS bill?".

As someone who has been fairly active on the "old freenet", I have never cared about money nor funding... but I cannot help but notice that some has likely been misappropriated. Things like the SUMA award (https://web.archive.org/web/20150320201527/http://suma-award...) were awarded specifically for "protection against surveillance and censorship" that the "new freenet" does not even aim to provide.

"The board" of the non-profit seems to have been culled just before the decision. I don't know why, I wasn't on it. Maybe @agl can shime in (he was).

All I know is that this could have been handled better. It's what I wrote back then on https://www.mail-archive.com/devl@freenetproject.org/msg5527...

I've abstained form interfering until now... but have you honestly forgotten?

Please explain how "the new freenet" tackles censorship resistance.

https://web.archive.org/web/20001017133926/http://freenetpro... "Freenet is a peer-to-peer network designed to allow the distribution of information over the Internet in an efficient manner, without fear of censorship."

https://web.archive.org/web/20050201110519/http://freenetpro... "Freenet is free software which lets you publish and obtain information on the Internet without fear of censorship."

https://web.archive.org/web/20150206152355/https://freenetpr... "Share files, chat on forums, browse and publish, anonymously and without fear of blocking or censorship!"

today: "Hyphanet is peer-to-peer network for censorship-resistant and privacy-respecting publishing and communication."

the new freenet: ?!?

Meshcore's crypto is interesting.

ECB, issues with key generation, key negotiation, seldom authenticated data, ...

It definitely works better than MT but please stop lauding it for its cryptographic properties ;)

It's at the bottom of their TODO, under the heading "V2 protocol spec".

TLS1.0 introduced modularity via the concept of "extensions". It's everything but a minor evolution of the protocol.

One of the many things it brought is session tickets, enabling server-side session resumption without requiring servers to keep synced-up state. Another is Server Name Indication, enabling servers to use more than one certificate.

TLS1.0 introduced modularity via the concept of "extensions". It's everything but a minor evolution of the protocol.

It would be great if Google supported rfc8414 and rfc7591. Right now most MUAs hardcode credentials instead of auto-discovering/registering/configuring them and decline to implement those standards "because the big boys don't support them". The practical result is that one cannot use oauth2 on their domain easily: the MUA needs to be told about which set of oAuth2 creds to use.

See https://searchfox.org/comm-central/source/mailnews/base/src/... , https://github.com/thunderbird/autoconfig/tree/master/ispdb and https://bugzilla.mozilla.org/show_bug.cgi?id=1602166

As one of the maintainers of Mailu, I'd say use Mailu!

Why? three main reasons: (a) security (as you have identified isolation matters, but that is not the only thing), (b) get the benefits of "battle-tested" setups and (c) features

On security: in its default config, Mailu scans emails for malicious macros via oletools (and optionally viruses via clamav). It also uses a hardened-malloc, Snuffleupagus (a security module for PHP), gates all PHP code behind an authentication wall (webmails), ... and does both DANE and MTA-STS validation to ensure your emails are delivered to the right place. The authentication stack handles "smart" rate-limiting: you get to limit the number of authentications with distinct credentials over a time-period (a misconfigured thick client won't trigger it), you have plenty of ways to avoid running into it (application tokens for thick clients, per-device cookies that give you a way out, whitelisting of "used" addresses, ...) and you also get to rate limit the number of sent emails (useful if a spammer gets their hands on the credentials of one of your users)

On the importance of "battle-testing" setups: well, there are plenty of non-subtle ways of breaking an email setup. Experience has shown that all the layers in the stack can be problematic... I can give you a bunch of examples of what we ran into recently if you want.

On features: your setup might be simpler but your users are missing out. Whether it's enhanced filtering (like with oletools), better indexing (full text search), indexing of attachments (with OCR! via Apache Tika), configuring server-side rules with managesieve or just "having an interface" to configure ooo, change their passwords, configure aliases or delegate permissions.

I have started spending time on Mailu because I don't like the bloat that comes with Mailcow. Give Mailu a shot; it is reasonably easy to debug when things go wrong (and not written in PHP :p).

Mailu is a simple yet full-featured mail server as a set of Docker images. It is free software (both as in free beer and as in free speech), open to suggestions and external contributions. The project aims at providing people with an easily setup, easily maintained and full-featured mail server while not shipping proprietary software nor unrelated features often found in popular groupware

If you need any help, our support channel is on https://riot.im/app/#/room/#mailu:tedomum.net

No, and it doesn't protect the privacy of the viewer either!

Mailu - a mail server as a set of Docker images.

Sure you can defeat it using specialized tools... but at that point, you are far from "all I need is a pen" and opportunistic attacks. The tool will have to match the width of the zipper: you'll need a collection or to have done reconnaissance.

At that point, shimming the zip-tie itself is probably easier/faster (and doable without specialized tools).

Yes, we're talking about an attack against the zipper (and not the zip tie nor the bag)

The goal here is tamper evidence... sure you can open the bag through the zipper but you won't be able to close the zipper back if you can't move the sliders.

Use the zip-tie to "anchor" the slider too... that will defeat the pen trick.

What's the shortest chain-size that those free CAs can offer (assuming android>=5.0 devices)?

It would be great to have a tool somewhere that matches client handshakes & supported CAs vs server config & choice of CA chains

The answer is complicated.

IMHO It's clearly better than no TPM... as for whether it's better or worse than a physical chip, it's a different trade-off.

One one side you have:

- higher speed

- higher protection against physical attacks (if only because the die is larger... it's smaller and the "bus" isn't as trivial to interact with)

On the other:

- new side channels (think spectre, meltdown & friends) and they are probably easier to exploit thanks to the higher speed (more samples)

- more parties to trust (microcode, ME, ...)

- erasure is harder

For the specific purpose of hardening passphrases/keys ... use both. :p

https://en.wikipedia.org/wiki/FIPS_140-2#Level_2

It definitely does when there is no attempt made at protecting against it. L2 means "tamper evidence", you need L3 for things to start to be designed to prevent it from being "basic".

SGX is L3, you'll be hard pressed to find a TPM that does better than L2.

Phrasing it another way: Even if you don't have the skills/equipment to do it. How much do you think it costs to get someone to do it for you? How reproducible is that process? Why are we assuming it's hard?

What I'm argueing in my talk is that it shouldn't be. Odds are your phone does it better :)

Decaping a chip from a lost laptop is far from science fiction and can be performed at a fixed cost. Mitigation is super-cheap... There's just no good reason to store the "final" key on the TPM.

Here I interleave rounds of argon2id (configured with parameters that fit my system: use up all the RAM and all the cores since there's nothing else to do in the initrd) with HMAC rounds from TPM and/or SGX (configured with the right policies so that they rate-limit and only unlock if the PCRs check out).

The PIN isn't required if you decap the TPM.

It's amazing that you disregard the most basic attack in your threat model (https://safeboot.dev/threats/): going after the TPM itself. TPMs are usually FIPS 140-2 L2: not something that's meant to be hardened against even basic hardware attacks.

IMHO the TPM should be a required piece but not the only piece of the puzzle. If I loose my laptop, I don't want the goods to be protected exclusively by a key that's trivial to recover from it (stored in something that's not a secure-element).

I've covered it in a talk I gave at 44con: https://www.youtube.com/watch?v=YZTWjLTz4AE

tl;dr; Use the TPM (and potentially other technologies like SGX) as part of your KDF to strengthen PIN/passphrase that the user provides. This breaks the asymmetry of offline attacks (attacker will always be bound by TPM/SGX-speed). Do NOT give it the only key required to decrypt your data.

That's basically what we've done with https://safepass.me/ and https://pwncheck.me/ ... and HIBP is the dataset we ship to our customers by default. If you are still looking to validate passwords when they're set, give me a nudge :)

We don't advertise the linux/PAM support since we have failed to find a market for it (usually things end up being hooked up onto AD one way or the other)...

Let me know how it goes; if our sales droids don't come up with something acceptable on their own, I am keen to understand why and will work something out for you.

I am affiliated and no, you don't need to sign-up to get a preview:

We have a video that shows how to set it up and basic operation: https://safepass.me/demo-video

We have a free "home-use" license: if your PC isn't hooked onto AD, it will just work. https://safepass.me/get-the-documentation https://safepass.me/download (the MSI)

Check https://safepass.me out (an active directory password filter)

Sure, but you can't "consolidate" them without re-transferring everything (typically differential snapshots)... whereas with native encryption, you just delete the snapshot.

Many things... here are the ones I care about:

- you can have different keys for all your "partitions" without having to pre-allocate them

- you can send encrypted incremental snapshots to a host that doesn't have the key (for backups for instance)

- it's using authenticated encryption (as opposed to LUKS with XTS)

The most effective trick it uses requires the ability to send custom HTTP headers... that wouldn't work as a bookmarklet.

They make it clear that it's not the listing of the addon on AMO that makes it subject to their policies (and local laws)... it's the signing itself.

So yeah... I can provide an unsigned copy of my add-ons to users... but unsigned add-ons are by design awkward to side-load :/

I am the author of that add-on ... what would you do in my shoes ?

  - provide an XPI (that will only benefit the few since the side-loading process is made awkwarder at every point release) ?
  - fight it ? If so, on what grounds and how ?
  - something else ?