Skip to main content
Cryptography

Return to Answer

replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1

in practice

A friend of mine needed help with her website and asked how to send me her login information securely. I've never known how to do this

The current best-practices way to let you access someone else's website is using SSH, the Secure Shell.

Send your public key to that person (in the open, with unencrypted email or etc.). Then have that person confirm it really is your public key (there are a variety of ways of checking). Then have that person log in to the website (perhaps using ssh) and append your public key (typically in a file named "id_rsa.pub") to the end of the "~/.ssh/authorized_keys" file in that account on the website.

That authorizes you to log in to that account using ssh in the normal way, using only your own private key and without knowing your friend's password or private key, and without your friend or anyone else knowing your private key.

http://en.wikibooks.org/wiki/Internet_Technologies/SSH has some step-by-step tips on how to create a private key (if you don't already have one), derive the corresponding public key from it, copy it to a remote server, log in with ssh, etc. (The Information SecurityInformation Security site is another place to ask for information about using ssh).

in theory

Your friend can encrypt the login information and send you the encrypted package. But how are you going to decrypt that package? You need the decryption key for that, right?

If you ever discover a way to securely send that decryption key -- why don't you send the login information directly the same way?

You have discovered the one problem with the one-time pad and with symmetric cryptography in general: the key exchange problem.

If you're just doing this for fun, you might consider using "t=n: trivial secret sharing", using XOR to create a set of messages sent through a variety of paths (a few messages sent through separate emails, IMing, phone calls, etc.) so that the only way to reconstruct the login information (or the decryption key) is to get all of the messages. But there are better methods.

In practice, the best solution we have so far to the key exchange problem is asymmetric cryptography, also called public-key cryptography. The RSA algorithm (the "rsa" in the "id_rsa.pub" mentioned above) and Diffie–Hellman key exchange (D-H) are currently the two most popular and widely-used asymmetric cryptography techniques. The clever part about D-H is that it doesn't actually send the secret key from Alice to Bob or from Bob to Alice -- instead, the algorithm generates a fresh new secret key from the (publicly transmitted) random bits Alice and Bob send each other, in such a way that Alice and Bob both end up with a copy of the key, but no one else listening to their conversation can get a copy of that key.

in practice

A friend of mine needed help with her website and asked how to send me her login information securely. I've never known how to do this

The current best-practices way to let you access someone else's website is using SSH, the Secure Shell.

Send your public key to that person (in the open, with unencrypted email or etc.). Then have that person confirm it really is your public key (there are a variety of ways of checking). Then have that person log in to the website (perhaps using ssh) and append your public key (typically in a file named "id_rsa.pub") to the end of the "~/.ssh/authorized_keys" file in that account on the website.

That authorizes you to log in to that account using ssh in the normal way, using only your own private key and without knowing your friend's password or private key, and without your friend or anyone else knowing your private key.

http://en.wikibooks.org/wiki/Internet_Technologies/SSH has some step-by-step tips on how to create a private key (if you don't already have one), derive the corresponding public key from it, copy it to a remote server, log in with ssh, etc. (The Information Security site is another place to ask for information about using ssh).

in theory

Your friend can encrypt the login information and send you the encrypted package. But how are you going to decrypt that package? You need the decryption key for that, right?

If you ever discover a way to securely send that decryption key -- why don't you send the login information directly the same way?

You have discovered the one problem with the one-time pad and with symmetric cryptography in general: the key exchange problem.

If you're just doing this for fun, you might consider using "t=n: trivial secret sharing", using XOR to create a set of messages sent through a variety of paths (a few messages sent through separate emails, IMing, phone calls, etc.) so that the only way to reconstruct the login information (or the decryption key) is to get all of the messages. But there are better methods.

In practice, the best solution we have so far to the key exchange problem is asymmetric cryptography, also called public-key cryptography. The RSA algorithm (the "rsa" in the "id_rsa.pub" mentioned above) and Diffie–Hellman key exchange (D-H) are currently the two most popular and widely-used asymmetric cryptography techniques. The clever part about D-H is that it doesn't actually send the secret key from Alice to Bob or from Bob to Alice -- instead, the algorithm generates a fresh new secret key from the (publicly transmitted) random bits Alice and Bob send each other, in such a way that Alice and Bob both end up with a copy of the key, but no one else listening to their conversation can get a copy of that key.

in practice

