Public Key Cryptography Basics

Introduction

Consider the following scenario from everyday life. Let’s say you are meeting a business partner over coffee and discussing somewhat confidential business plans. Let’s break down the meeting from the security perspective.

• You can see and hear the other person. Consequently, it is easy to be sure of their identity. That’s authentication, i.e., you are confirming the identity of who you are talking with.
• You can also confirm that what you are “hearing” is coming from your business partner. You can tell what words and sentences are coming from your business partner and what is coming from others. That’s authenticity, i.e., you verify that the message genuinely comes from a specific sender. Moreover, you know that what they are saying is reaching you, and there is no chance of anything changing the other party’s words across the table. That’s integrity, i.e., ensuring that the data has not been altered or tampered with.
• Finally, you can pick a seat away from the other customers and keep your voice low so that only your business partner can hear you. That’s confidentiality, i.e., only the authorised parties can access the data.

Let’s quickly compare this with correspondence in the cyber realm. When someone sends you a text message, how can you be sure they are who they claim to be? How can you be sure that nothing changed the text as it travelled across various network links? When you are communicating with your business partner over an online messaging platform, you need to be sure of the following:

• Authentication: You want to be sure you communicate with the right person, not someone else pretending.
• Authenticity: You can verify that the information comes from the claimed source.
• Integrity: You must ensure that no one changes the data you exchange.
• Confidentiality: You want to prevent an unauthorised party from eavesdropping on your conversations.

Cryptography can provide solutions to satisfy the above requirements, among many others. Private key cryptography, i.e., symmetric encryption, mainly protects confidentiality. However, public key cryptography, i.e., asymmetric cryptography, plays a significant role in authentication, authenticity, and integrity. This room will show various examples of how public key cryptography achieves that.

---

Learning Prerequisites

This room is the second of three introductory rooms about cryptography. Before starting this room, ensure you have finished the first one on the list.

• Cryptography Basics: https://tryhackme.com/r/room/cryptographybasics

• Public Key Cryptography Basics (this room)

• Hashing Basics

---

Learning Objectives

In this room, we will cover various asymmetric cryptosystems and applications that use them, such as:

• RSA
• Diffie-Hellman
• SSH
• SSL/TLS Certificates
• PGP and GPG

---

Common Use of Asymmetric Encryption

Note on Exchanging Symmetric Keys Using Asymmetric Cryptography

When two parties want to communicate securely, they often use symmetric encryption because it is much faster than asymmetric encryption. However, they first need a secure way to agree on the symmetric key. That’s where asymmetric cryptography (public key and private key) comes in.

The Box-and-Lock Analogy

1. Lock (Public Key)
   • The server sends you its “lock,” which anyone can use to secure a box but only the server can unlock.
2. Box (Message Container)
   • You place the secret instructions (the symmetric cipher details and the key) into a box.
3. Sending the Box
   • You lock the box using the server’s public key (the “lock”) and send it.
   • Even if someone intercepts this locked box, they cannot open it because they don’t have the server’s private key.
4. Unlocking the Box
   • When the server receives the locked box, it uses its private key to open it.
   • Now, the server knows the symmetric key and encryption method.
5. Secure Communication
   • From this point on, both of you communicate using symmetric encryption, which is faster and more efficient.

Key Points

• Asymmetric Encryption (Public/Private Key) Used primarily for securing the initial exchange of the symmetric key. It is slower but ensures that only the intended recipient can access the secret key.
• Symmetric Encryption (Shared Key) Once the symmetric key is exchanged securely, it is used for bulk data encryption because it is much faster and more efficient.
• Real-World Considerations In practice, additional steps like digital signatures and certificates verify identities and prevent man-in-the-middle attacks.

This approach ensures that only one initial exchange relies on the slower asymmetric method. Afterward, a fast symmetric cipher protects the rest of the communication.

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: Requests Public Key
    Server-->>Client: Sends Public Key (Lock)
    note right of Client: Client now has the <br>Server's Public Key
    
    Client->>Client: Generate Symmetric Key and Cipher Details
    Client->>Server: Encrypt Symmetric Info with <br>Public Key (Lock) and Send
    note right of Server: Data is unreadable <br>to anyone without <br>the Private Key

    Server->>Server: Decrypt with Private Key <br>(Open the locked box)
    note over Client,Server: Both parties now share the same <br>Symmetric Key and Cipher

    Client->>Server: Secure communication using <br>Symmetric Encryption
    Server->>Client: Secure communication using <br>Symmetric Encryption

