Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Froot75547yIs there a shared secret that only you two know? Else I'd say it's impossible to be sure that the other guy is not an imposter.
Oh another thing, would it be feasible to physically deliver the message? 3 months is a long time
Also, your talking as if ISPs could be trusted now π -
Wack63117y@DGApps and how do you read your emails? Going to gmail.com? Good joke!
The end to end encryption is between the Google Server and the other person. How do you think your mails are decrypted? In the browser?
If you want end to end encryption, which I would suggest do use, you need a local mailclient like thunderbird or something to only decrypt them once they are on your computer. When Gmail decrypt it, google knows the content, a ISP or Government can potentially tamper with it, and so on... -
pk7611727yAssuming extreme distrust, can you send the other person a one time pad, then use that? The pad should be delivered directly.
-
@Wack ProtonMail and TutaNota are good end to end encrypted email services! (disclaimer: I'm a Tutanota user for a few years now)
-
Froot75547y@Wack How does key agreement validate the other end? I can't see a way to ensure the other person is who you think it is without a shared secret or a certificate of some sort. It seems impossible not in computer science level but on logic level. I could he missing something ofcource. If I am, please elaborate π
-
Wack63117y@Froot I'm no expert on that field, but the basic idea is to generate a shared secret, using a key agreement protocol (https://en.m.wikipedia.org/wiki/...). Once you have that shared key, you can use it in another encryption algorithm. Although it's pretty hard to break, it's still possible, so in an extrem paranoia case, you would generate a new key for every message.
-
Froot75547y@Wack Yea, that provides encryption but doesn't prove the other ends identity. That's why SSL site's have certs so you know who you are talking to.
Otherwise you can encrypt all you want but a middleman will intercept the key exchange.
It's like when SSL gets stripped in a man-in-the-middle attack. The attacker poses as the the site you're trying to connect to and issues its own response so you get an encrypted connection but only up to the attackers server. But SSL uses certs so you'll know your connection has been tampered with since the cert won't match the site. Of course if the cert authority gets hacked then all the site's it certified are fucked.
So in this case here, you still need something to prove the other ends identity, else it could be a middleman that your talking to not the real recipient.
Please do let me know if I'm wrong somewhere βΊοΈ -
Froot75547y@Wack Hehe ye that'd be awesome, I'll let you know for sure. Tho it seems impossible in principle. But I'd love to be proven wrong here π
-
Froot75547y@Wack Hmmm that's an interesting idea. Sadly I don't know pgp but from what I quickly learned from Wikipedia it seems like an encryption protocol? How is it different from for example AES256? Or am I understanding it wrong?
But the mesh network idea is cool. Perhaps you could have a predefined amount of hops and make it work somewhat similar to TOR? Tho I'm still not quite sure about that. -
Wack63117y@Froot not particulary pgp, but as I remember it, it is already implemented to be able to build a web of trust. There are I think 4 levels of trust: unknown, untrusted (default role), trusted (people you trust/people your trusted people trust), fully trusted (yourself, people you know personaly). *could be wrong about the roles*. Each user has their own trustes. So you will have different trusts/levels as I'll have an so on.
We could use it to only forward messages to our fully trusted contacts and have them forward it to theirs, if there's a connection, otherwise fall back to partaly trusted, and so on. -
Froot75547y@Wack Hmmm so identity validation based on mutual trust. I like that. Tho trust seems to be a vital part in that system. Say one of your friends gets blackmailed into leaking your stuff. Still, if you always send say 3 identical messages by 3 different routes and check for tampering in the end then it could work.
Tho it seems like if you expand and iterate this system you end up in with a group of globally trusted parties no? That'd be quite similar to current cert authorities.
Still, I like the idea -
Wack63117y@Froot well, the current system is built on trust. I'd argue, that in this scenario, you'd end up with different trust groups, like fraction a, and fraction b, and within those fractions other groups who trust or don't trust each other.
What's important when sending multiple messages, is to send "slightly" different content, so you can determin, when something is leaked/changed on what path it was changed. To get the right messages, you could use something like hamming codes/error correcting codes and flag wrong messages (independent if it's just a transmition error, or leaked (on purpose or unknowingly)) if people in a certain trust level got to many flags you exclude them/move them to a lower level.
Related Rants
Tinfoil hat time!
So, for this scenario we assume a world war has is in full swing, and all communications are either completely out or extremely monitored.
Additionally, no servers can be trusted and no ISPs can be trusted. Even when downloading software you cannot know if the software you got is tampered or not.
You have to send a message to a recipient you cannot physically contact, and you have to make sure him and only him get the message, otherwise nukes are deployed and we all die. The message has to arrive within 3 months or else it's too late.
Is it possible? If yes, how?
undefined
nukes
tinfoil hat
encryption