Encryption and cryptography
You want to be comfortable with a few concepts: (1) The difference between Asymmetric cryptography and Symmetric cryptography; (2) SSH private/public keys, and (3) ways they can be implemented.
Symmetric encryption uses a single key/password that needs to be shared among the people who need to receive the message while asymmetrical encryption uses a pair of public key and a private key to encrypt and decrypt messages when communicating. For example, remember when I gave you the password for our server? Is that the best way? For me to make a password up and then send it to you via email? What if it gets intercepted. When you change the password, how do you know someone doesn’t use that malicious or share it with the world? That’s happened more than you guess. Did you know most email/password combos that have been used for more than 3 years have been hacked because of these types of issues?
Assymetric build on the work of Diffie and Hellman in 1976 “New Directions in Cryptography”, but really didn’t get legway till about 1997. The core idea is a public key and a private key. The public key can be used to encrypt a message “M” that can be decrypted using a second private key. These are fundamentally linked keys, whose math is based on prime number theory. Essentially its a math equation where reciprical key pairs exist allowing one to encrypt a message with one key, and decrypt it with another key. All this while ensuring that one cannot figure out the key by going backwards. The core idea in the two key system is to keep one key private and one key public. A central premise is that even if you know the public key, the original message and the “cipher” or coded message, you cannot determine the other private key. Super simple example:
- User 1: M+PublicKeyPair88 => Crypt
- Crypt+PrivateKeyPair88 => Message
Showing a little math where this can occur for real.
Hypothetical Public key from pair:
Hypothetical Private key from pair:
Your message (M)
Public Math 1-way formula. An encryption formula using public key info. C is cyphr of encrypted of M message.
C=M^(e) % n
Private Math 1-way formula. A formula using private key info. Message can be determined from the C, cypher, and the private key.
M=C^(d) % n
Test this out in Python. We can also use our private key to encrypt something, such that anyone with the public key can decrypt it. This is a great way to sign things. Someone could provide you a message only they know & make it a cypher using your public key. Only they know what they wrote. However, with the private key you can decode it. Now, you can return the message such that it can be decrypted with the public key.
You want to not use passwords when logging into the TRGN server. How do you do this? You create a private/public key:
This will create a public and a private key in the
.ssh directory. Note that the permissions must be 700/600 Never share your private key. You can see the key in the hidden .ssh directory by ‘ls -l .ssh’. You then login to the server and create a directory
.ssh, with a file called
authorized_keys. In this file, paste your public key.
When a your computer now connects to the trgn.usc.edu server, wishing to use SSH key authentication, your ssh will tell the server of this intent and will tell the server which public key to use. The server then check its
authorized_keys file for the public key, generate a random string and encrypts it using the public key. This encrypted message can only be decrypted with the associated private key. The server will send this encrypted message to the client to test whether they actually have the associated private key.
Upon receipt of this message, the client will decrypt it using the private key and combine the random string that is revealed with a previously negotiated session ID. It then generates an MD5 hash of this value and transmits it back to the server. The server already had the original message and the session ID, so it can compare an MD5 hash generated by those values and determine that the client must have the private key.
Asymmetric vs. symmetric cryptography
How many passwords do you have? Probably too many. Well, let’s talk about how we get rid of those and a core concept that matters a lot – public/private keys. This gets confusing – remember one thing. You get two keys – a private key and a public key. Don’t share the public.
Now its worth trying to understand it. There are many videos and many explanations, feel free to explore them.
Secure web browsing.
HTTP is not encrypted and thus is vulnerable to easedropping (such as via sharkware) which can let attackers gain access to website accounts and sensitive information, and modify webpages to inject advertisements. HTTPS encrypts information using these concepts above by establishing public certificate (or keys) that is shared with all, linked to a private key they keep on their server. There is typically a third-party supplying the certificates. When you go to the page, you encrypt information using this public key and the server can decrypt it using the private key.
Example from a company, Docusign:
Setting up public-private keys is a major and important part of security. There is a lot of information on public keys, but the way to think of it is like having a safety deposit box. It takes two keys to get in. If you are on a site, and you would like to access another site without typing that password in again, you can share a public key from the site you are in. This public key is in the background used to verify against the paired private key. It gets confusing, but essentially, sites that you feel are safe you can give them your public key – and because you know the private key you can get be authenticated.
Here’s the basic idea. In symmetric authentication, its essentially a key or a password.