---

RSA

RSA is a public-key encryption algorithm that enables secure data transmission over insecure channels. With an insecure channel, we expect adversaries to eavesdrop on it.

The Math That Makes RSA Secure

RSA is based on the mathematically difficult problem of factoring a large number. Multiplying two large prime numbers is a straightforward operation; however, finding the factors of a huge number takes much more computing power.

It’s simple to multiply two prime numbers together even on paper, say 113 × 127 = 14351. Even for larger prime numbers, it would still be a feasible job, even by hand. Consider the following numeric example:

• Prime number 1: 982451653031
• Prime number 2: 169743212279
• Their product: 982451653031 × 169743212279 = 166764499494295486767649

On the other hand, it’s pretty tricky to determine what two prime numbers multiply together to make 14351 and even more challenging to find the factors of 166764499494295486767649.

In real-world examples, the prime numbers would be much bigger than the ones in this example. A computer can easily factorise 166764499494295486767649; however, it cannot factorise a number with more than 600 digits. And you would agree that the multiplication of the two huge prime numbers, each around 300 digits, would be easier than the factorisation of their product.

Numerical Example

Let’s revisit encryption, decryption, and key usage in asymmetric encryption. The public key is known to all correspondents and is used for encryption, while the private key is protected and used for decryption, as shown in the figure below.

In the Cryptography Basics room, we explained the modulo operation and said it plays a significant role in cryptography. In the following simplified numerical example, we see the RSA algorithm in action:

1. Bob chooses two prime numbers: p = 157 and q = 199. He calculates n = p × q = 31243.
2. With ϕ(n) = n − p − q + 1 = 31243 − 157 − 199 + 1 = 30888, Bob selects e = 163 such that e is relatively prime to ϕ(n); moreover, he selects d = 379, where e × d = 1 mod ϕ(n), i.e., e × d = 163 × 379 = 61777 and 61777 mod 30888 = 1. The public key is (n,e), i.e., (31243,163) and the private key is $(n,d), i.e., (31243,379).
3. Let’s say that the value they want to encrypt is x = 13, then Alice would calculate and send y = x__e mod n = 13163 mod 31243 = 16341.
4. Bob will decrypt the received value by calculating x = y__d mod n = 16341379 mod 31243 = 13. This way, Bob recovers the value that Alice sent.

The proof that the above algorithm works can be found in modular arithmetic and is beyond the scope of this module. It is worth repeating that in this example, we picked a three-digit prime number, while in an actual application, p and q would be at least a 300-digit prime number each.

RSA in CTFs

The math behind RSA comes up relatively often in CTFs, requiring you to calculate variables or break some encryption based on them. Many good articles online explain RSA, and they will give you almost all of the information you need to complete the challenges. One good example of an RSA CTF challenge is the Breaking RSA room.

There are some excellent tools for defeating RSA challenges in CTFs. My favourite is RsaCtfTool, which has worked well for me. I’ve also had some success with rsatool.

You need to know the main variables for RSA in CTFs: p, q, m, n, e, d, and c. As per our numerical example:

• p and q are large prime numbers
• n is the product of p and q
• The public key is n and e
• The private key is n and d
• m is used to represent the original message, i.e., plaintext
• c represents the encrypted text, i.e., ciphertext

Crypto CTF challenges often present you with a set of these values, and you need to break the encryption and decrypt a message to retrieve the flag.

Questions

1. Knowing that p = 4391 and q = 6659. What is n?
   • 29239669
2. Knowing that p = 4391 and q = 6659. What is ϕ(n)?
   • 29228620

---

Diffie-Hellman Key Exchange

Note on Diffie-Hellman Key Exchange

One of the significant challenges of symmetric encryption is securely sharing the secret key. For example, when sending a password-protected document to a business partner, it is essential to use a secure channel to share the password, ensuring that adversaries cannot read or alter it.

Diffie-Hellman Key Exchange

