pacman-bintrans VS Tutanota makes encryption easy

If you trust them with your keys, why not trust them with your plaintext? At which point, why bother with E2EE at all?

The answer should be "because one day web browsers will be able to pin specific versions of specific web apps, with specific hashes, corresponding to specific releases tagged in their repo, which have been audited by a certain threshold of auditors that I trust".

What that looks like in practice is probably some mixture of the following projects:

https://github.com/kpcyrd/pacman-bintrans

https://users.rust-lang.org/t/rust-code-reviews-web-site-for...

https://paragonie.com/blog/2022/01/solving-open-source-suppl...

Generally speaking, Transparency Logs for securing software distribution has been a research topic since around 2015, I also wrote my master thesis on the subject.

Sigstore is a Transparency Log intended for provenance and software artifacts which has support for a few different build artifacts. The container ecosystems also appears to be embracing it.

Cool practical example is pacman-bintrans from kpcyrd that throws Arch Linux packages on sigstore and (optionally) checks each package for being reproducible before installation.

https://github.com/kpcyrd/pacman-bintrans

https://www.sigstore.dev/

I think this is generally useful for a lot of ecosystems indeed, and it's cool to also see similar scoped projects pop up to address the these issues.

Reproducible builds are an important part of efforts to secure the software supply chain. Ideally you want multiple independent parties vouching that a given package (whether a compiled binary, or a source tarball) corresponds to a globally immutably published revision in a source code repository.

That gives you Binary Transparency, which is already being attempted in the Arch Linux package ecosystem[0], and it protects the user from compromised build environments and software updates that are targeted at a specific user or that occur without upstream's knowledge.

Once updates can be tied securely to version control tags, it is possible to add something like Crev[1] to allow distributed auditing of source code changes. That still leaves open the questions of who to trust for audits, and how to fund that auditing work, but it greatly mitigates other classes of attack.

[0] https://github.com/kpcyrd/pacman-bintrans

[1] https://github.com/crev-dev/cargo-crev

It's good that having a reproducible build process is a requirement for the Gold rating, as is signed releases.

Perhaps there needs to be a Platinum level which involves storing the hash of each release in a distributed append-only log, with multiple third parties vouching that they can build the binary from the published source.

Obviously I'm thinking of something like sigstore[0] which the Arch Linux package ecosystem is being experimentally integrated with.[1] Then there's Crev for distributed code review.[2]

[0] https://docs.sigstore.dev/

[1] https://github.com/kpcyrd/pacman-bintrans

[2] https://github.com/crev-dev/crev

> Of course, since these packages are built automatically without human supervision it’s likely that some of them will have bugs in them that would otherwise have been caught by the maintainer.

Human supervision isn't enough to protect the supply chain, and I can't think of a time that it's actually stopped an attack at the packaging stage, but having some extra "friction" in the process seems like it should be a benefit. Ideally an attacker would have to get past both the upstream author and the Debian maintainer, rather than these being two separate single points of failure.

Fortunately the Debian project is improving the situation with regards to supply chain attacks by continuing to work on Reproducible Builds. I think the next step from there needs to be Binary Transparency, with the adoption of the sort of approach being trialled by Arch Linux:

https://github.com/kpcyrd/pacman-bintrans

Hi HN, we are the developers from Tuta (formerly Tutanota), the German end-to-end encrypted email provider, and we recently released the world's first post-quantum encryption for email.

We have included a full technical write-up of the cryptography involved in these changes and we have released it for open public review.

This document specifies TutaCrypt, a protocol designed for hybrid email encryption in Tuta Mail. The protocol combines a classical Elliptic-Curve-Diffie-Hellman key exchange with a post-quantum KEM. The goal is to replace the usage of RSA in Tuta Mail.

In the remainder of this document we describe some preliminaries such as the cryptographic primitives used. We define the core algorithms of the protocol and describe the flow of messages between the communicating parties. Finally, we discuss the security properties and some limitations of the protocol in its current form.

We are eager for your constructive feedback. All cryptography related source code is available for review and experimenting here: https://github.com/tutao/tutanota/blob/master/src/api/worker...

If you have any questions or comments related to post-quantum cryptography please let us know in the comments!

Tutanota - Free secure email account service provider with built-in end-to-end encryption, no ads, no tracking. Free 1GB storage. Which is also partially open source, so you can self-host.

You are probably using a window manager and Electron is not able to detect the secret service backend you have installed. We recently switched to Electron’s built in api for storing credentials, which is the reason for this issue. https://github.com/tutao/tutanota/issues/6265

Tuta Mail (version 3.119.3): Encrypted email & calendar service - easy to use, secure by design.

A look at tuta.com and tutanota.com demonstrates that Tuta is using an Amazon Start of Authority (SOA) DNS record and 4 corresponding Amazon Name Server (NS) DNS records.

rich coming from tuta who still lack a onion based login. this ticket from 2018 was locked as off-topic. https://github.com/tutao/tutanota/issues/528

as lenin said, the best way to control the opposition is to lead it. for me, unless the company has been raided by the government they simply cannot be trusted.

apple proudly advertises privacy billboards while sharing everything they are asked under shadow laws. absolute hypocrisy and double standards. but then they wouldnt be where they are without government money and favours.

Have a non business paid account. Can you change your current tutanota.com email to the tuta.com email?

I have an at tutanota.com account. All of a sudden, this evening, it disconnected and I haven't been able to re-access my account. It actually seems like the whole platform is down, but maybe that's just the context from my devices.

I have a fairly recent free account that I believe was on the domain tutanota.com which I can no longer log into.