feat: add and improve documents
This commit is contained in:
parent
e387f93d75
commit
49be7c4c42
1
.netlify/v1/config.json
Normal file
1
.netlify/v1/config.json
Normal file
@ -0,0 +1 @@
|
||||
{"images":{"remote_images":[]},"headers":[{"for":"/_astro/*","values":{"Cache-Control":"public, max-age=31536000, immutable"}}]}
|
||||
1017
package-lock.json
generated
1017
package-lock.json
generated
File diff suppressed because it is too large
Load Diff
140
src/content/docs/advanced/gnupg-controller.md
Normal file
140
src/content/docs/advanced/gnupg-controller.md
Normal file
@ -0,0 +1,140 @@
|
||||
---
|
||||
title: A Comprehensive Guide of GpgController
|
||||
sidebar:
|
||||
label: Gpg Controller
|
||||
---
|
||||
|
||||
The **GpgController** in **GpgFrontend** is a powerful tool for configuring and
|
||||
managing GPG-related settings. It provides advanced options for file operations,
|
||||
password input methods, and custom GPG configurations, catering to both general
|
||||
and advanced users.
|
||||
|
||||
## Accessing the GpgController
|
||||
|
||||
To access the **GpgController**:
|
||||
|
||||
1. Navigate to the **Advanced** menu in the top toolbar.
|
||||
2. Select **Open GnuPG Controller** from the dropdown menu.
|
||||
|
||||
|
||||
|
||||
The **GpgController** interface includes three tabs: **General**, **Key
|
||||
Database**, and **Advanced**. Below is a detailed explanation of each tab's
|
||||
features.
|
||||
|
||||
## General Tab: Core Settings
|
||||
|
||||
The **General** tab provides essential configuration options for GpgFrontend's interaction with GPG.
|
||||
|
||||
|
||||
|
||||
### Available Options
|
||||
|
||||
1. **Use Binary Mode for File Operations**
|
||||
|
||||
- This option determines the format used for encrypted or signed files:
|
||||
- **Binary Mode**: Produces compact and efficient files, ideal for storage
|
||||
and processing.
|
||||
- **ASCII Mode**: Generates human-readable files encoded in ASCII format.
|
||||
This is useful for sharing files over email or systems that might corrupt
|
||||
binary files.
|
||||
- **Recommendation**: Use binary mode for local file operations and ASCII
|
||||
mode for file sharing or email attachments.
|
||||
|
||||
2. **Use Pinentry as Password Input Dialog**
|
||||
|
||||
- GpgFrontend includes a built-in password input dialog designed as a
|
||||
temporary fallback when no external **Pinentry** program is available.
|
||||
However, the built-in dialog has limitations and may not work for all
|
||||
password input scenarios.
|
||||
- **Recommendation**: Users are strongly encouraged to install a
|
||||
full-featured **Pinentry** program to ensure a seamless and secure password
|
||||
input experience. **Pinentry** is optimized for GnuPG's requirements and
|
||||
provides additional features such as better passphrase caching and hardware
|
||||
token support.
|
||||
|
||||
3. **Enable GpgME Debug Log**
|
||||
|
||||
- Enables verbose logging for troubleshooting GPG operations via the
|
||||
**GpgME** library. This is useful for advanced users diagnosing issues in
|
||||
encryption or signing workflows.
|
||||
|
||||
4. **Restart Gpg Agent on Start**
|
||||
|
||||
- Ensures that the GPG agent is restarted whenever GpgFrontend launches. This
|
||||
helps avoid issues caused by stale GPG agent processes.
|
||||
|
||||
5. **Kill All GPG Daemons at Close**
|
||||
|
||||
- Terminates all GPG-related background processes when the application exits.
|
||||
This ensures that no sensitive information is cached in memory or
|
||||
accessible after the session ends.
|
||||
- **Recommendation**: Always enable this option for improved security.
|
||||
|
||||
> **Note**: Changes to any settings in the General tab will require
|
||||
> restarting GpgFrontend to take effect.
|
||||
|
||||
---
|
||||
|
||||
## Key Database Tab: Overview
|
||||
|
||||
The **Key Database** tab allows users to manage multiple key databases. While
|
||||
detailed documentation is available elsewhere, note the following key points:
|
||||
|
||||
- **Add New Key Database**: Easily create and manage isolated key databases for
|
||||
different projects or security requirements.
|
||||
- **Switch Between Databases**: Use the **Key Toolbox** dropdown in the main
|
||||
interface to select the active database.
|
||||
|
||||
|
||||
|
||||
> For more information on key database management, refer to the dedicated
|
||||
> documentation.
|
||||
|
||||
---
|
||||
|
||||
## Advanced Tab: Custom GnuPG Configuration
|
||||
|
||||
The **Advanced** tab is designed for users who need to configure custom GPG installations.
|
||||
|
||||
|
||||
|
||||
### Configuring Custom GnuPG
|
||||
|
||||
1. **Enable Custom GnuPG**
|
||||
|
||||
- Check the **Use Custom GnuPG** box to enable this feature.
|
||||
|
||||
2. **Specify GPG Configuration Path**
|
||||
|
||||
- Use the **Select GnuPG Path** button to locate and set the directory where
|
||||
`gpgconf` resides. This is critical because GpgFrontend relies on the paths
|
||||
provided by `gpgconf` to locate essential components like `gpg`, `gpgsm`,
|
||||
and `gpg-agent`.
|
||||
|
||||
3. **Verifying Custom Configuration**
|
||||
|
||||
- After setting the path, you can test the configuration by running `gpgconf
|
||||
--list-components` in a terminal. This command lists all available GPG
|
||||
components and their paths, ensuring that GpgFrontend can access them
|
||||
correctly.
|
||||
|
||||
|
||||
|
||||
> **Note**: If `gpgconf` is not configured correctly, GpgFrontend may fail to
|
||||
> locate and execute necessary GPG binaries.
|
||||
|
||||
---
|
||||
|
||||
## Tips for Using GpgController Effectively
|
||||
|
||||
1. **Choose File Formats Wisely**
|
||||
|
||||
- Use **Binary Mode** for efficiency in local operations and **ASCII Mode**
|
||||
for readability and compatibility in file sharing.
|
||||
|
||||
2. **Install a Full-Featured Pinentry**
|
||||
|
||||
- Avoid relying on GpgFrontend's built-in password dialog for critical
|
||||
operations. Installing **Pinentry** ensures better compatibility and
|
||||
security.
|
||||
124
src/content/docs/advanced/key-database.md
Normal file
124
src/content/docs/advanced/key-database.md
Normal file
@ -0,0 +1,124 @@
|
||||
---
|
||||
title: Multi-Key Database Support
|
||||
sidebar:
|
||||
label: Multi-Key Database
|
||||
---
|
||||
|
||||
GpgFrontend introduces **Multi-Key Database Support**, providing users with a
|
||||
flexible and organized way to manage multiple key databases. This feature is
|
||||
ideal for users who require separate cryptographic environments for different
|
||||
projects, organizations, or levels of security.
|
||||
|
||||
## Features and Benefits
|
||||
|
||||
### Key Features
|
||||
|
||||
1. **Multiple Key Databases**: Manage distinct key databases for specific
|
||||
purposes or contexts.
|
||||
2. **Flexible Switching**: Easily switch between databases for different
|
||||
operations without affecting other configurations.
|
||||
3. **Customizable Management**: Add, edit, reorder, or remove databases as
|
||||
needed.
|
||||
|
||||
### Benefits
|
||||
|
||||
- **Improved Security**: Isolate sensitive keys in dedicated databases to
|
||||
minimize exposure.
|
||||
- **Enhanced Organization**: Maintain separate databases for better operational
|
||||
clarity.
|
||||
- **Streamlined Workflows**: Quickly switch between databases for various
|
||||
projects or encryption tasks.
|
||||
|
||||
## Accessing the Multi-Key Database Feature
|
||||
|
||||
### Opening the GnuPG Controller
|
||||
|
||||
To manage multiple key databases, follow these steps:
|
||||
|
||||
1. **Access the Advanced Menu**
|
||||
|
||||
- Click on the **Advanced** menu in the top navigation bar.
|
||||
- Select **Open GnuPG Controller** from the dropdown options.
|
||||
|
||||
|
||||
|
||||
2. **Navigate to the Key Database Tab**
|
||||
|
||||
- In the **GnuPG Controller** window, switch to the **Key Database** tab.
|
||||
- Here, you will find a list of all configured key databases.
|
||||
|
||||
|
||||
|
||||
## Managing Key Databases
|
||||
|
||||
The **Key Database** tab allows you to perform the following operations:
|
||||
|
||||
### 1. Adding a New Key Database
|
||||
|
||||
- Click the **Add New Key Database** button.
|
||||
- Specify a name and path for the new database. This will create an isolated
|
||||
environment for new keys.
|
||||
|
||||
### 2. Editing and Reordering Key Databases
|
||||
|
||||
- Right-click on a database entry to view options like:
|
||||
- **Move Up/Move Down**: Reorder the database list.
|
||||
- **Move to Top**: Prioritize a database by moving it to the top.
|
||||
- **Edit**: Rename or modify the path of an existing database.
|
||||
- **Remove**: Delete a database from the configuration.
|
||||
|
||||
|
||||
|
||||
> **Note**: Any changes to the key database settings will require an application
|
||||
> restart to take effect.
|
||||
|
||||
### 3. Switching Between Databases
|
||||
|
||||
- Use the **Key Toolbox** dropdown in the main interface to switch between
|
||||
configured databases.
|
||||
- Select the desired database, and the corresponding keys will be displayed.
|
||||
|
||||
|
||||
|
||||
## Use Cases for Multi-Key Databases
|
||||
|
||||
1. **Project Isolation**
|
||||
|
||||
- Maintain separate databases for different projects to avoid accidental
|
||||
cross-use of keys.
|
||||
|
||||
2. **Organizational Separation**
|
||||
|
||||
- Keep departmental or team-specific keys isolated to ensure they are only
|
||||
accessible to authorized personnel.
|
||||
|
||||
3. **Enhanced Security for Sensitive Keys**
|
||||
- Store high-security keys in a dedicated database, minimizing the risk of
|
||||
exposure during routine operations.
|
||||
|
||||
## Tips for Effective Multi-Key Database Usage
|
||||
|
||||
1. **Name Databases Clearly**
|
||||
|
||||
- Use descriptive names for each database to make it easier to identify their
|
||||
purpose.
|
||||
|
||||
2. **Regular Backups**
|
||||
|
||||
- Backup each database regularly to prevent loss of critical keys. Store
|
||||
backups in secure, encrypted locations.
|
||||
|
||||
3. **Audit Database Usage**
|
||||
|
||||
- Periodically review the contents and usage of each database to ensure
|
||||
proper organization and security.
|
||||
|
||||
4. **Isolate Sensitive Operations**
|
||||
|
||||
- For highly sensitive keys, consider using a dedicated device or environment
|
||||
to manage their database.
|
||||
|
||||
5. **Avoid Overloading Databases**
|
||||
|
||||
- Distribute keys evenly across multiple databases instead of overloading a
|
||||
single one. This enhances performance and organization.
|
||||
214
src/content/docs/advanced/module-controller.md
Normal file
214
src/content/docs/advanced/module-controller.md
Normal file
@ -0,0 +1,214 @@
|
||||
---
|
||||
title: "Module Controller: Extending GpgFrontend Functionality"
|
||||
sidebar:
|
||||
label: Module Controller
|
||||
---
|
||||
|
||||
The **Module Controller** in **GpgFrontend** allows users to manage modular
|
||||
extensions that enhance the core functionality of the application. These modules
|
||||
provide features such as email integration, version checking, and key
|
||||
synchronization, offering flexibility for different workflows.
|
||||
|
||||
This guide provides an overview of the **Module Controller** interface,
|
||||
instructions for managing modules, and guidance for advanced users interested in
|
||||
developing custom modules.
|
||||
|
||||
---
|
||||
|
||||
## Accessing the Module Controller
|
||||
|
||||
To access the **Module Controller**:
|
||||
|
||||
1. Open the **Advanced** menu in the top toolbar.
|
||||
2. Select **Open Module Controller**.
|
||||
|
||||
|
||||
|
||||
The **Module Controller** interface consists of the following tabs:
|
||||
|
||||
- **Registered Modules**
|
||||
- **Global Register Table**
|
||||
|
||||
---
|
||||
|
||||
## Registered Modules Tab
|
||||
|
||||
The **Registered Modules** tab displays all available modules and provides tools
|
||||
for managing their activation, metadata, and storage.
|
||||
|
||||
### Key Features
|
||||
|
||||
1. **Module List**
|
||||
|
||||
- The left panel lists all currently available modules.
|
||||
- Modules prefixed with `*` are **Integrated Modules**, meaning they are
|
||||
bundled with the GpgFrontend application.
|
||||
|
||||
2. **Module Information**
|
||||
|
||||
- When a module is selected, detailed metadata is displayed in the right
|
||||
panel, including:
|
||||
|
||||
- **ID**: The unique identifier of the module.
|
||||
- **Version**: The current module version.
|
||||
- **SDK Version**: The version of the SDK required by the module.
|
||||
- **Path**: The physical location of the module file.
|
||||
- **Activation Status**: Indicates whether the module is active or set to
|
||||
auto-activate.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
- ID: com.bktus.gpgfrontend.module.email
|
||||
- Version: 1.0.0
|
||||
- SDK Version: 2.1.5
|
||||
- Path: /path/to/module/file
|
||||
- Auto Activate: True
|
||||
- Active: True
|
||||
```
|
||||
|
||||
|
||||
|
||||
3. **Module Actions**
|
||||
|
||||
- **Deactivate**: Temporarily disables the selected module.
|
||||
- **Disable Auto Activate**: Prevents the module from loading automatically
|
||||
when GpgFrontend starts.
|
||||
|
||||
4. **Show Mods Directory**
|
||||
|
||||
- Opens the directory where external modules are stored. Users can manually
|
||||
add or remove custom modules by placing or deleting files in this
|
||||
directory.
|
||||
|
||||
> **Tip for Integrated Modules**:
|
||||
|
||||
- **Windows/Mac Users**: Integrated Modules (prefixed with `*`) can be
|
||||
removed by deleting the corresponding `.dll` (Windows) or `.dylib` (Mac)
|
||||
file from the `modules` directory.
|
||||
- **Linux Users**: Due to the nature of **AppImage** and **Flatpak**
|
||||
packages, removing Integrated Modules may require recompiling and
|
||||
repackaging the application.
|
||||
|
||||
## Global Register Table Tab
|
||||
|
||||
The **Global Register Table** provides a detailed view of the internal data
|
||||
structure used by GpgFrontend and its modules. This table is primarily useful
|
||||
for developers and advanced users who want to debug or inspect module
|
||||
interactions with the core application.
|
||||
|
||||
### Key Features
|
||||
|
||||
1. **Key-Value Data**
|
||||
|
||||
- Displays the hierarchical structure of global variables, including:
|
||||
- Module-specific settings (e.g., version checking, state tracking).
|
||||
- GnuPG paths and environment configurations.
|
||||
- Example:
|
||||
```
|
||||
gpgme:
|
||||
ctx:
|
||||
app_path: /opt/homebrew/Cellar/gnupg/2.4.5_1/bin/gpg
|
||||
gnupg_version: 2.4.5
|
||||
gpgconf_path: /opt/homebrew/bin/gpgconf
|
||||
```
|
||||
|
||||
2. **Navigation**
|
||||
|
||||
- Expand nodes to explore detailed properties for modules or core components.
|
||||
|
||||
|
||||
|
||||
## Developing Custom Modules
|
||||
|
||||
The **Module Controller** supports custom modules, allowing developers to extend
|
||||
GpgFrontend's functionality for specialized use cases. All modules adhere to a
|
||||
strict **C ABI (Application Binary Interface)** and are dynamically linked to
|
||||
the `libgpgfrontend_sdk` library.
|
||||
|
||||
### Key Points for Developers
|
||||
|
||||
1. **C ABI Compliance**
|
||||
|
||||
- Modules must be implemented using the C ABI to ensure compatibility across
|
||||
all supported platforms (Windows, macOS, Linux).
|
||||
|
||||
2. **Dynamic SDK Linking**
|
||||
|
||||
- Modules interact with GpgFrontend by linking dynamically to the
|
||||
**libgpgfrontend_sdk** library. This library provides the necessary
|
||||
interfaces for module initialization, data exchange, and runtime
|
||||
interaction.
|
||||
|
||||
3. **SDK Limitations**
|
||||
|
||||
- The current SDK API is still under development and may not cover all
|
||||
potential use cases. Developers are encouraged to contact the project
|
||||
maintainer for guidance or feature requests.
|
||||
|
||||
4. **Getting Started**
|
||||
- Place the compiled module file (`.dll`, `.dylib`, or `.so`) in the
|
||||
`modules` directory. Use the **Show Mods Directory** button to locate this
|
||||
directory.
|
||||
|
||||
---
|
||||
|
||||
## Tips for Managing Modules
|
||||
|
||||
1. **Backup Before Changes**
|
||||
|
||||
- Always create a backup of the `modules` directory before making changes,
|
||||
especially when adding or removing modules.
|
||||
|
||||
2. **Regular Updates**
|
||||
|
||||
- Check for updates to both GpgFrontend and its modules to ensure
|
||||
compatibility and access to the latest features.
|
||||
|
||||
3. **Safe Removal**
|
||||
|
||||
- Follow the guidelines for deleting Integrated Modules based on your
|
||||
platform to avoid accidental issues.
|
||||
|
||||
4. **Use Global Register Table for Debugging**
|
||||
- Advanced users can verify module configurations and GPG environment paths
|
||||
through the **Global Register Table**.
|
||||
|
||||
---
|
||||
|
||||
## Example Module: Version Checking
|
||||
|
||||
The **VersionChecking** module is a bundled example of how GpgFrontend uses
|
||||
modules to provide additional functionality.
|
||||
|
||||
### Features:
|
||||
|
||||
- Checks the current application version.
|
||||
- Displays release notes for new updates.
|
||||
- Notifies users when an upgrade is available.
|
||||
|
||||
### Example Metadata:
|
||||
|
||||
```
|
||||
- ID: com.bktus.gpgfrontend.module.version_checking
|
||||
- Version: 1.0.0
|
||||
- Auto Activate: True
|
||||
```
|
||||
|
||||
### Global Register Table:
|
||||
|
||||
```
|
||||
com.bktus.gpgfrontend.module.version_checking:
|
||||
current_version: v2.1.5
|
||||
need_upgrade: false
|
||||
latest_version: v2.1.5
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
By leveraging the **Module Controller**, users can customize and extend
|
||||
GpgFrontend to suit their needs. Developers interested in creating new modules
|
||||
are encouraged to experiment with the SDK and collaborate with the maintainer
|
||||
for additional API support. For more details, visit the [GpgFrontend Modules
|
||||
GitHub
|
||||
Repository](https://github.com/saturneric/GpgFrontend-Modules/blob/main/README.md).
|
||||
@ -63,7 +63,7 @@ be used to verify the authenticity of our releases:
|
||||
#### Key Fingerprint
|
||||
|
||||
```
|
||||
E3379489C39B7270E70E2E303AAF1C64137CEE57
|
||||
12F7E8858CF15BEC9975FF3C5CA3DA246843FD03
|
||||
```
|
||||
|
||||
#### Public Key (OpenPGP)
|
||||
@ -71,86 +71,13 @@ E3379489C39B7270E70E2E303AAF1C64137CEE57
|
||||
```
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
|
||||
mQGNBGCVnvEBDACuEcjxckb4rocHGU7VPT/OOOOZapNG/0ViB3XhmzNh7q8QJiq6
|
||||
M4z0fpC5sf1pHXbbKtehLETrAUTFuaEp19askZI0ISoz5+qKGZuaM3bDZWBjwUpt
|
||||
woVgUphfeZy2DFsnmTtVj9CRU9Nma6smXVFud3Roj2ImZ0NFrkdETvprfLJ7jqk/
|
||||
mXgznNbbJdqmQ4l0I1E91VmrqHHHSakh3grzRDj/GuDookQl2JZfLA0J55qOYdkF
|
||||
5mmnqbYURGVcP2oot/wSrrWH0F/WatwRx9w+jZjrJWgKjJoqWwvzG8WGop1XkRn1
|
||||
Ea3Nzj/KsSL7C5YRu03BL7wNu6UNIJ/zsAnNLp87nCY85w+HnNGHkL3QcnqNQbQP
|
||||
3aySOkIjXdT8AlGIV5r5wO/RBg4e+xASGzQXx9lYbjJiiIOP2uLxYGGFbalDoiCa
|
||||
sonlXzMZTJrK7VvZ2UsnSnBJ8l/EPsY/AeZdWbmswQaFsJlfNsZZ6T5Rfyjtu8a3
|
||||
fwPJTTsbfIB6N3EAEQEAAbQbU2F0dXJuZXJpYyA8ZXJpY0Bia3R1cy5jb20+iQHO
|
||||
BBMBCAA4AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEE4zeUicObcnDnDi4w
|
||||
Oq8cZBN87lcFAmCWg1kACgkQOq8cZBN87leJfQv/ShjV9PRi8ixlJ1Ez1TDG+4N9
|
||||
EHoi2IwVK1UF51kA9lxyD+8n1ZHpcz7bRXV+YhHAO4A2l1ENrkCJVIZK9OO+Z64l
|
||||
TPKCV9JVSkxcpnr6sqKJ76Zplwah1ZkwAG9tdK9H95wgeIkO4oSRutX/cCJ35Gko
|
||||
FfhbV+/OyPYTT2562SZeQ2VqnptGLm0eF+FVt0HP4uxvRyGfgHQD46Ki6dr/JOXQ
|
||||
j57S06CIHGj1RT4uQVSx53gbFvfIgweHsWraRWwY8jMrgOazlo/KRHG4N04eQdzM
|
||||
K+WA80ODKuXdhnlGFMhn3RCFZpRV+Upso9syJ1FFChzsuX69+mRPvAojEDnREgd9
|
||||
s61nx5xWy6vKMB9oZiomNuPw2EScBwS9EK0M6APqgBaIdL6HOC7kjxBLfqgyhulD
|
||||
qGZXWNvFj5P2FNMVwSvK1cYftYz+QWqB5BhbJT2H/HpF2xNsH7jfTxwUp6KrN1Bz
|
||||
geNWgpQDXS5ZXU7dk22BwSah3nXs+LJi3Sloeh/piQHUBBMBCAA+FiEE4zeUicOb
|
||||
cnDnDi4wOq8cZBN87lcFAmCVnvECGwMFCQPC1M8FCwkIBwIGFQoJCAsCBBYCAwEC
|
||||
HgECF4AACgkQOq8cZBN87le3zAv/fMnxVMORS5rz/vsc0X8YSldmM1MqdIKSNghK
|
||||
nQKKnzTBtTKA/oHEyPhjnQRaCfi4eUGeUsdZq8fwbN6sWSmbhJ6cOVgIps9YcS/U
|
||||
sCV4egUHGy/+ozgDSh563v82ROWxXjszcnFz0F2d4stgroe8A//3OgQDv1wuhMJe
|
||||
vtSZe8W8ebj7mt0zNjccGQzNkWo82mOyZfjgvK//vWisW4JwP8gfEKBgAktj5MCY
|
||||
iGS2NbWPAToDIPCA6hKPb3sHQIY2/tGkKwyvr4oxwYRkNq4T5PWcV0p3qRsQudHp
|
||||
ZXGiL3VNIW04ihLcn8uxSE6sQK2eq5wp/6Wnt1EWG1xb0pU2nPFuAlULHsGxM+bB
|
||||
YJOk5WzYST1xdgXW3QxVsIoTuVqA+ehqrzvu+gGCz4uenFt6OAswqR7ii8D/Tpso
|
||||
RAU0nTEOAVpCxXAMgsdUS6jOjtyfTHixGlVL6U3dY3wTuqWdbxmYX/g00PnOTYF0
|
||||
1plvf21NHMeYLk68+1nRbtqoLnPVuQGNBGCVnvEBDAC8zNpSGRHUp+X7hit0bCDP
|
||||
P8HR+rxH50rOVFtQNyXw32lkIrwnHq0Y7FR4t7OSWTkX1xvxhXMILQdTBxKKrBtF
|
||||
IpQ44cO1UcklkYdCwE/F0lasLLfleo2NlG7ISwNEOxmJcWiwmkLHN3CnqXpXXqpG
|
||||
DTRavbuhE7yRewp/jNSCsikrvL7NedB5Ef5EZmSkvx7kXibXKzgKcyft5OlylRMU
|
||||
JS8gzzTPA+xMH/Cl1zFCSgymJw1DK1wx+u0ye2Oj7NDdrYtRR1qLpCq7kaGIPvIW
|
||||
556/58sj+/YRGeP5JTjhYFk/K8QQr8cK6HWuJQVASJUP+KBk8CiaqzbOPjlq69eG
|
||||
Oymraa8H7JvSR5ArJWPczOxQyiEbYABOtJk1ZSz4v4pa7+RLUfwFOYuTMyBoY3rJ
|
||||
uGhVxA77oHftfjteH1YcKyJXrWnJEA2UbUmyRa5cwZ8S7HXOIvMhCQS897Tzjpab
|
||||
lfnIKE0n99c2ylJ4y4fHYSXYDKiCPKniFio8CxfqY+cAEQEAAYkBvAQYAQgAJhYh
|
||||
BOM3lInDm3Jw5w4uMDqvHGQTfO5XBQJglZ7xAhsMBQkDwtTPAAoJEDqvHGQTfO5X
|
||||
FbAL/0XZJW6XUca9d7f6Ft/0crMILRKID5uuSaLN1jG7BuLTwyWPhi7eSWbZQmlD
|
||||
Fun/E3vHFj3U/WG13DJL6M89f3707R6rKxT1B17Ht53bO9zHqJ9KesP1G+mR3phk
|
||||
hnxoQFlFvfSASZbDFtwEm3eZs55UBY4EPYf9MV+qPT0iNu1KPVX427uQfI0Ic/m4
|
||||
xFAO2XI11wMunDQoXi7rjknjYWxqVyGgqgRLrBD1Bb/aLenKN9Wn4FajEDaYrgpH
|
||||
46HHyhAOJ2RZbenWO689rZY6/0qPwDGRL7B2xiktu2G+e5JMJjuRhwEB0g63G8M1
|
||||
MVuRGr/PvrBjs58kF47rxWpp2xmo8dqCHjNS3ze9pl6oyshPa1J5zeDTNk3Ujgr9
|
||||
IJEzWLDWv9PP9ApcSD15Ia60bxSvsC8FJAZh81JEadLywx0QNBLmnMP3Dxpd21LK
|
||||
W8cWXa31F6E6eNf/45h7UGxVBRoOdPQ/Kwg4z69V9T/AXOuK65XgtG5ajwlmoQcv
|
||||
Vx7KIrkCDQRgloMRARAAtRIaNwOpLKA1ogvpzgx8/A8PeXCKvKPZ/ls+8sJ8RSZb
|
||||
b8lmd+HN52sotj3h9XGZXO1123WLW5F7n/M3HazRBRLlIoUf5kWnuQmXXmUZ6DEC
|
||||
mq9VoZ30CPHWDEZv/BoScXEHMZNEppziebe2r57SqY9cIONt7B2wzi3sVcYOtDye
|
||||
c+9BUQoEEv/grSfRN/1Lzezb8Ac9XY0Jet9XK/ImKbGCoxMNzszGQeFO2Neg4hVG
|
||||
65NIHjTRwzMUOp2D9GV14z/mu2xj5z0mP8zTLw2nzjSW8b0s9ewsvawH45s+XBS8
|
||||
ndMU3R+pnHqZBJXU1OR9XjSSMZhaNk+cpOgVwlmbGhNUZ4jSPNVZr/fABpgpY7Bh
|
||||
ctY42Q3DZVSMwSmiGZA2Uoy7kKx2qtm1Q0ogh6x5mq9QKHODuh+Uc1XhbqxheySv
|
||||
/jWxvnWhRqaRMBIY+H6vFbXRkQvYjdtwwHZvBRyF5VOsdSUbdLunjyIeKTl2wMqR
|
||||
hm0y2li+nbTE+zbCcguGPtIMZq6V08M3OZZGxT1jZZocOi3y0qwuApaQvAvk7GpC
|
||||
mjjbSsq/ykbPUMSQHqAh77YY/9/v2kBh5u21fBPmtPyndAeZTNyukJ2dq8pecVgP
|
||||
eqT/sSs/Gn56T1cekPEIuUkUxQ4K1sLah1z4G+jg8VqCPIj4yBH6pfd6zBEPx70A
|
||||
EQEAAYkD8gQYAQgAJhYhBOM3lInDm3Jw5w4uMDqvHGQTfO5XBQJgloMRAhsCBQkH
|
||||
hh93AkAJEDqvHGQTfO5XwXQgBBkBCAAdFiEExEoeTMpVzDyCCrnkOlA5Ga/6SF8F
|
||||
AmCWgxEACgkQOlA5Ga/6SF9U+hAAs59FJP2pCQDnrFCrmk38mVePAyPNceSm7IEl
|
||||
zJWuoxf6XOkz7SP7Vh4mPxyRj3yltEnFN5tLvDOF8W+AwMMMHrK9TnXxnJ2HwCbY
|
||||
ifLgAGmNrMq+IoagTJDAZvlkp4m3gHe6zDYv9UIbFKdnB48FbwtahNm9LjMbqNDc
|
||||
nLBt+IuiO/PXUu6c56Wl+L9ntOSVLb1ySnRisI4iYx4J80GcFaMjlJFjQ5uGt0jh
|
||||
Ardq4zFLYgJfTTl6cM8WTANiKO2a6DgpZxb1knfKOjdasqeQcEs4ZcB6Nf9Bcw/X
|
||||
Qe2Ee85FA+qClxuIMTT5l6fDw+DXgZfSR0clwA4rMY7hCUvuRxCjc1LDOCbyHe/Z
|
||||
PUAntlNNKrXEicXxi8Odpzcq0/rDR53OMyzFhGXpbbxa89F/B96H249IW/waefN6
|
||||
VKpSb693VOyl8AtQ2tRAvy7YxYyhUQIKKCuahjdoib3GmFNE67rjW9MUVfefIhvp
|
||||
nBJaY8tp8YhYrDF0U9DMuYrTLcPu5VsR7gvlFY30If1XCavpAnq+eNaxIdTDIKfJ
|
||||
Q2cgALPBfzogEOeR+RY4Lo46dIGCaEYTpbImcJdum0GVACoMb0T1oOXIHWd1hy46
|
||||
ianYKGxMmjfS1f13cr6F1U18l8QKMBZhNTBazw2IdXaugdnbqryEsp20zPQ+caGR
|
||||
+E1wZmOLMAv+JMPJSK7Ra9cQf6GEos1XurjhaoegPh0Y9U4p1Dk1pQduI7togmJ/
|
||||
bhvIpawfi52rI/4I4g1HqjcU8iG6ZjTVE7kVVvDISex71czbmV9isWvW0HJlDgTQ
|
||||
piZbTCPqvgyEZRF0eIA+VTXOKD/qUwxvw3jo75KEcmW+sezqctREgH02EBPuD5GC
|
||||
Qyxi7+nNq37FTNYReydCEGEDfJXZ6x12FkW9nPe2fkxx7WT/ceVT2jGtSG4re5vk
|
||||
wYtnfgKvfHXYmTudoMuVmIsJc9zcdvhL1Nmrd1BOyeJmQCNyvwP48OkU5TqIGHc4
|
||||
PcbwniPKO8tozjuwE+iO2TjgwWc/Eg5hLPGYlyqalysP4nOO/KYLBwvgTrPse40N
|
||||
jg4/3Ew4DKxsrHtCGfhx+i5pXVYwbWklPd7mDmmvxnM5gFEqs0VMMGsjElCzDsmm
|
||||
v3fSDNozRpd0LXK7J4QGwtOBVivNf7XDQOx5ZXbh/HTQuTG2/8FMCbwUwPYFLx07
|
||||
hHHFn9+/wu20
|
||||
=bgvm
|
||||
mDMEZsEF1xYJKwYBBAHaRw8BAQdAPZ3dA2od9HFaiaJRr1TEEeRMfAcrBp8oqQPa
|
||||
R16Icva0OHNhdHVybmVyaWMoZm9yIGNvZGUgb3IgYmluYXJ5IHNpZ24gb25seSk8
|
||||
ZXJpY0Bia3R1cy5jb20+iJkEExYKAEEWIQQS9+iFjPFb7Jl1/zxco9okaEP9AwUC
|
||||
ZsEF1wIbIwUJA8JmbgULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRBco9ok
|
||||
aEP9A3TTAQC/H61IVj6LiSQ0dvodo5VFb2jTJa8XVfb2NT3yc/+JDwD+KTm+nV73
|
||||
dbaEG0FOTKu+n4rVhBpTes93Bn2GcRSbQwA=
|
||||
=fWZe
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
```
|
||||
|
||||
|
||||
@ -51,13 +51,14 @@ dependencies:
|
||||
This variant ensures compatibility with earlier Windows environments,
|
||||
extending the tool's accessibility and usability.
|
||||
|
||||
- **GnuPG 2.2.0 or Higher:** GpgFrontend integrates with GnuPG for its
|
||||
- **GnuPG 2.1.0 or Higher:** GpgFrontend integrates with GnuPG for its
|
||||
cryptographic operations, including encryption, decryption, and digital
|
||||
signing. GnuPG (version 2.2.0 or newer) is a necessary component to leverage
|
||||
the full capabilities of GpgFrontend. Please note, GnuPG 1.x versions are not
|
||||
supported by GpgFrontend due to differences in functionality and support.
|
||||
Users are encouraged to use GnuPG 2.x to ensure compatibility and secure
|
||||
operations.
|
||||
signing. While GpgFrontend supports GnuPG version 2.1.0 or newer, some
|
||||
features may not be fully functional with versions below 2.4.0. For the best
|
||||
compatibility and to ensure access to all features, it is strongly recommended
|
||||
to use GnuPG 2.4.0 or higher. Please note that GnuPG 1.x versions are not
|
||||
supported due to significant differences in functionality and lack of modern
|
||||
security updates.
|
||||
|
||||
By catering to a wide range of operating systems and ensuring backward
|
||||
compatibility with older Windows versions through Qt5 support, GpgFrontend
|
||||
|
||||
@ -6,7 +6,8 @@ sidebar:
|
||||
|
||||
When choosing cryptographic algorithms for key management and data security,
|
||||
it's important to understand the differences and use cases for RSA, DSA, ECDSA,
|
||||
and ECDH. Here’s a detailed comparison to help you make an informed decision:
|
||||
EdDSA, and ECDH. Here’s a detailed comparison to help you make an informed
|
||||
decision.
|
||||
|
||||
## RSA (Rivest-Shamir-Adleman)
|
||||
|
||||
@ -23,20 +24,6 @@ and ECDH. Here’s a detailed comparison to help you make an informed decision:
|
||||
- **Security**: Provides strong security, but larger key sizes are required as
|
||||
computational power increases.
|
||||
|
||||
## DSA (Digital Signature Algorithm)
|
||||
|
||||
- **Key Characteristics**: DSA, introduced by NIST in 1991, is primarily used
|
||||
for digital signatures and is not suitable for encryption.
|
||||
- **Key Sizes**: Typically uses 1024 to 3072-bit keys, with a recommended
|
||||
minimum of 2048 bits for new deployments.
|
||||
- **Use Cases**: Mainly used for digital signatures in various security
|
||||
protocols. It is less common than RSA and ECDSA.
|
||||
- **Performance**: Faster at generating keys compared to RSA but slower in
|
||||
verification. Requires a secure random number for each signature, which if
|
||||
compromised, can lead to vulnerabilities.
|
||||
- **Security**: Suitable for digital signatures, but less versatile and not as
|
||||
widely supported as RSA and ECDSA.
|
||||
|
||||
## ElGamal Encryption (ELG-E)
|
||||
|
||||
- **Key Characteristics**: ElGamal encryption (ELG-E) is an asymmetric key
|
||||
@ -84,52 +71,136 @@ used in two main algorithms: ECDH and ECDSA.
|
||||
|
||||
### Common ECC Algorithms and Their Use Cases
|
||||
|
||||
- **NIST Curves (P-256, P-384, P-521)**: These curves, standardized by the
|
||||
National Institute of Standards and Technology (NIST), are widely used in
|
||||
secure communication protocols. For example, **ECDH NIST P-256** provides
|
||||
approximately 128-bit security, making it suitable for most encryption needs,
|
||||
while **ECDSA NIST P-256** is often used for digital signatures. As the key
|
||||
size increases (e.g., P-384, P-521), so does the security level, with P-521
|
||||
offering approximately 256-bit security, ideal for applications requiring the
|
||||
highest level of protection.
|
||||
Elliptic Curve Cryptography (ECC) offers a range of algorithms and curves
|
||||
tailored to different cryptographic needs. Below is an overview of commonly used
|
||||
ECC algorithms and their specific applications.
|
||||
|
||||
- **ED25519 and ED448**: **ED25519** is favored for its speed and security,
|
||||
providing 128-bit security and commonly used in modern applications like
|
||||
secure messaging (e.g., Signal) and blockchain technologies. **ECDSA ED25519**
|
||||
is excellent for generating fast and secure digital signatures. **ED448**, on
|
||||
the other hand, offers higher security (224-bit) and is suitable for
|
||||
environments that require even stronger protection, although at a slight
|
||||
performance cost.
|
||||
- **NIST Curves (P-256, P-384, P-521)**: Standardized by the National Institute
|
||||
of Standards and Technology (NIST), these curves are widely utilized in secure
|
||||
communication protocols. For example:
|
||||
|
||||
- **BrainPool Curves (P-256, P-384, P-512)**: These curves are alternatives to
|
||||
the NIST standards, offering similar security levels but with different
|
||||
parameters. **ECDH BrainPool P-256** and **ECDSA BrainPool P-256** are used
|
||||
when there is a preference for non-NIST curves, especially in regions or
|
||||
industries where alternative cryptographic standards are required. The
|
||||
BrainPool curves maintain the balance between security and performance across
|
||||
different key sizes.
|
||||
- **ECDH NIST P-256**: Provides approximately 128-bit security, making it
|
||||
suitable for most encryption scenarios.
|
||||
- **ECDSA NIST P-256**: Commonly employed for digital signatures, offering
|
||||
robust security for authentication purposes.
|
||||
- **Higher Key Sizes**: P-384 and P-521 increase security levels
|
||||
proportionally, with P-521 offering around 256-bit security, making it ideal
|
||||
for high-security environments.
|
||||
|
||||
- **CV25519 and X448**: **ECDH CV25519** is a counterpart to ED25519 but is used
|
||||
specifically for key exchange. It provides approximately 128-bit security and
|
||||
is widely used for its efficiency in secure communications. **ECDH X448** is
|
||||
the higher-security variant (224-bit security) and is appropriate for
|
||||
scenarios demanding more robust encryption, albeit with higher computational
|
||||
costs.
|
||||
- **BrainPool Curves (P-256, P-384, P-512)**: BrainPool curves serve as
|
||||
alternatives to NIST standards, providing similar security levels but with
|
||||
independently developed parameters.
|
||||
|
||||
## Algorithm Flexibility in Primary Keys and Subkeys
|
||||
- **Use Cases**: Often used in regions or industries that prefer non-NIST
|
||||
curves for compliance or operational reasons.
|
||||
- **Examples**: **ECDH BrainPool P-256** and **ECDSA BrainPool P-256** offer a
|
||||
balance between security and performance, catering to scenarios where NIST
|
||||
standards are not desired.
|
||||
|
||||
Primary keys are typically limited to RSA, DSA, and ECDSA due to their critical
|
||||
role in establishing trust and signing other keys. These algorithms are
|
||||
well-established and extensively audited, providing robust security for identity
|
||||
verification.
|
||||
- **CV25519 and X448**: These curves are optimized for performance and are
|
||||
widely used in modern cryptographic applications.
|
||||
|
||||
Subkeys, however, are often used for specific operational tasks such as
|
||||
encryption and authentication. This allows them to utilize a broader range of
|
||||
algorithms like ECDH, which is optimized for key exchange. The flexibility in
|
||||
choosing algorithms for subkeys enhances their efficiency and allows
|
||||
cryptographic operations to be tailored to specific use cases, providing both
|
||||
performance and security benefits.
|
||||
- **ECDH CV25519**: A counterpart to ED25519, this curve is designed for key
|
||||
exchange and offers approximately 128-bit security. It is highly efficient
|
||||
in secure communications.
|
||||
- **ECDH X448**: A higher-security variant providing 224-bit security,
|
||||
suitable for applications requiring more robust encryption. However, it
|
||||
comes with a slight trade-off in computational efficiency.
|
||||
|
||||
By understanding the strengths and appropriate use cases for each algorithm, you
|
||||
can choose the best cryptographic solution for your needs, ensuring both
|
||||
security and efficiency in your operations.
|
||||
- **SECP256K1**: Defined by the Standards for Efficient Cryptography Group
|
||||
(SECG), SECP256K1 is distinct from NIST curves and has gained significant
|
||||
traction due to its adoption in blockchain technologies.
|
||||
- **Key Use Case**: Widely used for cryptographic operations in Bitcoin and
|
||||
other blockchain systems, where efficient signature verification is crucial.
|
||||
- **Performance**: Optimized for computational efficiency, making it an
|
||||
excellent choice for environments requiring rapid cryptographic operations.
|
||||
|
||||
## EdDSA (Edwards-Curve Digital Signature Algorithm)
|
||||
|
||||
### **Overview**
|
||||
|
||||
EdDSA is a modern digital signature algorithm based on elliptic curve
|
||||
cryptography. It is specifically designed to be more efficient, secure, and
|
||||
resistant to common implementation errors compared to older algorithms like DSA
|
||||
or ECDSA.
|
||||
|
||||
### **Key Characteristics**
|
||||
|
||||
- **Deterministic Signature Generation**: Unlike ECDSA and DSA, which require
|
||||
secure random numbers for each signature, EdDSA uses deterministic methods,
|
||||
reducing the risk of vulnerabilities caused by poor randomness.
|
||||
- **Elliptic Curves Used**: EdDSA supports two primary curves:
|
||||
- **Ed25519**: Provides 128-bit security and is optimized for speed and
|
||||
compact key sizes.
|
||||
- **Ed448**: Provides higher 224-bit security for environments requiring
|
||||
greater protection but at the cost of performance.
|
||||
|
||||
### **Use Cases**
|
||||
|
||||
- **Ed25519**: Ideal for secure messaging (e.g., Signal), blockchain, and other
|
||||
modern cryptographic protocols where performance and efficiency are critical.
|
||||
- **Ed448**: Used in environments requiring stronger security, such as highly
|
||||
sensitive communications or systems with long-term security needs.
|
||||
|
||||
### **Performance**
|
||||
|
||||
EdDSA is faster than RSA and ECDSA for both signing and verification. Its
|
||||
compact key sizes make it ideal for resource-constrained devices or systems.
|
||||
|
||||
### **Compatibility**
|
||||
|
||||
While Ed25519 has gained significant adoption in modern cryptographic libraries,
|
||||
it is not yet universally supported in older systems or clients. Ed448 has even
|
||||
more limited support.
|
||||
|
||||
## Why ECDH Cannot Be Used as a Primary Key Algorithm
|
||||
|
||||
### Key Difference Between ECDH and ECDSA/EdDSA
|
||||
|
||||
- **ECDH (Elliptic Curve Diffie-Hellman)** is a key exchange algorithm used to
|
||||
establish shared secrets between two parties. It is not designed for signing
|
||||
or verification, which are essential for primary key functionalities.
|
||||
- **ECDSA (Elliptic Curve Digital Signature Algorithm)** and **EdDSA** are
|
||||
signature algorithms, specifically designed for identity verification and
|
||||
creating/verifying digital signatures, making them suitable for primary keys.
|
||||
|
||||
### Primary Key Requirements
|
||||
|
||||
Primary keys are used to:
|
||||
|
||||
1. **Sign Other Keys**: Establish trust relationships by signing subordinate
|
||||
keys.
|
||||
2. **Verify Identities**: Sign and verify data, proving ownership of the key.
|
||||
|
||||
Since ECDH does not provide signature functionality, it cannot be used for these
|
||||
purposes. Instead, it is commonly used for subkeys dedicated to encryption or
|
||||
key exchange tasks.
|
||||
|
||||
## Recommended Algorithms for Compatibility and Security
|
||||
|
||||
### **1. RSA (2048-bit or 3072-bit)**
|
||||
|
||||
- **Why**: RSA offers the broadest compatibility across legacy systems,
|
||||
libraries, and cryptographic protocols.
|
||||
- **When to Use**: Choose RSA when you need to ensure interoperability with
|
||||
older clients or systems that may not support newer elliptic curve algorithms.
|
||||
|
||||
### **2. Curve25519**
|
||||
|
||||
- **Why**: Curve25519 is highly efficient, secure, and compact, making it a great
|
||||
choice for modern cryptographic applications.
|
||||
- **When to Use**: Use Curve25519 in environments where compatibility with
|
||||
modern systems is sufficient, and you want to benefit from its speed and
|
||||
smaller key sizes.
|
||||
|
||||
### Combining RSA and Curve25519
|
||||
|
||||
For the best balance between compatibility and performance, consider using RSA
|
||||
for the **primary key** (for identity verification and signing other keys) and
|
||||
Curve25519 for **subkeys** (used for signing, encryption, or authentication).
|
||||
This approach ensures:
|
||||
|
||||
- **Maximum Compatibility**: RSA as the primary key ensures interoperability
|
||||
with older systems.
|
||||
- **Modern Efficiency**: Curve25519 as subkeys provides better performance for
|
||||
modern operations.
|
||||
|
||||
182
src/content/docs/guides/email.md
Normal file
182
src/content/docs/guides/email.md
Normal file
@ -0,0 +1,182 @@
|
||||
---
|
||||
title: Email Functionality
|
||||
sidebar:
|
||||
label: Email Operations
|
||||
---
|
||||
|
||||
GpgFrontend offers a powerful and user-friendly solution for email encryption
|
||||
and signing, tailored for security-conscious users. By processing emails offline
|
||||
in a widely supported `.eml` format, it eliminates the need for complex
|
||||
protocols while maintaining robust OpenPGP compliance. Whether you're signing,
|
||||
encrypting, verifying, or decrypting emails, GpgFrontend ensures a secure and
|
||||
streamlined experience.
|
||||
|
||||
## **Purpose and Key Advantages**
|
||||
|
||||
GpgFrontend's email processing functionality is designed to empower users to
|
||||
handle PGP-signed and encrypted emails in situations where their email clients
|
||||
or web-based email services lack native PGP support. The core advantages
|
||||
include:
|
||||
|
||||
- **Offline Verification and Decryption**: Users can securely process emails
|
||||
locally without uploading their private keys to email providers. This
|
||||
significantly enhances privacy and security.
|
||||
- **EML Format Handling**: By leveraging the widely supported `.eml` format,
|
||||
GpgFrontend avoids introducing complex protocols like IMAP or SMTP,
|
||||
maintaining simplicity while offering full OpenPGP compliance.
|
||||
- **Security-Focused**: For security-conscious users, GpgFrontend provides an
|
||||
offline, local-first solution that minimizes exposure to online threats and
|
||||
untrusted environments.
|
||||
|
||||
## **Features Overview**
|
||||
|
||||
### **1. OpenPGP Standards Compliance**
|
||||
|
||||
GpgFrontend adheres to OpenPGP standards (RFC 4880 and 3156) for email
|
||||
encryption and signing, ensuring compatibility with tools like Thunderbird and
|
||||
other OpenPGP-enabled clients.
|
||||
|
||||
- Emails processed in GpgFrontend can be easily verified and decrypted by
|
||||
compliant email clients.
|
||||
- Supports separate and combined operations, such as:
|
||||
- **Sign Only**: Digitally sign the email to ensure authenticity.
|
||||
- **Encrypt Only**: Encrypt the email to protect its content.
|
||||
- **Sign and Encrypt Together**: Combine both operations for comprehensive
|
||||
security.
|
||||
- **Decrypt and Verify Together or Separately**: Flexibly handle incoming
|
||||
messages.
|
||||
|
||||
### **2. Creating and Processing Emails**
|
||||
|
||||
#### **Creating and Signing Emails**
|
||||
|
||||
1. Open GpgFrontend and click **"New E-Mail"** to create a blank email.
|
||||
|
||||
|
||||
|
||||
2. Type your email content in the editor.
|
||||
3. Select your private key from the **Key Toolbox**.
|
||||
4. Click **"Sign"** to digitally sign the email.
|
||||
- Signed emails include a PGP signature block, visible in the content.
|
||||
|
||||
|
||||
|
||||
#### **Encrypting Emails**
|
||||
|
||||
1. Select the recipient's public key in the **Key Toolbox**.
|
||||
2. Click **"Encrypt"** to secure the email content.
|
||||
- The content will be transformed into a PGP-encrypted format.
|
||||
|
||||
|
||||
|
||||
#### **Saving Emails for Sending**
|
||||
|
||||
1. Processed emails can be saved as `.eml` files using **File > Save As**.
|
||||
2. Upload the `.eml` file to your email client's drafts folder or webmail
|
||||
interface, then send the email.
|
||||
|
||||
### **3. Receiving and Processing Emails**
|
||||
|
||||
#### **Decrypting and Verifying Emails**
|
||||
|
||||
1. Export the email source as an `.eml` file from your email client or copy the
|
||||
raw email source.
|
||||
2. Open the `.eml` file in GpgFrontend.
|
||||
3. Use:
|
||||
- **"Decrypt Verify"**: Decrypt and verify the email simultaneously.
|
||||
- **"Verify"**: Validate the signature without decrypting.
|
||||
- **"Decrypt"**: Decrypt without verifying.
|
||||
|
||||
|
||||
|
||||
#### **Offline Validation**
|
||||
|
||||
- GpgFrontend processes all email verification and decryption offline, ensuring
|
||||
that no sensitive data is exposed to external servers.
|
||||
- Users retain full control of their private keys, which remain stored locally.
|
||||
|
||||
### **4. Why Use EML Format?**
|
||||
|
||||
#### **Benefits of EML**
|
||||
|
||||
- `.eml` is a widely supported format across email clients like Thunderbird,
|
||||
Outlook, and webmail platforms.
|
||||
- Unlike proprietary email handling protocols, `.eml` allows for seamless
|
||||
export, import, and offline processing.
|
||||
|
||||
#### **Why Not Use IMAP/SMTP?**
|
||||
|
||||
- Avoids the complexity and potential vulnerabilities introduced by integrating
|
||||
full-fledged email protocols.
|
||||
- Keeps the application lightweight and focused on local cryptographic
|
||||
operations.
|
||||
|
||||
#### **Addressing PGP Limitations in Clients**
|
||||
|
||||
- Many email clients lack robust PGP support or offer inconsistent
|
||||
implementations.
|
||||
- GpgFrontend provides a reliable and flexible solution for users needing
|
||||
advanced PGP functionality.
|
||||
|
||||
## **Key Use Cases**
|
||||
|
||||
### **1. Sending Emails**
|
||||
|
||||
1. Process the email in GpgFrontend (e.g., sign, encrypt, or both).
|
||||
2. Save the processed email as an `.eml` file.
|
||||
3. Import the `.eml` file into your email client or webmail interface, then send
|
||||
it.
|
||||
|
||||
### **2. Receiving Emails**
|
||||
|
||||
1. Export the email source as `.eml` from your email client.
|
||||
2. Open it in GpgFrontend to decrypt or verify.
|
||||
3. For example:
|
||||
- A signed email will display a **"Good Digital Signature"** message.
|
||||
- An encrypted email will be decrypted and displayed in plaintext.
|
||||
|
||||
## **Advanced Features**
|
||||
|
||||
### **1. Combined Operations**
|
||||
|
||||
- GpgFrontend supports simultaneous encryption and signing of outgoing emails.
|
||||
- Incoming emails can also be decrypted and verified in a single operation for
|
||||
convenience.
|
||||
|
||||
### **2. Flexible Processing**
|
||||
|
||||
- Choose separate or combined workflows for signing, encrypting, verifying, or
|
||||
decrypting based on your needs.
|
||||
- This flexibility makes GpgFrontend a versatile tool for various email
|
||||
scenarios.
|
||||
|
||||
### **3. Offline-First Design**
|
||||
|
||||
- All cryptographic operations are performed locally, ensuring that private keys
|
||||
and sensitive data are never exposed to external servers.
|
||||
|
||||
## **Best Practices for Secure Email Handling**
|
||||
|
||||
1. **Use Trusted Keys**:
|
||||
|
||||
- Regularly validate public keys to prevent misuse.
|
||||
- Import keys only from trusted sources.
|
||||
|
||||
2. **Keep Private Keys Offline**:
|
||||
|
||||
- Avoid uploading private keys to email providers.
|
||||
- Store private keys securely, preferably on encrypted storage.
|
||||
|
||||
3. **Leverage GpgFrontend's Local Processing**:
|
||||
|
||||
- Ensure all encryption, signing, and verification tasks are performed
|
||||
offline for maximum security.
|
||||
|
||||
4. **Save Emails in EML Format**:
|
||||
|
||||
- Use `.eml` files for cross-platform compatibility and simple integration
|
||||
with various email clients.
|
||||
|
||||
5. **Check Email Compatibility**:
|
||||
- Ensure recipients can handle PGP-encrypted emails or provide instructions
|
||||
for using tools like GpgFrontend or Thunderbird.
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Generate Key Pair & Subkey
|
||||
title: Generate Key Pair
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
@ -65,188 +65,16 @@ signing, and authentication. Follow the steps below to create your own keys.
|
||||
By following these steps, you can generate a secure key pair using GpgFrontend,
|
||||
tailored to your specific needs for encryption, signing, and authentication.
|
||||
|
||||
## Steps to Generate a Subkey
|
||||
|
||||
|
||||
|
||||
1. **Open Key Management**:
|
||||
|
||||
- In the Key Management interface, right-click on the key pair you wish to
|
||||
add a subkey to. Select the "New Subkey" option from the context menu.
|
||||
|
||||
2. **Fill in Basic Information**:
|
||||
|
||||
- **Key Type**: Select the type of subkey you want to generate. Available
|
||||
options include RSA, DSA, ECDSA, ECDH, ECDH NIST P-256, ECDH NIST P-384,
|
||||
ECDH NIST P-521, ECDH BrainPool P-256, ECDH BrainPool P-384, and ECDH
|
||||
BrainPool P-512.
|
||||
- **Key Size**: Choose the key size. This option is only applicable when the
|
||||
key type is RSA or DSA.
|
||||
- **Expiration Date**: Set an expiration date for the subkey. You can also
|
||||
choose to check the "Never expire" checkbox to make the subkey permanent.
|
||||
|
||||
3. **Set a Passphrase**:
|
||||
|
||||
- If the primary key has a passphrase, the subkey's passphrase must be equal
|
||||
to it. Ensure that the "Non Pass Phrase" checkbox is unchecked if you want
|
||||
to set a passphrase.
|
||||
|
||||
4. **Select Key Usage**:
|
||||
|
||||
- Specify the usage for the subkey. Options include:
|
||||
- **Encryption**: For encrypting data.
|
||||
- **Signing**: For creating digital signatures.
|
||||
- **Authentication**: For authentication purposes, such as SSH keys.
|
||||
- Note that the certification usage is not available for subkeys.
|
||||
|
||||
5. **Generate the Subkey**:
|
||||
- After filling in all the necessary information and selecting the desired
|
||||
options, click the "OK" button to generate your subkey.
|
||||
|
||||
By following these steps, you can generate a subkey using GpgFrontend, which
|
||||
enhances the functionality of your primary key pair for various cryptographic
|
||||
operations.
|
||||
|
||||
## Extra Note
|
||||
|
||||
Below are some guidelines that may prove useful in comprehending the
|
||||
aforementioned concepts and utilizing this tool accurately.
|
||||
|
||||
#### Understanding Primary Keys and Subkeys
|
||||
|
||||
In the realm of cryptography, key management plays a crucial role in ensuring
|
||||
data security. A key pair consists of a primary key and one or more subkeys,
|
||||
each serving distinct functions yet working together to secure and manage
|
||||
digital identities and communications. This structure not only enhances security
|
||||
but also provides flexibility in key usage and management.
|
||||
|
||||
#### The Role of Primary Key and Subkeys
|
||||
|
||||
- **Primary Key**: The primary key is the cornerstone of your cryptographic
|
||||
identity. It is used for identity verification, which includes signing other
|
||||
keys to establish trust. The primary key's signature on a subkey validates the
|
||||
subkey's association with the identity of the primary key holder.
|
||||
|
||||
- **Subkeys**: Subkeys are associated with the primary key and are used for
|
||||
encryption and signing documents or messages. Subkeys can be thought of as
|
||||
extensions of the primary key, each designated for specific tasks. This
|
||||
separation of duties allows for greater security and operational flexibility.
|
||||
For example, you can have separate subkeys for signing and encryption.
|
||||
|
||||
#### Advantages of Using Subkeys
|
||||
|
||||
1. **Enhanced Security**: By using subkeys for day-to-day operations, you
|
||||
minimize the risk associated with key exposure. If a subkey is compromised,
|
||||
it can be revoked without affecting the primary key or other subkeys, thereby
|
||||
limiting the potential damage.
|
||||
|
||||
2. **Operational Flexibility**: Subkeys allow for specific roles (e.g., signing,
|
||||
encryption) to be isolated. This means you can renew or revoke subkeys as
|
||||
needed without disrupting the overall cryptographic setup.
|
||||
|
||||
3. **Convenient Key Rotation**: Regularly updating keys is a best practice in
|
||||
cryptography. Subkeys make it easier to rotate keys for signing and
|
||||
encryption without needing to re-establish the primary key's trust
|
||||
relationships.
|
||||
|
||||
#### Managing Primary Keys and Subkeys
|
||||
|
||||
- **Secure Storage**: The primary key should be stored in a highly secure
|
||||
location, preferably offline or in a hardware security module (HSM), to
|
||||
prevent unauthorized access. The loss or compromise of the primary key
|
||||
jeopardizes the entire cryptographic framework.
|
||||
|
||||
- **Key Generation and Maintenance**: While tools like GpgFrontend provide
|
||||
user-friendly interfaces for managing keys, they may lack support for advanced
|
||||
operations like generating multiple subkeys. Therefore, using the command-line
|
||||
`gpg` tool for such tasks is advisable. Despite this limitation, GpgFrontend
|
||||
can play a critical role in monitoring the presence of the primary key, which
|
||||
is essential for certain operations like adding subkeys or signing other keys.
|
||||
|
||||
- **Revocation and Renewal**: Prepare revocation certificates for your primary
|
||||
key and subkeys in advance. In case of key compromise or expiration, these
|
||||
certificates allow you to invalidate the keys, informing others in your trust
|
||||
network not to use them anymore.
|
||||
|
||||
#### Practical Tips for Effective Key Management
|
||||
|
||||
- **Purpose-Specific Subkeys**: If your primary key was not generated with
|
||||
certain capabilities (e.g., encryption), you can create a subkey with the
|
||||
required functionality. This allows the key pair to be used for the intended
|
||||
cryptographic operations without regenerating the primary key.
|
||||
|
||||
- **Multiple Subkeys for Different Devices**: For users operating across
|
||||
multiple devices, generating separate subkeys for each device can enhance
|
||||
security. If one device is compromised, only the subkey on that device needs
|
||||
to be revoked, leaving the others unaffected.
|
||||
|
||||
- **Backup and Recovery**: Regularly back up your key pair, including the
|
||||
primary key and all subkeys. Secure backups ensure that you can recover your
|
||||
cryptographic capabilities even in the event of hardware failure or data loss.
|
||||
|
||||
In summary, understanding and implementing a robust key management strategy,
|
||||
with a clear distinction between primary keys and subkeys, is essential for
|
||||
maintaining the integrity and security of cryptographic operations. By adhering
|
||||
to best practices for key usage, storage, and renewal, users can safeguard their
|
||||
digital identities and ensure the confidentiality and authenticity of their
|
||||
communications.
|
||||
|
||||
#### Additional Note on Subkey Algorithm Types
|
||||
|
||||
Subkeys in GpgFrontend offer more algorithm types than primary keys due to their
|
||||
specialized roles. While primary keys focus on establishing identity and trust,
|
||||
subkeys are often dedicated to specific tasks like encryption or authentication.
|
||||
This task-specific design allows subkeys to utilize a broader range of
|
||||
algorithms, enhancing their flexibility and functionality. For instance, while
|
||||
primary keys may be restricted to certain secure algorithms for signing, subkeys
|
||||
can employ diverse algorithms optimized for encryption, like ECDH, ensuring
|
||||
efficient and secure operations tailored to the user's needs.
|
||||
|
||||
For more Details: [Comparison of Cryptographic Algorithms](/extra/algorithms-comparison)
|
||||
|
||||
**Primary Key Supported Algorithms:**
|
||||
## Primary Key Supported Algorithms
|
||||
|
||||
- RSA
|
||||
- DSA
|
||||
- ECDSA ED25519
|
||||
- EdDSA ED448 (GnuPG >2.3.0)
|
||||
- ECDSA SECP256K1 (GnuPG >2.3.0)
|
||||
- ECDSA NIST P-256
|
||||
- ECDSA NIST P-384
|
||||
- ECDSA NIST P-521
|
||||
- ECDSA BrainPool P-256 (GnuPG >2.3.0)
|
||||
- ECDSA BrainPool P-384 (GnuPG >2.3.0)
|
||||
- ECDSA BrainPool P-512 (GnuPG >2.3.0)
|
||||
|
||||
**Subkey Supported Algorithms:**
|
||||
|
||||
- RSA
|
||||
- DSA
|
||||
- ELG-E
|
||||
- ECDSA ED25519
|
||||
- ECDSA ED448 (GnuPG >2.3.0)
|
||||
- ECDH CV25519
|
||||
- ECDH X448 (GnuPG >2.3.0)
|
||||
- ECDH NIST P-256
|
||||
- ECDH NIST P-384
|
||||
- ECDH NIST P-521
|
||||
- ECDH BrainPool P-256 (GnuPG >2.3.0)
|
||||
- ECDH BrainPool P-384 (GnuPG >2.3.0)
|
||||
- ECDH BrainPool P-512 (GnuPG >2.3.0)
|
||||
|
||||
**Explanation:**
|
||||
|
||||
The broader range of algorithms available for subkeys arises because subkeys are
|
||||
designed for specific functions and can therefore leverage specialized
|
||||
algorithms optimized for those functions. For example, ECDH (Elliptic Curve
|
||||
Diffie-Hellman) is highly efficient for encryption tasks and is commonly used
|
||||
for subkeys dedicated to encryption. This flexibility in algorithm choice
|
||||
ensures that cryptographic operations can be optimized for both performance and
|
||||
security based on the specific use case.
|
||||
|
||||
Primary keys, however, are central to the user's cryptographic identity and are
|
||||
primarily used for signing and certifying subkeys. This critical role
|
||||
necessitates the use of well-established and highly secure algorithms to ensure
|
||||
the integrity and trustworthiness of the entire cryptographic system.
|
||||
|
||||
By differentiating the algorithms and roles of primary keys and subkeys,
|
||||
GpgFrontend enhances both security and operational efficiency, allowing users to
|
||||
maintain a robust and flexible cryptographic setup.
|
||||
|
||||
260
src/content/docs/guides/generate-use-subkey.md
Normal file
260
src/content/docs/guides/generate-use-subkey.md
Normal file
@ -0,0 +1,260 @@
|
||||
---
|
||||
title: Generate and Use Subkey
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
GpgFrontend provides comprehensive support for subkeys, allowing users to
|
||||
enhance security and flexibility through proper key management.
|
||||
|
||||
## Steps to Generate a Subkey
|
||||
|
||||
|
||||
|
||||
1. **Open Key Management**:
|
||||
|
||||
- In the Key Management interface, right-click on the key pair you wish to
|
||||
add a subkey to. Select the "New Subkey" option from the context menu.
|
||||
|
||||
2. **Fill in Basic Information**:
|
||||
|
||||
- **Key Type**: Select the type of subkey you want to generate. Available
|
||||
options include RSA, DSA, ECDSA, ECDH, ECDH NIST P-256, ECDH NIST P-384,
|
||||
ECDH NIST P-521, ECDH BrainPool P-256, ECDH BrainPool P-384, and ECDH
|
||||
BrainPool P-512.
|
||||
- **Key Size**: Choose the key size. This option is only applicable when the
|
||||
key type is RSA or DSA.
|
||||
- **Expiration Date**: Set an expiration date for the subkey. You can also
|
||||
choose to check the "Never expire" checkbox to make the subkey permanent.
|
||||
|
||||
3. **Set a Passphrase**:
|
||||
|
||||
- If the primary key has a passphrase, the subkey's passphrase must be equal
|
||||
to it. Ensure that the "Non Pass Phrase" checkbox is unchecked if you want
|
||||
to set a passphrase.
|
||||
|
||||
4. **Select Key Usage**:
|
||||
|
||||
- Specify the usage for the subkey. Options include:
|
||||
- **Encryption**: For encrypting data.
|
||||
- **Signing**: For creating digital signatures.
|
||||
- **Authentication**: For authentication purposes, such as SSH keys.
|
||||
- Note that the certification usage is not available for subkeys.
|
||||
|
||||
5. **Generate the Subkey**:
|
||||
- After filling in all the necessary information and selecting the desired
|
||||
options, click the "OK" button to generate your subkey.
|
||||
|
||||
By following these steps, you can generate a subkey using GpgFrontend, which
|
||||
enhances the functionality of your primary key pair for various cryptographic
|
||||
operations.
|
||||
|
||||
## Understanding Primary Keys and Subkeys
|
||||
|
||||
In the realm of cryptography, key management plays a crucial role in ensuring
|
||||
data security. A key pair consists of a primary key and one or more subkeys,
|
||||
each serving distinct functions yet working together to secure and manage
|
||||
digital identities and communications. This structure not only enhances security
|
||||
but also provides flexibility in key usage and management.
|
||||
|
||||
### The Role of Primary Key and Subkeys
|
||||
|
||||
- **Primary Key**: The primary key is the cornerstone of your cryptographic
|
||||
identity. It is used for identity verification, which includes signing other
|
||||
keys to establish trust. The primary key's signature on a subkey validates the
|
||||
subkey's association with the identity of the primary key holder.
|
||||
|
||||
- **Subkeys**: Subkeys are associated with the primary key and are used for
|
||||
encryption and signing documents or messages. Subkeys can be thought of as
|
||||
extensions of the primary key, each designated for specific tasks. This
|
||||
separation of duties allows for greater security and operational flexibility.
|
||||
For example, you can have separate subkeys for signing and encryption.
|
||||
|
||||
### Advantages of Using Subkeys
|
||||
|
||||
1. **Enhanced Security**: By using subkeys for day-to-day operations, you
|
||||
minimize the risk associated with key exposure. If a subkey is compromised,
|
||||
it can be revoked without affecting the primary key or other subkeys, thereby
|
||||
limiting the potential damage.
|
||||
|
||||
2. **Operational Flexibility**: Subkeys allow for specific roles (e.g., signing,
|
||||
encryption) to be isolated. This means you can renew or revoke subkeys as
|
||||
needed without disrupting the overall cryptographic setup.
|
||||
|
||||
3. **Convenient Key Rotation**: Regularly updating keys is a best practice in
|
||||
cryptography. Subkeys make it easier to rotate keys for signing and
|
||||
encryption without needing to re-establish the primary key's trust
|
||||
relationships.
|
||||
|
||||
## Best Practices for Using Subkeys
|
||||
|
||||
After understanding the concepts discussed above, you might be wondering how
|
||||
exactly you can effectively use subkeys to maximize their advantages. In
|
||||
principle, the main goal is to separate the subkey from the primary key to
|
||||
leverage better security. If your subkeys are always kept together with the
|
||||
primary key, you will always need to use the complete set of keys, increasing
|
||||
the risk of compromising the primary key. GpgFrontend supports the export of
|
||||
individual subkeys, as well as the configuration of multiple key databases.
|
||||
Using these features together, you can easily isolate a particular subkey,
|
||||
export it, and import it into another key database. This allows you to secure
|
||||
the primary key separately, even removing it from the original key database to
|
||||
reduce exposure. For high-security environments, it is recommended that:
|
||||
|
||||
> "The primary key should be stored in a highly secure location, preferably
|
||||
> offline or in a hardware security module (HSM), to prevent unauthorized
|
||||
> access. The loss or compromise of the primary key jeopardizes the entire
|
||||
> cryptographic framework."
|
||||
|
||||
### Step-by-Step Guide to Exporting Subkeys
|
||||
|
||||
To demonstrate how to export an individual subkey, let's refer to the screenshot
|
||||
provided. Below is a step-by-step guide to navigate the GpgFrontend interface
|
||||
and successfully export a subkey:
|
||||
|
||||
1. **Open Key Details View**: Open the GpgFrontend application and navigate to
|
||||
the key database section. Select the desired key from the list to open the
|
||||
**Key Details** view.
|
||||
|
||||
2. **Access the Keychain Tab**: Click on the **Keychain** tab within the Key
|
||||
Details window. Here, you will be able to see a list of all keys associated
|
||||
with your selected primary key. The list includes the primary key itself,
|
||||
which is displayed in the first row, as well as any subkeys.
|
||||
|
||||
3. **Select a Subkey**: Locate and click on the subkey you wish to export. Once
|
||||
selected, details about the subkey will appear in the lower half of the
|
||||
window, providing information such as **Key ID**, **Algorithm**, **Key
|
||||
Size**, and **Usage**.
|
||||
|
||||
4. **Export the Subkey**: On the right side of the key details section, there is
|
||||
an **Export Subkey** button, highlighted in the screenshot. Click this button
|
||||
to start the export process.
|
||||
|
||||
5. **Save the Subkey File**: A file dialog will appear, prompting you to specify
|
||||
a location to save the exported subkey. Choose a secure directory and save
|
||||
the subkey as a separate file.
|
||||
|
||||
|
||||
|
||||
### Step-by-Step Guide to Importing Subkeys
|
||||
|
||||
To demonstrate how to import an individual subkey that has been previously
|
||||
exported, let's refer to the screenshots provided. Below is a step-by-step guide
|
||||
to navigate the GpgFrontend interface and successfully import a subkey:
|
||||
|
||||
1. **Select the Key Database**: Choose the appropriate key database from the **Key Toolbox**.
|
||||
|
||||
|
||||
|
||||
1. **Import the Subkey**: Click on the **Import Key** button in the top toolbar,
|
||||
and select **File** from the dropdown menu. This action will open a dialog
|
||||
where you can browse your system to locate the previously exported subkey
|
||||
file.
|
||||
|
||||
|
||||
|
||||
2. **Select Subkey File**: Browse to the location where the subkey file is
|
||||
saved, select it, and click **Open**. This will import the subkey into the
|
||||
selected key database.
|
||||
|
||||
3. **Verify Imported Subkey**: After importing the subkey, locate it in the
|
||||
**Key Toolbox** list. Click on the subkey to open its **Key Details** view.
|
||||
You should see all relevant information about the subkey, including **Key
|
||||
ID**, **Algorithm**, **Key Size**, and **Usage**.
|
||||
|
||||
4. **Handling Primary Key**:You can now move your master key to a safe place. Then delete it at
|
||||
GpgFrontend.
|
||||
|
||||
|
||||
|
||||
### Confirming Primary Key Absence
|
||||
|
||||
In the **Key Toolbox**, you may notice that some keys have a `#` symbol next to
|
||||
their **Type** (e.g., **pub/sec#**). This symbol indicates that the primary key
|
||||
for this subkey does not exist in the current key database. This is expected if
|
||||
you have securely removed the primary key to minimize exposure, while retaining
|
||||
the subkeys for ongoing operations.
|
||||
|
||||
|
||||
|
||||
You can confirm the absence of the primary key by opening the **Key Details**
|
||||
view of the imported subkey. In the **Primary Key Existence** section, it should
|
||||
indicate **Not Exists**. This ensures that the primary key is not present, which
|
||||
enhances the overall security of your cryptographic setup.
|
||||
|
||||
## Key Functionality Without a Primary Key
|
||||
|
||||
When a primary key is absent from the key database, certain limitations apply.
|
||||
You can confirm the absence of the primary key by checking the **Primary Key
|
||||
Existence** section in the Key Details view, which will display **Not Exists**.
|
||||
This setup is intentional in many cases to improve security by isolating the
|
||||
primary key.
|
||||
|
||||
|
||||
|
||||
### Actions Limited by the Absence of a Primary Key:
|
||||
|
||||
1. **Creating New Subkeys**: The absence of the primary key prevents the
|
||||
generation of additional subkeys.
|
||||
2. **Adding UID**: You cannot attach new User IDs (UIDs) to the keyset without
|
||||
the primary key.
|
||||
3. **Key Certification**: Signing other keys to certify them as trusted is only
|
||||
possible with a primary key.
|
||||
4. **Key Revocation**: Generating a revocation certificate for the subkey or
|
||||
primary key is impossible without the primary key.
|
||||
|
||||
### Practical Example: Subkey-Only Use Case
|
||||
|
||||
In scenarios where only the subkey remains, as depicted in the screenshot:
|
||||
|
||||
- The subkey can be actively used for encryption purposes (e.g., encrypting
|
||||
emails or files).
|
||||
- Since no subkey capable of signing exists, you cannot digitally sign data. To
|
||||
address this, it is advisable to generate a signing-capable subkey during the
|
||||
initial key creation process.
|
||||
|
||||
This setup is particularly beneficial for environments where the exposure of the
|
||||
primary key poses a security risk. By isolating the primary key and relying
|
||||
solely on subkeys, you can maintain a balance between functionality and
|
||||
security.
|
||||
|
||||
|
||||
|
||||
### Tips for Secure Usage:
|
||||
|
||||
1. **Inspect Subkey Capabilities**: Always verify what operations a subkey can
|
||||
perform by reviewing its **Usage** field.
|
||||
2. **Plan Subkey Generation**: At the time of key creation, consider creating
|
||||
multiple subkeys with distinct purposes (e.g., signing, encryption,
|
||||
authentication).
|
||||
3. **Backup Primary Key Securely**: Store the primary key in an offline, highly
|
||||
secure location to allow recovery or advanced operations if needed.
|
||||
|
||||
### Additional Note on Subkey Algorithm Types
|
||||
|
||||
Subkeys in GpgFrontend offer more algorithm types than primary keys due to their
|
||||
specialized roles. While primary keys focus on establishing identity and trust,
|
||||
subkeys are often dedicated to specific tasks like encryption or authentication.
|
||||
This task-specific design allows subkeys to utilize a broader range of
|
||||
algorithms, enhancing their flexibility and functionality. For instance, while
|
||||
primary keys may be restricted to certain secure algorithms for signing, subkeys
|
||||
can employ diverse algorithms optimized for encryption, like ECDH, ensuring
|
||||
efficient and secure operations tailored to the user's needs.
|
||||
|
||||
For more Details: [Comparison of Cryptographic Algorithms](/extra/algorithms-comparison)
|
||||
|
||||
**Subkey Supported Algorithms:**
|
||||
|
||||
- RSA
|
||||
- DSA
|
||||
- ELG-E
|
||||
- ECDSA ED25519
|
||||
- ECDSA ED448 (GnuPG >2.3.0)
|
||||
- ECDH CV25519
|
||||
- ECDH SECP256K1 (GnuPG >2.3.0)
|
||||
- ECDH X448 (GnuPG >2.3.0)
|
||||
- ECDH NIST P-256
|
||||
- ECDH NIST P-384
|
||||
- ECDH NIST P-521
|
||||
- ECDH BrainPool P-256 (GnuPG >2.3.0)
|
||||
- ECDH BrainPool P-384 (GnuPG >2.3.0)
|
||||
- ECDH BrainPool P-512 (GnuPG >2.3.0)
|
||||
@ -45,16 +45,6 @@ challenge of securely exchanging the password between the sender and receiver
|
||||
cannot be understated. If this password is intercepted or guessed by an
|
||||
unauthorized party, the encrypted data's security is compromised.
|
||||
|
||||
In summary, GpgFrontend's support for symmetric encryption provides a powerful
|
||||
tool for users needing to secure their data with a password. This method is
|
||||
distinguished by its reliance on a single password for both encryption and
|
||||
decryption, offering a balance between simplicity and security. Users must
|
||||
exercise caution in creating a strong password and ensure its secure exchange to
|
||||
maintain the confidentiality and integrity of their encrypted data. Symmetric
|
||||
encryption with GpgFrontend is a testament to the versatility of cryptographic
|
||||
practices, catering to a wide range of security needs with user-friendly
|
||||
solutions.
|
||||
|
||||
## How to Perform Symmetric Encryption
|
||||
|
||||
Performing symmetric encryption with GpgFrontend is a straightforward process.
|
||||
|
||||
@ -4,186 +4,100 @@ sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
As a beginner, you're only required to swiftly comprehend a few crucial sections
|
||||
of the page. The exploration that follows will gradually unveil additional
|
||||
functionalities. Bear in mind that interfaces may vary across different
|
||||
versions.
|
||||
This documentation explains the interface and functionality of GpgFrontend,
|
||||
based on the latest UI design. It is intended to guide users through its
|
||||
features effectively.
|
||||
|
||||
|
||||
|
||||
|
||||
## Text Editor
|
||||
## Text Editing Zone
|
||||
|
||||
The text editing zone allows you the liberty to input any desired text or
|
||||
establish a new tab through the "New" option in the file menu at the top. Moving
|
||||
or closing tabs can be done with ease as per your needs.
|
||||
The **Text Editing Zone** allows users to input any desired text or work on
|
||||
existing files. You can open a new tab using the **"New"** or **"New E-Mail"**
|
||||
button or load an existing file with **"Open"** from the menu bar.
|
||||
|
||||
Numerous operations can be performed on your text using options available in the
|
||||
Operations Bar at the top of the interface. You can encrypt, decrypt, sign, and
|
||||
verify text directly from this menu. Additionally, standard shortcuts like
|
||||
Ctrl+C, Ctrl+V, and Ctrl+S for copy, paste, and save operations, or searching
|
||||
within the text using Ctrl+F, are supported.
|
||||
### Key Features:
|
||||
|
||||
The edited text within the text box is encoded in UTF-8 without any formatting.
|
||||
This plain text format ensures that no message alteration leads to confusion.
|
||||
While there are plans to introduce rich text editing in the future, the
|
||||
specifics are still being deliberated.
|
||||
- **Operations Bar**: Located at the top, it provides options to encrypt,
|
||||
decrypt, sign, and verify text directly.
|
||||
- **Standard Shortcuts**: Supports basic shortcuts like **Ctrl+C**, **Ctrl+V**,
|
||||
and **Ctrl+S** for copying, pasting, and saving text.
|
||||
- **Plain Text Format**: Text is encoded in UTF-8 without formatting to ensure
|
||||
clarity and compatibility. Future plans may include rich text editing.
|
||||
|
||||
### Large Text File Support
|
||||
#### Large Text File Support
|
||||
|
||||
GpgFrontend accommodates opening larger files without hindrance, with the
|
||||
current limit set to 1MB per file. When dealing with relatively large files,
|
||||
editing of the tab won't be feasible until the entire file is loaded. During
|
||||
this time, despite not being able to edit the file, you still have the
|
||||
capability to view it.
|
||||
- Files up to **1MB** are supported. Larger files may cause performance issues
|
||||
and are not recommended.
|
||||
- While loading large files, editing will be temporarily disabled until the
|
||||
entire file is processed.
|
||||
|
||||
It is important to note that opening files larger than 1MB is not supported, as
|
||||
excessively long text files can cause significant performance issues with the
|
||||
graphical user interface (GUI). This limitation helps maintain the application's
|
||||
responsiveness and ensures a smooth user experience.
|
||||
## Information Panel
|
||||
|
||||
## Information Board
|
||||
The **Information Panel** displays the results of current operations (e.g.,
|
||||
encryption, decryption, signing) and their status, such as success or failure.
|
||||
It provides helpful details about the operation, such as timestamps, key IDs,
|
||||
and algorithms used.
|
||||
|
||||
GpgFrontend presents the outcome of the current tab page operation on the
|
||||
Information Board, signifying the success or failure of the operation. The
|
||||
Information Board's text includes supplementary details to assist in
|
||||
understanding the particulars of your encryption, decryption, signature, and
|
||||
other operations. Depending on your language settings, the output displayed on
|
||||
the dashboard may differ.
|
||||
### Color Coding for Status
|
||||
|
||||
The Information Board was conceived to provide a comprehensive view of more
|
||||
information within the same space. However, GpgFrontend plans to incorporate a
|
||||
graphical interface in the future to augment the user's comprehension of this
|
||||
information.
|
||||
|
||||
### Color Coding
|
||||
|
||||
- **Green**: Indicates a successful operation that has been thoroughly verified
|
||||
and found devoid of any issues. The appearance of green font color signifies
|
||||
an all-clear.
|
||||
- **Yellow**: Denotes a successful operation with some potential issues detected
|
||||
during result testing. The yellow font color serves as a subtle alert for the
|
||||
user, necessitating a detailed review of the operation.
|
||||
- **Red**: Symbolizes an unsuccessful operation or a significant discrepancy in
|
||||
the operation's outcome. The red font color acts as a clear warning, demanding
|
||||
the user to meticulously inspect the operation's specifics to ensure security.
|
||||
|
||||
### Customizable Font Size
|
||||
|
||||
Should you find the font size on the information board to be diminutive, you can
|
||||
easily adjust it under the 'Application' section in the settings. The default
|
||||
font size is 10, and it can be modified to any value ranging from 9 to 18.
|
||||
- **Green**: Indicates a successful operation with no issues.
|
||||
- **Yellow**: Suggests a successful operation but with potential warnings.
|
||||
- **Red**: Signifies an unsuccessful operation or critical errors.
|
||||
|
||||
### Dashboard Actions Menu
|
||||
|
||||
The dashboard actions menu, located below the Information Board, provides quick
|
||||
and easy access to essential functions related to the content displayed. It
|
||||
empowers users to efficiently manage and process large chunks of information for
|
||||
various purposes.
|
||||
|
||||
#### Copy
|
||||
|
||||
This function allows users to swiftly capture significant portions of content
|
||||
from the Information Board for use in other applications. Simply select the
|
||||
content you need and use this button to copy it to the clipboard.
|
||||
|
||||
#### Save File
|
||||
|
||||
This operation archives the contents of the Information Board into the file
|
||||
system in UTF-8 format. Although the resultant output file does not have a
|
||||
suffix, it is essentially plain text and can be opened with any text editor.
|
||||
|
||||
#### Clear
|
||||
|
||||
This command promptly purges all content from the Information Board, including
|
||||
both the displayed contents and statuses. Any new operation, such as encryption
|
||||
or decryption, will automatically trigger this clearing process, ensuring that
|
||||
the Information Board always displays the most current and relevant information.
|
||||
- **Copy**: Copies content from the Information Panel to the clipboard.
|
||||
- **Save File**: Saves the Information Panel's content as a plain text file
|
||||
(UTF-8).
|
||||
- **Clear**: Clears all content from the Information Panel, resetting it for the
|
||||
next operation.
|
||||
|
||||
## Key Toolbox
|
||||
|
||||
The Key Toolbox on the right side of the interface lists all available keys,
|
||||
including public and private keys. The columns provide details such as key type,
|
||||
name, and email address. You can select keys from this list to perform various
|
||||
operations such as encryption, decryption, signing, and verification.
|
||||
The **Key Toolbox**, located on the right side of the interface, lists all
|
||||
available keys. It provides details such as key type, name, email address, and
|
||||
usage. Users can select keys for specific operations by ticking the boxes in the
|
||||
first column.
|
||||
|
||||
### Usage
|
||||
### Key Details
|
||||
|
||||
Most Gpg-related operations require specifying a key pair (for tasks like
|
||||
encryption, decryption, signature, etc.). You can select the checkbox in the
|
||||
first column of the Key Toolbox's table to designate one or more keys for your
|
||||
operation. Categories that contain only public keys are frequently utilized in
|
||||
cryptographic scenarios.
|
||||
- **Type**:
|
||||
- `pub`: Public key (for encryption or verification).
|
||||
- `pub/sec`: Key pair with both public and private keys.
|
||||
- `pub/sec#`: Key pair with missing primary key.
|
||||
- `pub/sec^`: Key pair with components stored on a smart card.
|
||||
- **Email Address**: Shows the email associated with each key.
|
||||
- **Usage**: Indicates key functionality with codes:
|
||||
- `C`: Certification.
|
||||
- `E`: Encryption.
|
||||
- `S`: Signing.
|
||||
- `A`: Authentication.
|
||||
|
||||
### Classification
|
||||
### Categories
|
||||
|
||||
The Toolbox showcases categories via tabbed display. None of these categories
|
||||
include any expired or revoked keys. To view such keys, you should refer to the
|
||||
Key Manager. The default category comprises all private and public keys. During
|
||||
any operation, only the keys from the currently selected category will be
|
||||
considered for input.
|
||||
|
||||
### Columns
|
||||
|
||||
Understanding this list is crucial. Let's walk through its components step by
|
||||
step.
|
||||
|
||||
- **Select**: Check the box in this column to notify GpgFrontend that you wish
|
||||
to use the key from this row for your subsequent operation.
|
||||
|
||||
- **Type**: This column informs you about the key type and whether the primary
|
||||
key exists in your key pair.
|
||||
|
||||
- `pub` signifies that it is a public key, which can be used for encryption or
|
||||
verification operations.
|
||||
- `pub/sec` indicates that the key pair contains both public and private keys.
|
||||
It can be employed for nearly all operations (consult the 'Usage' column to
|
||||
confirm this).
|
||||
- `pub/sec#` shows that the key pair has a public key and a private key, but
|
||||
the primary key is absent from the key pair. This suggests you won't be able
|
||||
to perform certain specific operations (like adding subkeys, signing other
|
||||
key pairs, etc.)
|
||||
- `pub/sec^` implies that one or more keys (subkeys or master keys) from the
|
||||
key pair are in the smart card.
|
||||
- `pub/sec#^` denotes a simultaneous occurrence of the previous two
|
||||
situations.
|
||||
|
||||
- **Name**: Represents the identity information of the key pair.
|
||||
- **Email Address**: Also denotes the identity information of the key pair.
|
||||
- **Usage**: Determines which operations the key pair can execute. Composed of
|
||||
four uppercase letters, each letter signifies a specific use.
|
||||
|
||||
- `C` stands for Certificate. Key pairs containing the primary key generally
|
||||
have this usage.
|
||||
- `E` stands for Encrypt. The key pair can be used for encryption operations.
|
||||
- `S` stands for Sign. The key pair can be used for signing operations.
|
||||
- `A` stands for Authenticate. The key pair can be used to perform operations
|
||||
like SSH authentication.
|
||||
|
||||
- **Validity**: A Gpg concept that roughly represents the level of trust in this
|
||||
key.
|
||||
The toolbox categorizes keys by type (e.g., public or private) using tabs.
|
||||
Expired or revoked keys are not displayed by default and can be viewed in
|
||||
**Manage Keys**.
|
||||
|
||||
## Operations Bar
|
||||
|
||||
The Operations Bar at the top includes the following functions:
|
||||
The **Operations Bar**, at the top of the interface, provides quick access to
|
||||
all core functionalities:
|
||||
|
||||
1. New: Create a new text file tab.
|
||||
2. Open: Open an existing text file.
|
||||
3. File Browser: Browse and select files from your system.
|
||||
4. Encrypt: Encrypt the text or file.
|
||||
5. Encrypt Sign: Encrypt and sign the text or file.
|
||||
6. Decrypt: Decrypt the text or file.
|
||||
7. Decrypt Verify: Decrypt and verify the text or file.
|
||||
8. Sign: Sign the text or file.
|
||||
9. Verify: Verify the signature of the text or file.
|
||||
10. Manage Keys: Open the key management interface.
|
||||
11. Import Key: Import a new key through some approaches.
|
||||
|
||||
This interface provides a comprehensive suite of tools for managing and
|
||||
utilizing your cryptographic keys and performing various encryption-related
|
||||
operations with ease.
|
||||
1. **New E-Mail**: Create a new email or text file.
|
||||
2. **Open**: Open an existing text file.
|
||||
3. **File Browser**: Browse and select files from your system.
|
||||
4. **Encrypt**: Encrypt text or files using selected keys.
|
||||
5. **Encrypt Sign**: Encrypt and sign text or files simultaneously.
|
||||
6. **Decrypt**: Decrypt text or files.
|
||||
7. **Decrypt Verify**: Decrypt and verify signed files.
|
||||
8. **Sign**: Digitally sign text or files.
|
||||
9. **Verify**: Verify the signature of text or files.
|
||||
10. **Manage Keys**: Access the key management interface.
|
||||
11. **Import Key**: Import keys into your keyring.
|
||||
|
||||
### Customization
|
||||
|
||||
For operations that you may not use for a while, you have the option to uncheck
|
||||
the associated function group in the top menu view. Conversely, for the
|
||||
operations you frequently use, you have the ability to add them here.
|
||||
You can hide unused functions or add frequently used ones via the view settings
|
||||
menu in the application.
|
||||
|
||||
@ -12,7 +12,7 @@ encryption, decryption, and digital signing, offering a seamless interface for
|
||||
managing OpenPGP tasks. Embrace the latest features of GnuPG 2.x, enhancing your
|
||||
security in the digital age.
|
||||
|
||||
**Document Version Reference: [v2.1.4](https://github.com/saturneric/GpgFrontend/releases/tag/v2.1.4)**
|
||||
**Document Version Reference: [v2.1.6](https://github.com/saturneric/GpgFrontend/releases/tag/v2.1.6)**
|
||||
|
||||
## User Interface Glimpse
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user