blastrock

Thanks for the link!

Funny to see that someone already thought of this attack in 2022

Very clever!

I am the author of one of the older guides https://blastrock.github.io/fde-tpm-sb.html .

I was wondering about the solution you propose which seems a bit complicated to me. Here's my idea, please tell me if I'm completely wrong here.

What if I put a file on the root filesystem with some random content (say 32 bytes), let's name it /prehash. I hash this file (sha256, blake2, whatever). Then, in the signed initrd, just after mounting the filesystem, I assert that hash(/prehash) == expected_hash or crash the system otherwise. Do you think it would be enough to fix the issue?

The encryption/upload is streamed, but the download/decryption is not, we will work on that. Thanks for the link!

Actually, Filekit is meant to be integrated into an application, and that application is responsible for delivering JS and handling identities, not the Tanker server.

No, the unlock key is for the user to keep, and never be transmitted by anyone else than the user themselves. If you do the transmission, it's not end to end anymore.

This option is only for users concerned about security, the other unlock methods are less strong but still provide security.

TweetNaCl is roughly equivalent to libsodium, on which Tanker builds. Tanker is easier to integrate into your app because it takes care of key sharing, multi-devices, user group managment, etc. These are all things you would have to handle by yourself using just a cryptographic library like TweetNaCl.

> how the Trustchain Private Key is "obtained".

The Trustchain private key is generated when you create a Trustchain. It is generated on your machine. You can try it and create a Trustchain yourself here: https://dashboard.tanker.io/

> And finally, if the private key really is generated on your service, we can just pack up and go home.

It is not :)

> What it sounds like you have is a PKI infrastructure with open source SDK and "end-to-end" encryption of things, as much as end-to-end applies for keys/trust roots generated anywhere but locally.

That's pretty much it. The trust root is that Trustchain key, and Tanker never sees its private part.

> Regarding the service, my main issue is that with an open source SDK you're aiming at a certain type of people, developers, like many of us, but I see no mention of the algos used which immediately causes me to lose interest (between that and the sales/marketing heavy website). If you're really targeting developers I would suggest losing the marketing babble and get down to brass tacks.

I take note of this. The parts targeted at developers available at the moment are the documentation, the code examples, and the SDK sources. We will write and publish something that explains how it works under the hood.

> Is libsodium WASMed for the browser?

It is not WASMed yet, but we are working on it.

> It would be nice if Tanker exposed the cryptography operations, so it could be a more re-usable library. Is this possible?

Tanker is more of a high-level library. It focuses on the ease of use, and tries to be hard to misuse, so it does the key handling and uses fixed algorithms.

You are right, you'd still have to trust the webmail/chat provider if you want to chat securely. Tanker still protects against data leaks from the app servers in this case.

We also provide SDKs for Android and iOS. They protect against more threats as you can install an app you know the provenance and the app doesn't auto update like a website that you reload every time you open your browser. If you are concerned about security, you could even compile the apps yourself in this case.

Tanker developer here. We use libsodium as our underlying cryptographic library. It uses XChacha20/Poly1305 for symmetric encryption, Curve25519 for asymmetric encryption and signature, and Blake2 for hashing.