A friend of mine needed help with her website and asked how to send me her login information securely. I've never known how to do this

The current best-practices way to let you access someone else's website is using SSH, the Secure Shell.

Send your public key to that person (in the open, with unencrypted email or etc.). Then have that person confirm it really is your public key (there are a variety of ways of checking). Then have that person log in to the website (perhaps using ssh) and append your public key (typically in a file named "id_rsa.pub") to the end of the "~/.ssh/authorized_keys" file in that account on the website.

That authorizes you to log in to that account using ssh in the normal way, using only your own private key and without knowing your friend's password or private key, and without your friend or anyone else knowing your private key.

http://en.wikibooks.org/wiki/Internet_Technologies/SSH has some step-by-step tips on how to create a private key (if you don't already have one), derive the corresponding public key from it, copy it to a remote server, log in with ssh, etc. (The Information Security site is another place to ask for information about using ssh).

in theory

Your friend can encrypt the login information and send you the encrypted package. But how are you going to decrypt that package? You need the decryption key for that, right?

If you ever discover a way to securely send that decryption key -- why don't you send the login information directly the same way?

You have discovered the one problem with the one-time pad and with symmetric cryptography in general: the key exchange problem.

If you're just doing this for fun, you might consider using "t=n: trivial secret sharing", using XOR to create a set of messages sent through a variety of paths (a few messages sent through separate emails, IMing, phone calls, etc.) so that the only way to reconstruct the login information (or the decryption key) is to get all of the messages. But there are better methods.

In practice, the best solution we have so far to the key exchange problem is asymmetric cryptography, also called public-key cryptography. The RSA algorithm (the "rsa" in the "id_rsa.pub" mentioned above) and Diffie–Hellman key exchange (D-H) are currently the two most popular and widely-used asymmetric cryptography techniques. The clever part about D-H is that it doesn't actually send the secret key from Alice to Bob or from Bob to Alice -- instead, the algorithm generates a fresh new secret key from the (publicly transmitted) random bits Alice and Bob send each other, in such a way that Alice and Bob both end up with a copy of the key, but no one else listening to their conversation can get a copy of that key.

Source Link
David Cary
David Cary
  • 5.7k
  • 4
  • 22
  • 35

in practice

A friend of mine needed help with her website and asked how to send me her login information securely. I've never known how to do this

The current best-practices way to let you access someone else's website is using SSH, the Secure Shell.

Send your public key to that person (in the open, with unencrypted email or etc.). Then have that person confirm it really is your public key (there are a variety of ways of checking). Then have that person log in to the website (perhaps using ssh) and append your public key (typically in a file named "id_rsa.pub") to the end of the "~/.ssh/authorized_keys" file in that account on the website.

That authorizes you to log in to that account using ssh in the normal way, using only your own private key and without knowing your friend's password or private key, and without your friend or anyone else knowing your private key.

http://en.wikibooks.org/wiki/Internet_Technologies/SSH has some step-by-step tips on how to create a private key (if you don't already have one), derive the corresponding public key from it, copy it to a remote server, log in with ssh, etc. (The Information Security site is another place to ask for information about using ssh).

in theory

Your friend can encrypt the login information and send you the encrypted package. But how are you going to decrypt that package? You need the decryption key for that, right?

If you ever discover a way to securely send that decryption key -- why don't you send the login information directly the same way?

You have discovered the one problem with the one-time pad and with symmetric cryptography in general: the key exchange problem.

If you're just doing this for fun, you might consider using "t=n: trivial secret sharing", using XOR to create a set of messages sent through a variety of paths (a few messages sent through separate emails, IMing, phone calls, etc.) so that the only way to reconstruct the login information (or the decryption key) is to get all of the messages. But there are better methods.

In practice, the best solution we have so far to the key exchange problem is asymmetric cryptography, also called public-key cryptography. The RSA algorithm (the "rsa" in the "id_rsa.pub" mentioned above) and Diffie–Hellman key exchange (D-H) are currently the two most popular and widely-used asymmetric cryptography techniques. The clever part about D-H is that it doesn't actually send the secret key from Alice to Bob or from Bob to Alice -- instead, the algorithm generates a fresh new secret key from the (publicly transmitted) random bits Alice and Bob send each other, in such a way that Alice and Bob both end up with a copy of the key, but no one else listening to their conversation can get a copy of that key.