The Diffie-Hellman Key Exchange is a method that allows two parties to establish a shared secret over an insecure communication channel without requiring a pre-existing shared secret. An observer cannot derive the shared key, and the established key can be used for symmetric encryption in subsequent communications.

Process Overview:

1. Agreement on Public Variables:

   • Two parties (e.g., Alice and Bob) agree on a large prime number p and a generator g, where 0 < g < p. These values are publicly shared.

2. Private Key Selection:

   • Each party chooses a private integer: Alice chooses a, and Bob chooses b. These are kept secret.

3. Public Key Calculation:

   • Using the private keys and the public variables:
     • Alice calculates her public key: A = g^a mod p.
     • Bob calculates his public key: B = g^b mod p.

4. Key Exchange:

   • Alice and Bob exchange their public keys A and B.

5. Shared Secret Calculation:

   • Both parties calculate the shared secret using their private key and the other party’s public key:
     • Alice calculates: Shared Secret = B^a mod p.
     • Bob calculates: Shared Secret = A^b mod p.
   • Both calculations result in the same shared secret: g^(a*b) mod p.

Example Calculation:

1. Public variables:

   • p = 29, g = 3

2. Private keys:

   • Alice chooses a = 13
   • Bob chooses b = 15

3. Public keys:

   • Alice calculates A = 3^13 mod 29 = 19
   • Bob calculates B = 3^15 mod 29 = 26

4. Key exchange:

   • Alice sends A = 19 to Bob.
   • Bob sends B = 26 to Alice.

5. Shared secret:

   • Alice calculates: B^a mod p = 26^13 mod 29 = 10
   • Bob calculates: A^b mod p = 19^15 mod 29 = 10
   • Shared secret: 10

Security Note:

The chosen numbers in this example are too small for real-world applications. In practice, much larger numbers are used to ensure security.

Integration with RSA:

Diffie-Hellman is often used alongside RSA:

• Diffie-Hellman: Key agreement.
• RSA: Digital signatures, key transport, and authentication.

For example, RSA can verify the identity of a communication partner via digital signatures, preventing man-in-the-middle attacks.

---

Questions

1. Consider p = 29, g = 5, a = 12. What is A? Given:

• p = 29
• g = 5
• a = 12

We need to calculate A = g^a mod p = 5¹² mod 29

Let’s break down the calculation:

5<sup>1</sup> = 5
5<sup>2</sup> = 25
5<sup>3</sup> = 125 ≡ 125 - 4 * 29 ≡ 125 - 116 ≡ 9 (mod 29)
5<sup>4</sup> = 5 * 9 = 45 ≡ 45 - 29 = 16 (mod 29)
5<sup>6</sup> = 16 * 25 = 400 ≡ 400 - 13 * 29 ≡ 400 - 377 ≡ 23 (mod 29)
5<sup>12</sup> = 23 * 23 = 529 ≡ 529 - 18 * 29 ≡ 529 - 522 ≡ 7 (mod 29)

Therefore, A = 7

So the answer is $\boxed{7}$

---

2. Consider p = 29, g = 5, b = 17. What is B? Given:

• p = 29
• g = 5
• b = 17

We need to calculate B = g^b mod p = 5¹⁷ mod 29

We can use modular exponentiation to calculate this efficiently. Let’s break it down:

5¹ = 5
5² = 25
5³ = 125 ≡ 9 (mod 29)
5⁴ ≡ 9 * 5 = 45 ≡ 16 (mod 29)
5⁸ ≡ 16 * 16 = 256 ≡ 256 - 8 * 29 = 256 - 232 = 24 (mod 29)
5¹⁶ ≡ 24 * 24 = 576 ≡ 576 - 19 * 29 = 576 - 551 = 25 (mod 29)

Now we can calculate 5¹⁷:

5¹⁷ = 5¹⁶ * 5¹ ≡ 25 * 5 = 125 ≡ 9 (mod 29)

Therefore, B = 9

So the answer is $\boxed{9}$

---

3. Knowing that p = 29, a = 12, and you have B from the second question, what is the key calculated by Bob? (key = B__a mod p) In the previous question, we calculated B = 9 when p = 29, g = 5, and b = 17. Now we’re given:

• p = 29
• a = 12
• B = 9

We need to calculate the shared key using Bob’s calculation: Key = B^a mod p = 9¹² mod 29

