💾 Archived View for bbs.geminispace.org › u › mozz › 14357 captured on 2024-05-26 at 16:04:26. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-05-12)

➡️ Next capture (2024-06-16)

-=-=-=-=-=-=-

Comment by ☕️ mozz

Re: "Surveillance in Gemini"

In: s/Gemini

TLS 1.3 already has a mechanism for padding responses for this reason, you're better off using that than trying to implement something gemini-specific.

— https://datatracker.ietf.org/doc/html/rfc8446#section-5.4

☕️ mozz

Jan 25 · 4 months ago

2 Later Comments ↓

🤖 gamma · Jan 26 at 01:41:

Great point about TLS 1.3. Clients and servers could both use that to mask content length.

🚀 ElectricalDance · Jan 26 at 13:02:

What you are describing is basically what High latency mix network used to do in the early 90. In short, you could send them a PGP encrypted e-Mail and they would store it and then forward it after a certain time (few hours usually). You can search Mixnet, cypherpunk remailer if you want more information about this.

TLS was never built to do this. It’s was created against "trivial" interception between you and the sender and to secure online shopping.

Original Post

🌒 s/Gemini

Surveillance in Gemini — Adversary can tell very specifically which one gemini page a user is requesting, based on the size of server response. There is no need to decrypt the channel to learn which page is transmitted there, the only thing that matters is the size of that message. The same thing works all the way around, if someone has submitting a picture or a text to the gemini forum, adversary can see corresponding portion of encripted traffic going from specific user. Again, there is no...

💬 nikhotmsk · 6 comments · 3 likes · Jan 25 · 4 months ago · #privacy