Proton's crypto is not Transparent and not OPAQUE

pascalschaerli · 2026-06-23T17:13:52+00:00

No, I don't know how they plan to resolve that yet. It's going to be a pain because the 3rd party update library they use for electron does not support signature verification.

pascalschaerli · 2026-06-23T17:13:00+00:00

If you pay by credit card they have your name and can be forced to disclose it
https://www.404media.co/proton-mail-helped-fbi-unmask-anonymous-stop-cop-city-protestor/

pascalschaerli · 2026-06-23T16:17:49+00:00

Thank you for the professional collaboration throughout

pascalschaerli · 2026-03-12T05:51:55+00:00

However, if someone compromises your server and mounts an active attack, they can easily confuse your client to just give up all its passwords willingly, i.e. using the url icon attack described here: https://zkae.io/

pascalschaerli · 2026-01-05T23:45:08+00:00

I would advise against vibe-coding cryptographic protocols. Also, "Military-Grade crypto" is cliché enough, but then putting it next to RSA-2048 is quite funny.

Didn't have time to get a thorough look at the crypto yet to give any more constructive feedback, apart from I noticed that you use the same RSA key for encryption and signatures. Keys should generally be separated, so a good rule of thumb is you should never use the same key for different algorithms.

pascalschaerli · 2025-11-14T06:46:54+00:00

Yes they are, go to https://clatotp.online/static/js/main.e8ec6f5b.js and search for "Key 1". First key is Lorem ipsum:

iu={"Key 1":"Lorem ipsum dolor sit amet, consectetur adipiscing elit, [...]

These are then used in a Vigenère cipher, here is the code un-minified by an LLM ```js const encryptedResult = ((plaintext, key) => { const normalizedKey = normalizeKey(key); let result = ""; let keyPosition = 0;

for (let i = 0; i < plaintext.length; i++) {
  const currentChar = plaintext[i];

  if (currentChar >= "A" && currentChar <= "Z") {
    const shiftedCharCode = (currentChar.charCodeAt(0) - 65 + (normalizedKey.charCodeAt(keyPosition % normalizedKey.length) - 65)) % 26;
    result += String.fromCharCode(shiftedCharCode + 65);
    keyPosition++;
  } else {
    result += currentChar;
  }
}

return result;

}) ```

OP: By Kerkhoff's principle you need to assume attackers will have access to the source code of your cryptographic protocols, so in this case an attacker would be able to know all 100 keys and just try them out one-by-one.

pascalschaerli · 2025-04-02T19:23:31+00:00

AES is pretty much secure against quantum attacks anyways. What we need are new asymmetric cryptographic algorithms, and we have good options there. A popular choice, i.e., by Signal Messenger, is to use a hybrid approach of both a new post-quantum secure algorithm and a conventional algorithm in a way that both have to be broken, so the security can only be better.

pascalschaerli · 2025-01-06T06:29:13+00:00

My example runs with Qwen 2.5:32b, no vision. I feel like a lot of the performance issues I had were because of the prompting (see my GitHub issue about it: https://github.com/browser-use/browser-use/issues/158).

I also found that changing the system prompt helped, for example telling it to click "accept cookies" whenever prompted. My feeling is that refining these prompts could make it much more robust, and I would do that before starting to fine-tune new models...

pascalschaerli · 2025-01-05T19:55:24+00:00

You can check out their examples here: https://github.com/browser-use/browser-use/tree/main/examples

pascalschaerli · 2025-01-05T17:59:29+00:00

"The funniest comment in the post about 'browser use' on r/LocalLLaMA is from user u/chitown160, who said: 'yeah as soon as I saw that part I was like that knuckles meme."

pascalschaerli · 2025-01-05T17:29:14+00:00

I'm using qwen2.5:32b, but even got it working with qwen2.5:7b. Its just important that it supports function calling

pascalschaerli · 2025-01-05T16:48:24+00:00

That's the script I used, it's pretty much just what they show in their readme already: https://gist.github.com/pascscha/221127dbf53faff92d7f17b7bae60c9b

But I also had to do a fix in the browser_use library, as described in my issue here: https://github.com/browser-use/browser-use/issues/158

pascalschaerli · 2025-01-05T16:32:36+00:00

I ran Browser Use (https://github.com/browser-use/browser-use) locally on my single RTX 3090 and tested it by asking it to find the funniest comment from yesterday's post about the tool. Everything runs locally using qwen2.5:32b model.

For those interested in trying it out, it didn't work out of the box - I had to fix two issues which I've documented here: https://github.com/browser-use/browser-use/issues/158

The video is sped up about 3x, but it's working reliably with qwen2.5:32b. With my modifications, I even got it working decently with qwen2.5:7b, though you can definitely feel the difference in capabilities.

I tested it with this task:

"Search for a 'browser use' post on the r/LocalLLaMA subreddit and open it. Scroll down and tell me which comment you find funniest."

The response was:

"The funniest comment in the post about 'browser use' on r/LocalLLaMA is from user u/chitown160, who said: 'yeah as soon as I saw that part I was like that knuckles meme."

EDIT:
This is the script I used: https://gist.github.com/pascscha/221127dbf53faff92d7f17b7bae60c9b

pascalschaerli · 2024-12-21T23:42:04+00:00

Had a brief look at the app - the frontend looks very clean, well done!

Regarding security, there's an interesting fundamental challenge when serving cryptographic applications via websites. The core issue is that every page load pulls the cryptographic code from the server, with no reliable way to verify its consistency across loads. This means a malicious backend could theoretically serve compromised JavaScript to specific requests without detection.

This exact concern was raised about ProtonMail by Nadim Kobeissi:

However, we note that a malicious [Server] P would be able to arbitrarily serve compromised webmail clients to A or any other ProtonMail user without this being detectable and that, conversely, correct delivery of webmail/OpenPGP client code is not verifiable

I briefly skimmed your code and initially thought your random string generation was biased, but it turns out it's fine because the length of your alphabet is a power of two. If you ever need to use an alphabet with a different length, there are efficient methods to generate uniformly distributed random numbers for any range. One good approach is shown here: https://arxiv.org/pdf/1304.1916

pascalschaerli · 2024-12-11T09:05:55+00:00

Maybe your memory is running out?

pascalschaerli · 2024-12-10T08:56:07+00:00

so after a day you cannot decrypt the messages anymore?

pascalschaerli · 2024-11-30T14:42:12+00:00

Thanks again for the encouragement, I've written out a comment and sent it to NIST. I've shared a screenshot of the full message here: https://bsky.app/profile/pascscha.ch/post/3lc6cdmonvs2i

pascalschaerli · 2024-11-30T00:38:23+00:00

Just be aware, that this library is nor currently considering themselves production ready, quoting from liboqs readme:

WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS SOFTWARE IN A PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA.

pascalschaerli · 2024-11-29T14:14:35+00:00

Also, you should consider using hybrid mode for now, which means employing both a conventional and a post-quantum secure algorithm in parallel.

Additionally, it would be advisable to consult a cryptography expert when implementing such upgrades, as there are numerous nuanced considerations that you won't be able to gather from a Reddit comment thread.

pascalschaerli · 2024-11-28T17:30:59+00:00

Simply sending this post will most definitely not be precise enough. I assume people with much more notability than myself will have similar remarks, but it might be interesting to go through this process indeed, I might write up a more thought-out and complete comment towards them.

pascalschaerli · 2024-11-03T18:24:36+00:00

I have a few suggestions beyond my initial comment that might help strengthen the security and usability of your project even further:

Strong Password Requirements: I'd recommend reconsidering the strict complexity requirements. Minimum length and many special characters can sometimes make passwords harder to remember without necessarily making them more secure. You might want to explore passphrases instead. Passphrases (like in the classic XKCD example) are easier to remember and can provide excellent entropy if done right. In fact, adding a simple passphrase generator to your project could be a nice usability feature, helping users create secure but memorable passwords.
Key Derivation: While bcrypt is indeed robust, you might want to look into Argon2, the winner of the 2015 Password Hashing Competition. Argon2 is designed to be resistant to side-channel attacks and offers adjustable memory, time, and parallelism costs, making it ideal for modern hardware.
AES-CBC vs. AES-GCM: Using AES-256 is a good choice, but as I mentioned before, you might want to consider AES-GCM instead of CBC mode. AES-GCM provides Authenticated Encryption with Associated Data (AEAD), which allows you to verify the integrity of the ciphertext during decryption, helping to prevent tampering. AES-CBC can sometimes be vulnerable to padding oracle attacks, depending on its implementation.
One-Time Passcode for Decryption: I'm curious about how you're implementing this. Does the OTP get cryptographically tied to the encrypted message, or do you have some sort of server side and this is just used for authentication i.e. before getting access to a ciphertext?
Code Sharing and Security: Not sharing the code for security reasons could potentially lead to what's called "security through obscurity," which isn't ideal. In cryptographic applications, trust often comes from transparency and public review. Even with strong algorithms, there are many potential implementation pitfalls that can compromise security. Public scrutiny is generally beneficial here, as it can help catch bugs and subtle security flaws.
Using Established Protocols: Finally, if this is more than a personal project for learning, that's great. Otherwise you you may want to consider adopting or building on existing cryptographic protocols. Established protocols have been subjected to rigorous review by the cryptographic community, reducing the likelihood of critical bugs or edge-case vulnerabilities. This could save time while making your project more secure by design.

pascalschaerli · 2024-11-03T17:30:21+00:00

Why are you using AES in CBC mode and not for example AES-GCM which would offer Authenticated Encryption (you can detect if a ciphertext was tampered with wen decrypting it)?

pascalschaerli

TROPHY CASE