Let’s calculate this efficiently using modular exponentiation:

9¹ = 9
9² = 81 ≡ 81 - 2*29 = 81 - 58 = 23 (mod 29)
9⁴ ≡ 23 * 23 = 529 ≡ 529 - 18*29 = 529 - 522 = 7 (mod 29)
9⁸ ≡ 7 * 7 = 49 ≡ 20 (mod 29)

9¹² = 9⁸ * 9⁴ ≡ 20 * 7 = 140 ≡ 140 - 4*29 = 140 - 116 = 24 (mod 29)

Therefore, the shared key calculated by Bob is 24.

The answer is $\boxed{24}$

---

4. Knowing that p = 29, b = 17, and you have A from the first question, what is the key calculated by Alice? (key = A__b mod p) In the first question, we calculated A = 7 when p = 29, g = 5, and a = 12. Now we have:

• p = 29
• b = 17
• A = 7

Alice calculates the shared key as Key = A^b mod p = 7¹⁷ mod 29

Let’s compute this using modular exponentiation:

7¹ = 7
7² = 49 ≡ 20 (mod 29)
7⁴ ≡ 20 * 20 = 400 ≡ 400 - 13*29 = 400 - 377 = 23 (mod 29)
7⁸ ≡ 23 * 23 = 529 ≡ 529 - 18*29 = 529 - 522 = 7 (mod 29)
7¹⁶ ≡ 7 * 7 = 49 ≡ 20 (mod 29)

7¹⁷ = 7¹⁶ * 7¹ ≡ 20 * 7 = 140 ≡ 140 - 4*29 = 140 - 116 = 24 (mod 29)

Therefore, the shared key calculated by Alice is 24.

The answer is $\boxed{24}$

---

SSH

Authenticating the Server

If you have used an SSH client before, you would know the confirmation prompt in the terminal output below.

root@TryHackMe# ssh 10.10.244.173 The authenticity of host '10.10.244.173 (10.10.244.173)' can't be established. ED25519 key fingerprint is SHA256:lLzhZc7YzRBDchm02qTX0qsLqeeiTCJg5ipOT0E/YM8. This key is not known by any other name. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.10.244.173' (ED25519) to the list of known hosts.

Explanation of the SSH Client Interaction

1. SSH Command:

• The user initiates an SSH connection: ssh 10.10.244.173.
• SSH allows remote login to a server securely over a network.

2. Authenticity Check:

• The client receives the server’s public key (ED25519 in this case).
• Since this is the first time connecting to the server, the client doesn’t have this key in its known_hosts file.

3. Warning:

• The client warns you because it cannot verify the server’s identity. This protects against a potential Man-in-the-Middle (MITM) attack, where an attacker pretends to be the server to intercept your data.

4. User Decision:

• If you trust the server and its public key, you can type yes. This saves the server’s public key in your ~/.ssh/known_hosts file for future connections.

5. Future Connections:

• The next time you connect to the same server, the client will verify the server’s public key with the saved key in known_hosts. If the key matches, the connection proceeds silently. If it doesn’t match, the client will warn you again.

How is a Man-in-the-Middle Attack Possible?

1. Interception:

• The attacker positions themselves between the client (you) and the server (target). This can be done by:
• Compromising the network (e.g., Wi-Fi or router).
• Using techniques like ARP spoofing to redirect traffic.

2. Impersonation:

• When the client sends an SSH connection request, the attacker intercepts it.
• The attacker pretends to be the target server and sends their own public key instead of the server’s key.

3. Data Interception:

• Once the client accepts the attacker’s key, the attacker can decrypt and read data sent by the client, modify it, or relay it to the actual server (proxying).

4. No Trust Verification:

• If the user blindly types yes without verifying the server’s key fingerprint, they unknowingly establish a connection with the attacker.

Diagram for MITM Attack

Here’s a Mermaid graph illustrating a simple MITM attack:

graph TD

    A[Client] -->|SSH Connection Request| B[Attacker MITM]

    B -->|Fake Server Key| A

    B -->|SSH Connection Request| C[Server]

    C -->|Server Key| B

    A -->|Data Sent| B

    B -->|Relayed Data| C

    C -->|Response| B

    B -->|Fake Response| A

Explanation of the Graph

1. The client initiates an SSH connection.

