So I've had this idea on my radar for a while, but here was my angle:

What if you made this a web extension, and took control of textareas everywhere on the web?

Why not be able to turn any message delivery (ex. facebook messenger) into a delivery for private messaging. What keybase used to be (a repository for peoples' public keys) would be a great integration point -- if the person has a public key listed (maybe in a twitter bio, etc), you can send them messages that are encrypted with a generated symmetric key + nonce (the usual safe enveloping rigor you need) -- and every message you send them might start with the URL or the actual encrypted message itself (and it would be up to them to use the extension to decode it).

It would be easy to get this working with a browser (a sufficiently powered web extension would do), but a bit harder to get it working on phones since the APIs aren't QUITE there, but IIRC there are some screen scraping APIs that could actually work (as long as your read the screen text, convert that to a message, then decode etc).

My friend and I implemented this a couple of years ago. It is no longer maintained but the general ideas still apply. Very few social media sites use standard text areas which makes maintaining compatibility a total PITA.

https://github.com/XCF-Babble/babble

There is another group that fully supports an E2EE Facebook https://github.com/DimensionDev/Maskbook

Thanks for the pointers! Keeping up with the changing components/data entry stuff for different websites would certainly suck.

Not exactly what you describe, but you might find Mailvelope[0] interesting.

https://mailvelope.com/en/

If memory serves well, mailvelope can actually be used for any text box so you can use it even in non-email contexts.

This was called PGP and it was cool for awhile

It was pretty good.

Should talk to the folks of Keyoxide [0] [1] to see how this aligns (Keyoxide is like Keybase identity parts, and then FOSS).

[0] https://keyoxide.org

[1] https://codeberg.org/keyoxide/

Keyoxide looks awesome, thanks for mentioning! I'm going to look deeper into it. As far as pubKey, the idea is really to keep it ephemeral. Most important steps would probably be looking into different crypto libraries and implementations, then UX.

They might be able to implement yours as a feature of theirs.

There's also https://keys.pub/

Oh cool. I did a similar thing using age [0] encryption: https://age-online.com/?receive_mode=1

[0]: https://age-encryption.org/

This is the most mature implementation I've seen so far. I'd be very interested in helping getting file encryption and integrations work through PRs.

Hey this looks great! Nice work.

It's good that you're taking steps to make sure your tool is completely client-side. Good job!

You're loading bootstrap.bundle.min.js from jsdelivr. This opens you up to an unnecessary supply-chain attack (i.e. if jsdelivr becomes compromised or malicious, it can ship a modified version that exfiltrates user data). You're also loading crypto-js.min.js from cloudflare, which has the same problem.

I would recommend moving both of those 2 script files to your own domain so that the user is only trusting 1 site instead of 3.

EDIT: I just noticed you are using subresource integrity to mitigate this problem. Never mind then, carry on!

I wonder if there is a popular way for the user to pin a hash of a webpage (to be warned if it changes)? IPFS probably has a way to do hashes of pages, but for other hosting methods, maybe a popular extension to verify contents of the site would be good. Like a hash for the whole page that can be verified. I think I saw a site specific thing for doing that but popularity across multiple sites would help adoption. It's weird that Some of the Javascript has resource hashes and some doesn't. Not that this makes it especially more secure...

Speaking of IPFS, I actually had it pinned for a bit and it worked great. I was going to look into Pinata, as I had used them years ago. Turns out they've completely pivoted to NFTs and the same plan costs 10x what it used to. I could host on my home server but don't want to leak my IP. Is IPFS over TOR a thing?

yup https://news.ycombinator.com/item?id=22094431

Thanks for this. Related to it, does anybody have any resources showing the state of the art for non-tech audience to remember client generated private keys?

What are options? Password manager (most people I know don't use one), Browser keychain (no guarantee of sync between user devices), WebAuthn (same problem), IndexedDB or localstorage, (both can be purged, again, no sync).

Unless I'm missing something, I feel this is problem worthwhile solving as a community, it would unlock a lot of utility/privacy for the average web user.

Would love to hear any more qualified takes on this.

Or base64 encoded as a document anchor in the url, like zerobin. This relies on bookmark storage (so, you start to worry about shredding such a key).

IMO the recent announcement of synced WebAuthn platform authenticators that’ll be supported by major platforms is probably the closest thing, at this point.

Thanks for this, I looked up recent Google I/O announcement, it had passed me by. iOS/MacOS has it in beta too, so you're right, we're getting close to half the problem improved.

Derive the key from password.

"Which protocol are you using?"

"It's in the code."

"Riiiight."

https://en.wikipedia.org/wiki/Security_Protocols_Open_Reposi...

I suggest using hash instead of query params so the keys are not sent to the server.

To be clear, you mean the fragment part of the URL, everything that comes after the pound sign. Not a cryptographic hash.

There are formal efforts to create 'decentralized identifiers,' including W3C DIDs[1] and KERI[2].

1. https://www.w3.org/TR/did-core/ 2. https://keri.one/keri-resources/

The former has good traction, why not support that? (they don't require a blockchain btw, though some implementations propose perhaps one of the most appropriate uses of one, simply to store public keys and revocations).

Nice. Had this idea and a prototype ready, 3 years ago. never got around to finalize it. Let me know how i can contact you and i can share some of my ideas, etc.

Let's see if this works ;)

https://www.pubkey.pm/msgIndex.html?hash=U2FsdGVkX19LN06nBQs...

Try replying with your encrypted email and I'll reach out!

U2FsdGVkX19NpXMRlLYzK2ueIj0WAXj2pkEGro8mAokAYqyEDk+XzNTJgBnuwuSQTsm4TEhbXHhq/Nljgfh9HX4gRSK2psekJFaV4PBP5jQo90TyHpZ8wpI6Bn6XkGowZchoo2dDh1ymE6xDwQKLfyoOZDENOBWm/L6OoRRPgb5eLL6IaiFCeR6ATe4ZLjoNSoy/v9ZrTmIiIw6U6mSPU8fxOHVIQChKY3VpNMSKEBNv62qz2iF8cw3/CclFg9NjNPKU/TkjYCd9AhWc8o89EvoiIosaKZsph9cjq+UsNiRobXjEWGcaLtuyvyCkcmyqfGzQkfrDNh3sXG7XeNxckfOUaJozEh+/TP4uYBls8dLvIGqRv+fa7gSB3J7XXowMEXT10T1SEMa4tFhNOFlzSXKCtzMUlN9Le9gebe6fBqM=

Pinged you

This is a great demo!

How long until it gets used to share dick pics?

post your pubkey and only you will know the answer

Similarly, I have a rough specification for something that builds much further out on this idea (towards the Keybase-style vision). Would love to get in touch.

U2FsdGVkX1/FFKGwfCgflTAvl5rr2RP+WSQ4n/tGHuMcFnD8JFfXJfoAzIHAVakHSOiiM7MnOsAZGT2jyh/+Sgs6mgN4wea6RnMx8dIXCItuu5g462RG9un8fHivYtqdTNBa3XLp8HDWsPXMHoEoiP4M1F9nrQhMREYFp2Q6fpiEpZY4q1a+VtGpLIjdVk2k788eMQjvYZh/vruzvx751HCzz/D+lsVSFJsOaoZQpqOTj4iD/kSludUkKY7v/vk8fcew4i88RtEc63oRgarLiBEu5rB1PGxCf32/8tVVjy4/B2QmQ8nYdL50SR4oeU52lb3pyciOweuJOiE88U+WdmQ4IJ+LNozGYE514vta5Qy2ZCHgHhHNTrs32X6n9+1w0Mv0Y8z/Cxf28Rm356pIPw==

Why is the pubkey "hash" sent to the server as a query, rather than staying client-side as a fragment?

Why does "Regenerate Private Key" not actually regenerate private key?

Why is the pubkey obfuscated by encrypting with "123NSA"?

How do I know the 624-byte pubkey "hash" doesn't contain the 32-byte private key?

How do I know the server isn't secretly harvesting IP addresses, associating them with pubkeys, and crawling referrer URLs for messages?

Kudos for using some sort of preexisting standard rather than pointlessly developing your own.

Can we get a quick summary of the whole crypto system?

It says:

> The URL generated contains an ECC curve25519 ciphertext (wrapped in AES simply to throw off SIGINT) that contains an armored version of the public key corresponding to the provided private key. People can visit this custom link and enter their message to encrypt it only for your eyes.

I don't quite understand the idea behind wrapping the ciphertext in AES, with a constant key of "123NSA".

The implementation is pretty short: https://www.pubkey.pm/index.js

The AES wrapping is exactly what prompted me to ask for an explanation :) That confused me too. I'm also wondering about using a vendored OpenPGP JS instead of WebCrypto, not sure if there's a reason but I'm wary since it increases the attack surface.

EDIT: Also confused about the multi-key encryption and ZKP mentions.

>Also confused about the multi-key encryption and ZKP mentions.

For scaffolding, I built upon a very cool PoC in its own right.

https://zkmulticrush.github.io

I've cleaned up the references to ZKP etc. My insomniac eyes didn't catch it.

Edit: The git repo has all the diffs between the two projects.

>wrapping the ciphertext in AES, with a constant key of "123NSA".

Posting the public key URLs publicly was a big part of the use case I imagined. It's well known that armored PGP text gets immediately swallowed up by all kinds of actors scraping the internet. Public keys are valuable metadata and can come in handy ten years down the line for an intelligence org. The AES thing is nowhere near a solution, but a tiny bandaid.

IMO this site should not allow key upload, forcing users to use ephemeral keys generated by the website, so they're only ever used for this purpose. Then you don't need to worry about them being public and can do away with the AES encryption. This is a cool site though, nice work!

It's not completely client side, because you have to hit a server to load the code. If anybody actually started using this for real, that'd be the weak link that would be (easily) attacked.

How would you attack it? It’s hosted on GitHub with ssl encryption and any changes would require someone to merge malicious code that would be obvious to any maintainer of the project. Everything is hackable to someone motivated and well funded but github should be pretty dang tough to penetrate.

That is assuming you would need to attack GitHub instead of just sending them a letter from a government office.

And that would then allow the attacker to…? Modify the code without a trace to intentionally insert malware? Access logs that don’t exist?

Interesting, I made something similar using a private server to store the messages. https://securely.so

I love this :)

Thanks popcalc! I was thinking about doing a show hn with this also :)

