This might sound like a really stupid question, but I need to know.
Say you've got an email on a service that uses end-to-end encryption, but requires a password that you and the receipient must agree on.
Obviously, you need to give them the password through some other channel, but what's the most secure? You can't email it across, obviously, and you can't use a phone because that would give your location (assume TOR is in use).
So what would you do?
>>53651023
Look into Diffie-Helman then kill yourself.
>>53651317
Welp. I have no idea how this works. Could someone care to explain the math?
tell them the password in person
>>53651317
How would you even implement this in an email client?
>>53651489
What if you can't meet them in person?
>>53651454
Wikipedia cares to explain the math, I care to assert your homosexuality is not an excuse to avoid research.
>>53651023
diffie hellman is just a meme OP
OTR though look into bitmessage email relays
>>53651023
Email encryption is typically done through public-key cryptography and no exchange of passwords is necessary. You can read more about it here.
https://en.wikipedia.org/wiki/Public-key_cryptography
>>53651598
Read the thread, faggot. OP has already admitted he's not going to research a goddamn thing or implement anything you suggest without holding his hand.
>>53651598
>>53651578
>>53651317
Thanks, but the email service I'm with uses that instead of PGP (!?!?!?!?) so PUBKEY is out the question.
And as for D-H you still need to give your recipient an integer, which can be intercepted. So how would you exchange them securely?
You might as well ask the original question - what is the most practical and secure way to exchange passwords?
>>53651698
Jesus, you might want to rereas that D-H article.
>>53651667
I spent ten minutes looking through it as closely as I could and I didn't get it. It's started to become a little clearer.
I am actually a bit of a noob with this, so bear with me for Christ's sake. A bit of patience on your part wouldn't go amiss, thanks.
>>53651733
Just did reread the relevant bit, and it's becoming clearer.
>>53651738
Literally look at the pretty picture on Wikipedia's D-H page (the paint colors).
Forget the math for a second and you'll understand the theory.
>>53651738
I split calling you a faggot and telling you to kill yourself into 2 posts. That's as patient as it gets on 4cjan
>>53651454
Concept:
You can't unmix paint, and given one or more buckets of mixed paint you can't find out what was mixed together.
We want to share a secret color of paint. We publicly agree on a starting color, then each choose a secret color and mix it with the starting color. Then we exchange buckets of paint, and we mix the paint with our secret color. We now both have the same mixed color, so we shared a secret.
Anyone who knows the shared color would also need to know our secret colors to mix the same shared secret, even if they've seen the color of the paints when we exchanged the buckets (can't unmix).
Mathematics:
Choose a prime number p and a primitive root modulo p, which we'll call g. Given g^a mod p knowing g and p, it's hard (discrete logarithm problem) to find a, which means that intercepting the stuff you exchange doesn't help an eavesdropper. (g^a mod p)^b mod p = (g^b mod p)^a mod p, so the procedure gives the same result at both ends. The exponents get pretty big so the computation may seem nasty, but there's an algorithm called modular exponentiation which lets you work it out quickly.
One problem of course is that Diffie-Hellman on its own does not authenticate the person you're sharing a key with. Depending on the method of communication you might have no way to verify that you're not sharing the secret key with a man in the middle.
>>53651785
Very funny. First thing I looked at. I'm still learning. You were a nub once, remember.
But my question now is, how would you go about implementing it? Telling the recipient to do this seems a bit too simple and easy for an eavesdropper to crack, so I'm assuming there's software that creates incredibly difficult functions based on the same principle, and I can't figure how you'd implement it then, or get your recipient to do it if they're not skilled on this sort of thing.
I'm probably over thinking something here.
>>53651885
I see. I got the concept already by now but thanks - how would you authenticate? What would be the best communication method?
>>53651698
bitmessage you cock guzzler
Meet in the middle of the night underwater in a submarine in the middle of the Atlantic with all the electricity shut off. Cup your fat, quivering lips next to his ears and whisper your code phrase "im a faggot that needs to be handheld"
>>53651986
and what if the other person is reluctant to download it?
And I can see problems if you have to exchange your usernames on BM and there's an eavesdropper - because instead of them getting your passwords they get your usernames and know which accounts to break into and sit in to intercept the passwords.
>>53652209
>is trying to learn
>asking questions
>gain knowledge
>use that next time combined with initiative
>clearly wants this
>wants to be handheld
Pick one, O Myopic One.
>>53651698
D-H can have everything intercepted and still be secure dumbshit
>>53652345
I've figured that out. Read the thread.
>>53651933
Authentication is actually really difficult with symmetric crypto where you have 1 key, the better solution is to use public/private key cryptography.
A private key can sign a message, a matching public key can verify it. A public key can encrypt a message that only a matching private key can decrypt. Look up RSA, that's the main algorithm here.
Let's say we met up sometime ago, and I gave you my public key. You've verified my identity in person, so you know for sure that the public key is legit. You're communicating with me and want me to authenticate myself, so you ask me to sign a message using my private key. I sign the message and send it back to you, and you verify it with my public key: this proves that you're talking to the person with the private key, if you trust that I haven't revealed that key to anyone, you can trust that it's me.
Only problem is, maybe we've never met. In that case, there are public servers holding public keys. I sign the message, you look up my public key online, verify the signature, if it's valid I'm legit. How do you trust that the key on the website is actually mine? A key can be signed. Let's say we both know a certain professor and trust him (and know his public key). I've met with the guy, he's verified my public key, signed it and uploaded the signature to the key server. When you download my public key, you can verify his signature on my key: if it's legit, this key was definitely signed by him. If someone you trust has signed my key, you can trust that it's me.
PGP works this way: when I send you an e-mail, I encrypt it with your public key and sign it with my private key. This way, only you can decrypt and read it (if I trust your public key, I'm sure only you will read it), and you're sure it came from me (assuming you trust my public key).
Mathematics behind RSA are pretty difficult to explain though.
>>53653169
One more thing about the e-mails, you actually don't encrypt the e-mail with RSA, you only encrypt a one-time use key you generate with which you actually encrypt the message using regular stuff like AES.
In general, you use signed messages to authenticate each other, share a key using Diffie-Hellman and use that key to encrypt the conversation with AES.
>>53653169
Don't use RSA. It can't be trusted anymore.
>>53651023
IRC
>>53653367
[citation needed]
>>53653582
factorization of semiprimes is the RSA moat. shors algorithm on quantum computers...exponential growth will have arbitrary-length semiprimes factored in practical time frames.