2. The attacker intercepts the request and replies with their own public key.

3. The attacker establishes a connection with the real server in the background.

4. The client and server communicate through the attacker, allowing the attacker to see and manipulate the data.

This is why verifying the server’s fingerprint is critical during the SSH process.

---

SSH Private Keys

As just mentioned, you should treat your private SSH keys like passwords. Never share them under any circumstances; they’re called private keys for a reason. Someone with your private key can log in to servers that accept it, i.e., include it among the authorised keys, unless the key is encrypted with a passphrase.

It’s very important to mention that the passphrase used to decrypt the private key doesn’t identify you to the server at all; it only decrypts the SSH private key. The passphrase is never transmitted and never leaves your system.

Using tools like John the Ripper, you can attack an encrypted SSH key to attempt to find the passphrase, highlighting the importance of using a complex passphrase and keeping your private key private.

When generating an SSH key to log in to a remote machine, you should generate the keys on your machine and then copy the public key over, as this means the private key never exists on the target machine using ssh-copy-id. However, this doesn’t matter as much for temporary keys generated to access CTF boxes.

The permissions must be set up correctly to use a private SSH key; otherwise, your SSH client will ignore the file with a warning. Only the owner should be able to read or write to the private key (600 or stricter). ssh -i privateKeyFileName user@host is how you specify a key for the standard Linux OpenSSH client.

Keys Trusted by the Remote Host

The ~/.ssh folder is the default place to store these keys for OpenSSH. The authorized_keys (note the US English spelling) file in this directory holds public keys that are allowed access to the server if key authentication is enabled. By default on many Linux distributions, key authentication is enabled as it is more secure than using a password to authenticate. Only key authentication should be accepted if you want to allow SSH access for the root user.

Using SSH Keys to Get a “Better Shell”

During CTFs, penetration testing, and red teaming exercises, SSH keys are an excellent way to “upgrade” a reverse shell, assuming the user has login enabled. Note that www-data usually does not allow this, but regular users and root will work. Leaving an SSH key in the authorized_keys file on a machine can be a useful backdoor, and you don’t need to deal with any of the issues of unstabilised reverse shells like Control-C or lack of tab completion.

---

authorized_keys File

• Purpose: This file is used by the SSH SERVER (sshd) to determine which public keys are authorized to log into a specific user account on the target machine.

• Location: It resides in the ~/.ssh/ directory of the user being logged into (e.g., /home/username/.ssh/authorized_keys).

• Function: When an SSH client attempts to log in using a private key, the server checks whether the corresponding public key is listed in the authorized_keys file for the target user. If the key matches, the login is allowed without requiring a password.

• Attack Use Case: By adding a public key to this file, an attacker grants themselves passwordless SSH access to the target system.

---

Question

1. Check the SSH Private Key in ~/Public-Crypto-Basics/Task-5. What algorithm does the key use?

user@ip-10-10-133-8:~$ cd Public-Crypto-Basics/Task-5
user@ip-10-10-133-8:~/Public-Crypto-Basics/Task-5$ ls
id_rsa_1593558668558.id_rsa
user@ip-10-10-133-8:~/Public-Crypto-Basics/Task-5$ cat id_rsa_1593558668558.id_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,0B5AB4FEB69AFB92B2100435B42B7949
 