I think you need a way of not destroying the human readability of the chat - if I came here and there were piles of cipher text blobs I’d be very turned off

What makes this anonymous?

It's not that it makes anything anonymous, the usage was made for already anonymous spaces.

What spaces are anonymous?

Tons of communities on the internet allow you to be anonymous, is this news to you? HN is one of them, 4chan and Mastodon are two other examples, I'm sure you know of others too.

pseudonymous != anonymous

"anonymous" as in the real identity is unknown. You can literally post on 4chan without a account. On HN you can create account for each comment you make.

That doesn't mean your real identity is unknown.

That's always up to you of course. But it's different compared to say Facebook that forces you to use your real identity, and will work against you if you want to remain anonymous.

Even if you want to remain anonymous and don't deliberately reveal your identity you can almost always be identified anyway.

That's why services like HN aren't truly anonymous but pseudonymous.

It takes a lot of effort, a lot of knowledge and a lot of luck to stay truly anonymous on the internet... especially in the long run.

The only way to be sure you're never identified on the internet is to never use it at all.

No source code, no thank you!

Should have it linked within 15 min! Obviously I don't condone anyone to use this for serious things as of this stage.

Edit: Source repo in original post!

view-source (its all client side)

So, according to you every software is open-soruce as you can use "View Source" or "Inspect Elements" in the browser?!

If its all client side JS/HTML, yes.