Diffie-Hellman is a way of generating a shared secret between two people in such a way that the secret can't be seen by observing the communication. That's an important distinction: You're not sharing information during the key exchange, you're creating a key together.
This is particularly useful because you can use this technique to create an encryption ...
The other answers do an excellent job explaining the maths behind the key exchange. If you'd like a more pictorial representation, nothing beats the excellent paint analogy shown on the Diffie–Hellman key exchange Wikipedia entry:
Image is in the public domain
Public Keys are designed for sharing, read access to and or publishing a public key is fine
Private Keys are secret, they should only be accessible to the owner of said private key.
To drive this point home, think back to every HTTPS website you have ever visited. In each case, as part of HTTPS the site gives you their public key. So not only is it safe ...
None, that's why it is called a public key. It can not be used to access anything encrypted for you without solving math problems that are currently prohibitively difficult to solve. It is possible that in the future it may be possible to solve these problems and that would cause the public key to allow messages to be decoded, but there is no current known ...
Is it completely safe to publish an ssh public key?
No, but you can do it anyway without worries (lots of people do, just look at https://sks-keyservers.net/i/ or https://pgp.mit.edu/)
The reason why it's not completely safe is because if I know your public key, I can, with a neat piece of mathematics, calculate your private key. Your public key contains a ...
If the attacker is able to passively capture data and later gets access to the private key of the certificates (i.e. stealing, heartbleed attack or law enforcement), then the attacker could decode all previously captured data if the encryption key is only derived from the certificate itself.
DH key exchange makes it possible to create a key independent from ...
Nothing is "completely safe"; the question is whether it adds any additional risks.
The SSH protocol sends the client's public key encrypted, only after it has negotiated a symmetric session encryption key with the server. So an adversary that eavesdrops on the connection doesn't learn the client's public key. This means that publishing it does give the ...
If you want a simpler plain English explanation of DH that can be readily understood by even non-technical people, there is the double locked box analogy.
Alice puts a secret in a box and locks it with a padlock that she has the only key to open. She then ships the box to Bob.
Bob receives the box, puts a second padlock that only he has the key to on it, ...
This preference of symmetric cryptography over asymmetric cryptography is based on the idea that asymmetric cryptography uses parametrized mathematical objects and there is a suspicion that such parameters could be specially chosen to make the system weak. For instance, when using Diffie-Hellman, DSA or ElGamal, you have to work modulo a big prime p. A ...
The key exchange problem
A secure connection requires the exchange of keys.
But the keys themselves would need to be transfered on a secure connection.
There are two possible solution:
exchange the key by physically meeting and sharing the keys.
Somehow established a shared secret on a public unsecure channel. This is easier said than done, and the first ...
No, unless you use a unique one per service. It lets attackers identify you.
If you use the same public key for service A and service B, and your public key gets leaked for both of them, this will cross-link your two accounts together.
Hopefully neither of the two services is embarrassing. But even in that case, this will give the attacker a better lead for ...
Just to expand on a couple bits of info alluded to above, there are basically two risks to consider, neither of them relating to the algorithms (those are safe).
First, is incidental data leakage. Do you run slaterockandgravel.com as Mr. Slate but have your key signed firstname.lastname@example.org? Did Betty sign your key and you don't want the world ...
There are many steps needed to understand the reasons and I will try to guide you through each.
1) Use encryption correctly...
With RSA algorithm, Alice and Bob can just share their public keys
(public_a, public_b) and keep their private keys (private_a,
private_b). Alice can just send Bob the messages which are encrypted
by private_a, and Bob can ...
RSA is still recommended as a gold standard (strong, wide compatible)
ed25519 is good (independent of NIST, but not compatible with all old clients).
Server is usually providing more different host key types, so you are targeting for compatibility. The order of priority in the client config is from the stronger to more compatible ones.
Since the algorithms are in a state of flux, I find that using an ssh-audit tool (available on Github) (here's a more recent fork) to be extremely useful.
Example output of a current but secured SSH settings is given below:
(gen) banner: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
(gen) software: OpenSSH 6.7p1
(gen) compatibility: OpenSSH 6.5+, ...
In public key cryptography, the key is usually a key pair, consisting of a public key and a private key, and it is what you do encryption, decryption, signing, and verification with.
"A key certificate is an assertion that a certain key belongs to a certain entity" PGP lecture.
To illustrate what each key does, and to see an example of why one would both ...
Asymmetric encryption provides security for messages exchanged between Alice and Bob only insofar as Alice knows Bob's public key and Bob knows Alice's public key. Otherwise, attackers could publish fake public keys and, in effect, pose as Alice when talking to Bob and vice versa.
An historical view of the issue is the following: in older times (say, 50 ...
This depends on the algorithm. Especially with asymmetric cryptography, the speeds vary wildly. You may want to check out eBACS for more detailed and machine-independent benchmarking of various crypto primitives. As always, you need to perform your own benchmark on your own system to know exactly what to expect on a production system under the chosen ...
I cannot reconcile in my head how or why the roles of the keys suddenly reverses.
(I'm primarily focusing on RSA signatures.)
Anyone can produce an encrypted message (by using your public key) and only you can decrypt it (by using your private key). The roles of public and private key reverse because a signature has to be something that only you can ...
There is a slight risk of revealing your identity if your public key contains your hostname as a comment at the end, e.g. ssh-rsa C4F3B4B3... email@example.com. If your name is fairly uncommon it may be possible to identify you.
See this question & answer for more detail: Should I publish my public SSH key with user@hostname at the end?
CHOOSING AN ALGORITHM AND KEY SIZE
SSH supports several public key algorithms for authentication keys.
rsa - an old algorithm based on the difficulty of factoring large
numbers. A key size of at least 2048 bits is recommended for RSA; 4096
bits is better. RSA is getting old and significant advances are being
made in ...
Do not use the OpenSSL command line to encrypt or sign anything. The OpenSSL command line is a debugging tool. To encrypt or sign a message, use a tool designed for this purpose, such as GPG.
A private key file contains all the information needed to construct the public key. If you have a private key in a format that OpenSSL understands and you want to get ...
However, the server must store some form of the mailbox password so that the user can be authenticated. Should a security breach occur on the server, wouldn't it be just a matter of time for a determined hacker (and a powerful hacker, if, say, a government decides to be one) to figure out the real mailbox password?
Security is about trade-offs. It is ...
You seem to ask for a comparative study on the PRNG (pseudo-random number generators) used by default by OpenSSL and the Linux kernel. This could most probably fill a volume full of mathematical formulas, and to make it worse OpenSSL and the Linux PRNG are not independent since OpenSSL will use /dev/urandom as a default seed, and there are ongoing work to ...
The private key is used to decrypt, and to sign things. You don't use it to encrypt. You use the public key for that. But openssl genrsa will not generate the public key, only the private. To encrypt things, you must first generate the public key (so you have a keypair: private and public):
openssl rsa -in yourdomain.key -outform PEM -pubout -out public.pem
Securing data as it passes through the internet usually requires protecting it in two ways:
Confidentiality -- assuring no one except the intended recipients can read the data
Integrity -- assuring no one can modify or tamper the data in transit
Confidentiality is provided using Symmetric Encryption and Integrity is provided using a Message Authentication ...
The host has a key pair, consisting of a public key and a private key. (It can have multiple key pairs in different formats; at the beginning of a connection, the client and the server negociate to determine a format that they both support.) There's a host public key and a host private key; there are also other key pairs (public and private keys) which are ...
Just open it, if it's encrypted it will begin with
-----BEGIN RSA PRIVATE KEY-----
if it is not it will begin directly by the (base64 encoded) key :
-----BEGIN RSA PRIVATE KEY-----
The short answer is to use RS256, to be understood as SHA 256 with RSA 2048 bits keys.
See RFC 7518 JSON Web Algorithms (JWA) for all supported algorithms.
On signing algorithms
There are two major signing algorithms supported by JWT: RSA and ECDSA.
RSA (as in alg:RS256) is the classic asymmetric signing algorithm based on prime factorization. It's very ...