jc40IChbGadGmmQieKevqwq0DijIZc6T/vE1G65Umd9fvwTd9RDl5AckbkIhh2s/
u5OTGlJ2KBGCubrzjgw4pWVI8w53gcd+K/WUCtn3cmUQKrMou0xvf9BumjFTGR38
3c2WciVmCKW/8ET78zkBhJqiw0ZOJLsx1tZRYN9hhIlSp5zmYKl7MSP6U5dUoOX/
v7p5bJjBe0ykXu7uHhx6RUEuJv75uo7UihXCtg4jpaUl7iRR4DyFFF0DtxKXQLfs
O6vaLwEvGtIeqMnMrn6Or5Xlj+cxWdsxeF+DjenZYNPSpSir3a0DN0kMqnNWUEL/
jF3GctLlhALjRJzwUAsORnMAIgzuNbUo5xjrJf3H0mUELT27457VKkRb3XitSpRi
s3T2zofBvSjxFUtSxZ22AoGHwiyvpbAuq+J/mkFzOjW2z8c9g8Zf66/o51aNFbWl
ozQEcnlKK22lz/WTZJs1KZ7efooilM5YErtbyTlsxK5VJWIPToNELH4YExcILl/Z
Oyl3PdcgPiKUe5YLL+29CJ/7iHk1M9zxlSgSB+Ba2i0oTcabR159VhpH1DRw1JDs
nYR9gg6523lD3PEzNQtui2UT7S3uympRBetJYXD9I2ezY35zdYkaSDURFo/h8ykr
zWTiUmgoZefaHx8GriYaYqAVXTqTLMGXb0XB/qrxg62Gx86ReV/kU5WnMmjTwOIo
4k0CXJl6k2/LJ7sFmS/0sj4FDtqq50ixSoDE/zFF91Q2EA/IQNEH65fj2juBFIee
NzBT+MRDH/xv7s0WfymnUVKtLgm4vK9Or5KucVVoTJF14y/iFBtnaBw3+kHnkb1x
hy1J6lK96m9UrmxB61Oa0u0Mfe31Je4gRgoZOnBQHZvBj0I0ek3WLZTpysUEq7Ar
eilO+34ZRgFN6QUdmIw+I//88A9PW+s7GR+dAVVwectF6ZIZnRN3AGDlPwk4nKoG
LPxnWroCxpPvLEMmoUQ67xmH5Mj6EOEebSmV+vH4qpke//ys6iiWfyTqusVGfnAt
Oi4HpMVvZ4AYcPfNs02dgBFtbOJrPPu6mwbQaVeRG2wT43uHlZOvDDyynS9aOIlm
h2sKJsrdlOedl4aPlGTfbNZ0M3SPPau+XprA622s39DMQhnLvzuw/of85bkHYRvN
HpGmSxzas/JrifcDl+Xd1Y6SHbetaYcaZwUXC1hXPqypltbLmHIQ5NHqLgmJeFJb
442LBxdnHWUavqBSF2igPBAoVwp4UUcngS19F5Rs72qsoN3dHliF8Pf+rP56P3CR
Gm9CL4VbrC/SMQURSJj+RLUymS2EGlHggRG+LKpmqzCqPonNmRd6UycelADHmUTC
QG1gWghIdci0cw8QjioszmJRu0/Cem86/QPCiXRfsXYwqLD1ILp3DKFFXGOtHbey
EnL8ml0l+t/fI6ewIfbYBp6cqGMd0OgbGCUh57nvxGMmQ6wSPBv44s6EV2rgz8JH
MNBRcFvWiVjTSiMrEXQrzgXS24MCm9YxkTOS/FZebYrM7fH5wrqQxIp3O8xif5mr
GkSJcoDC2UWg2KEnAgZRXdL6CPjDSkFQoLo1/w09vCwhzQDgn3dKB0HShTTuxk6j
-----END RSA PRIVATE KEY-----
 
user@ip-10-10-133-8:~/Public-Crypto-Basics/Task-

ANSWER : RSA

---

Digital Signatures and Certificates

flowchart TB
    A((Digital Signatures)) --> B(Ensure Authenticity<br>& Integrity)
    A --> C(Use Public &<br>Private Keys)
    C --> D(Sign with<br>Private Key)
    C --> E(Verify with<br>Public Key)
    
    A --> F((Certificates))
    F --> G(Used in HTTPS/TLS)
    F --> H(Chain of Trust)
    H --> I(Root CA Trusted<br>by OS/Browser)
    H --> J(Intermediate CA<br>Trusted by Root CA)
    H --> K(Site Certificate<br>Issued by CA)
    
    style A fill:#fffae6,stroke:#bbb,stroke-width:1px
    style F fill:#fffae6,stroke:#bbb,stroke-width:1px
    style B fill:#e1f0ff,stroke:#36f
    style C fill:#e1f0ff,stroke:#36f
    style D fill:#d9ffe2,stroke:#3a3
    style E fill:#d9ffe2,stroke:#3a3
    style G fill:#fff2dc,stroke:#fa3
    style H fill:#fff2dc,stroke:#fa3
    style I fill:#ffdce6,stroke:#f33
    style J fill:#ffdce6,stroke:#f33
    style K fill:#ffdce6,stroke:#f33

