[HN Gopher] Show HN: PubKey - Communicate Privately in Anonymous...
___________________________________________________________________
Show HN: PubKey - Communicate Privately in Anonymous Public Spaces
A little while back I remember seeing a user on a certain anonymous
imageboard asking for an invite to a selective email host. Only
after a few minutes did the guy realize the perplexity of the
situation. How do you insure against a race condition in a public
forum with no way to direct message? Luckily, he nabbed the invite
code, but it got me thinking about using PGP to provide a solution.
This is meant to be a rough PoC and the UX is definitely not ready
for the average Joe, but the functionality I'd like to think is
there. What catbox.moe is to dropbox is what I'd like this to
eventually be to keybase. Btw, "this page uses NO SERVER" just
means it's static. I'm not trying to fool anyone lol. Edit: Source
Code: https://codeberg.org/popcalc/pubKey
Author : popcalc
Score : 118 points
Date : 2022-07-18 09:23 UTC (13 hours ago)
(HTM) web link (www.pubkey.pm)
(TXT) w3m dump (www.pubkey.pm)
| rapnie wrote:
| 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/
| gnufx wrote:
| There's also https://keys.pub/
| popcalc wrote:
| 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.
| aaaaaaaaata wrote:
| They might be able to implement yours as a feature of theirs.
| luke-stanley wrote:
| 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...
| popcalc wrote:
| 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?
| tepitoperrito wrote:
| yup https://news.ycombinator.com/item?id=22094431
| effisfor wrote:
| 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.
| ryukafalz wrote:
| IMO the recent announcement of synced WebAuthn platform
| authenticators that'll be supported by major platforms is
| probably the closest thing, at this point.
| ttyprintk wrote:
| 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).
| GoblinSlayer wrote:
| Derive the key from password.
| nikolay wrote:
| No source code, no thank you!
| nibbleshifter wrote:
| view-source (its all client side)
| nikolay wrote:
| So, according to you every software is open-soruce as you can
| use "View Source" or "Inspect Elements" in the browser?!
| nibbleshifter wrote:
| If its all client side JS/HTML, yes.
| popcalc wrote:
| 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!
| pmoriarty wrote:
| What makes this anonymous?
| capableweb wrote:
| It's not that it makes anything anonymous, the usage was made
| for _already anonymous_ spaces.
| pmoriarty wrote:
| What spaces are anonymous?
| capableweb wrote:
| 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.
| makeworld wrote:
| pseudonymous != anonymous
| capableweb wrote:
| "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.
| pmoriarty wrote:
| That doesn't mean your real identity is unknown.
| capableweb wrote:
| 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.
| kaoD wrote:
| I suggest using hash instead of query params so the keys are not
| sent to the server.
| [deleted]
| makeworld wrote:
| To be clear, you mean the fragment part of the URL, everything
| that comes after the pound sign. Not a cryptographic hash.
| motohagiography wrote:
| "Which protocol are you using?"
|
| "It's in the code."
|
| "Riiiight."
|
| https://en.wikipedia.org/wiki/Security_Protocols_Open_Reposi...
| hardwaresofton wrote:
| 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).
| keurrr wrote:
| 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
| hardwaresofton wrote:
| Thanks for the pointers! Keeping up with the changing
| components/data entry stuff for different websites would
| certainly suck.
| exabrial wrote:
| This was called PGP and it was cool for awhile
| rpdillon wrote:
| Not exactly what you describe, but you might find Mailvelope[0]
| interesting.
|
| https://mailvelope.com/en/
| rakoo wrote:
| If memory serves well, mailvelope can actually be used for
| any text box so you can use it even in non-email contexts.
| upofadown wrote:
| Kudos for using some sort of preexisting standard rather than
| pointlessly developing your own.
| postcynical wrote:
| 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.
| popcalc wrote:
| 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!
| postcynical wrote:
| U2FsdGVkX19NpXMRlLYzK2ueIj0WAXj2pkEGro8mAokAYqyEDk+XzNTJgBnuw
| uSQTsm4TEhbXHhq/Nljgfh9HX4gRSK2psekJFaV4PBP5jQo90TyHpZ8wpI6Bn
| 6XkGowZchoo2dDh1ymE6xDwQKLfyoOZDENOBWm/L6OoRRPgb5eLL6IaiFCeR6
| ATe4ZLjoNSoy/v9ZrTmIiIw6U6mSPU8fxOHVIQChKY3VpNMSKEBNv62qz2iF8
| cw3/CclFg9NjNPKU/TkjYCd9AhWc8o89EvoiIosaKZsph9cjq+UsNiRobXjEW
| GcaLtuyvyCkcmyqfGzQkfrDNh3sXG7XeNxckfOUaJozEh+/TP4uYBls8dLvIG
| qRv+fa7gSB3J7XXowMEXT10T1SEMa4tFhNOFlzSXKCtzMUlN9Le9gebe6fBqM
| =
| popcalc wrote:
| Pinged you
| Retr0id wrote:
| This is a great demo!
| motoboi wrote:
| How long until it gets used to share dick pics?
| Schroedingersat wrote:
| post your pubkey and only you will know the answer
| saint_abroad wrote:
| 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?
| mos_6502 wrote:
| 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/tGHuMcFnD8JFfXJfoAzIHAV
| akHSOiiM7MnOsAZGT2jyh/+Sgs6mgN4wea6RnMx8dIXCItuu5g462RG9un8fH
| ivYtqdTNBa3XLp8HDWsPXMHoEoiP4M1F9nrQhMREYFp2Q6fpiEpZY4q1a+VtG
| pLIjdVk2k788eMQjvYZh/vruzvx751HCzz/D+lsVSFJsOaoZQpqOTj4iD/kSl
| udUkKY7v/vk8fcew4i88RtEc63oRgarLiBEu5rB1PGxCf32/8tVVjy4/B2QmQ
| 8nYdL50SR4oeU52lb3pyciOweuJOiE88U+WdmQ4IJ+LNozGYE514vta5Qy2ZC
| HgHhHNTrs32X6n9+1w0Mv0Y8z/Cxf28Rm356pIPw==
| davidy123 wrote:
| 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).
| jstanley wrote:
| 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!
| balderdash wrote:
| 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
| kaoD wrote:
| Can we get a quick summary of the whole crypto system?
| jstanley wrote:
| 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
| popcalc wrote:
| >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.
| makeworld wrote:
| 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!
| kaoD wrote:
| 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.
| popcalc wrote:
| >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.
| nkcmr wrote:
| Oh cool. I did a similar thing using age [0] encryption:
| https://age-online.com/?receive_mode=1
|
| [0]: https://age-encryption.org/
| makeworld wrote:
| Hey this looks great! Nice work.
| popcalc wrote:
| 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.
| marksalpeter wrote:
| Interesting, I made something similar using a private server to
| store the messages. https://securely.so
| popcalc wrote:
| I love this :)
| marksalpeter wrote:
| Thanks popcalc! I was thinking about doing a show hn with
| this also :)
| tptacek wrote:
| 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.
| aardvarkr wrote:
| 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.
| gkbrk wrote:
| That is assuming you would need to attack GitHub instead of
| just sending them a letter from a government office.
___________________________________________________________________
(page generated 2022-07-18 23:01 UTC)