1. Digital Signatures:

   • Authenticity: Verifies who signed or created the document/message.
   • Integrity: Ensures the content was not altered after it was signed.
   • Asymmetric Cryptography:
   • Signing: Done with the private key (kept secret).
   • Verification: Done with the public key (shared openly).
   • Hashing: The document’s hash is encrypted with the signer’s private key, and recipients compare it with the hash of the received document.
   • Legal Standing: In many jurisdictions, digital signatures are considered as valid as physical signatures.

2. Certificates:

   • Purpose: A way to bind a public key to an entity (e.g., a website) and to establish a trust relationship.
   • Chain of Trust:
     • Root Certificate Authority (CA) is trusted by operating systems and browsers by default.
     • Intermediate CAs are trusted by the Root CA.
     • Certificates for specific organizations or websites are issued by these trusted CAs.

• HTTPS/TLS: When you visit a secure site, your browser checks the certificate and traces its chain back to a trusted root CA.

• Obtaining Certificates: You can pay certificate authorities or use a free service like Let’s Encrypt (provided you own the domain).

• Result: Ensures secure, encrypted communication and confirms that the site you’re connecting to is the genuine site it claims to be.1. Digital Signatures:

Questions

1. What does a remote web server use to prove itself to the client?
   • Certificate
2. What would you use to get a free TLS certificate for your website?
   • Let’s Encrypt

---

PG and GPG

GPG (GNU Privacy Guard) is a tool used to encrypt and decrypt messages or files, ensuring that only the person with the correct private key can read them. It also allows you to sign documents to prove they came from you. GPG uses public-key cryptography, meaning you have two keys:

1. Public Key: Shared with others to let them encrypt messages for you or verify your signature.

2. Private Key: Kept secret; used to decrypt messages and create digital signatures.

Importing Your Key ( gpg —import backup.key )

• When you run gpg —import backup.key, you are telling GPG to load or restore the private (and/or public) keys contained in the file backup.key into your GPG keyring (your local collection of keys).

• This is useful if you have switched computers or have a new installation of GPG and need to bring in your existing keys so you can decrypt files or sign documents again.

Decrypting a Message ( gpg —decrypt confidential_message.gpg )

• Once your private key is imported (so GPG knows which key belongs to you), you can decrypt an encrypted file by running gpg —decrypt confidential_message.gpg.

• GPG will find your private key in the keyring, use it to decrypt the message, and output the original content.

Example Flow

1. Back Up Your Keys

   • You might have previously saved your private key to a file named backup.key.

2. Import Your Key

   • gpg —import backup.key (loads your keys into GPG on this computer).

3. Decrypt a File

   • gpg —decrypt confidential_message.gpg (outputs the decrypted content).

4. Read the Decrypted Message

   • The confidential message is displayed on the screen or saved to a file (e.g., by adding > output.txt after the decrypt command).

This ensures that only someone with the matching private key can read an encrypted file, preserving confidentiality.

Practical Example

Now that you have your GPG key pair, you can share the public key with your contacts. Whenever your contacts want to communicate securely, they encrypt their messages to you using your public key. To decrypt the message, you will have to use your private key. Due to the importance of the GPG keys, it is vital that you keep a backup copy in a secure location.

Let’s say you got a new computer. All you need to do is import your key, and you can start decrypting your received messages again:

• You would use gpg --import backup.key to import your key from backup.key
• To decrypt your messages, you need to issue gpg --decrypt confidential_message.gpg

Questions

1. Use GPG to decrypt the message in ~/Public-Crypto-Basics/Task-7. What secret word does the message hold?
   • Pineapple

user@ip-10-10-133-8:~/Public-Crypto-Basics/Task-7$ gpg --import tryhackme.key
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key FFA4B5252BAEB2E6: public key "TryHackMe (Example Key)" imported
gpg: key FFA4B5252BAEB2E6: secret key imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
user@ip-10-10-133-8:~/Public-Crypto-Basics/Task-7$ gpg --decrypt message.gpg
gpg: encrypted with rsa1024 key, ID 2A0A5FDC5081B1C5, created 2020-06-30
      "TryHackMe (Example Key)"
You decrypted the file!
The secret word is Pineapple.