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
|
#### Key Fingerprint
|
||||||
|
|
||||||
```
|
```
|
||||||
E3379489C39B7270E70E2E303AAF1C64137CEE57
|
12F7E8858CF15BEC9975FF3C5CA3DA246843FD03
|
||||||
```
|
```
|
||||||
|
|
||||||
#### Public Key (OpenPGP)
|
#### Public Key (OpenPGP)
|
||||||
@ -71,86 +71,13 @@ E3379489C39B7270E70E2E303AAF1C64137CEE57
|
|||||||
```
|
```
|
||||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||||
|
|
||||||
mQGNBGCVnvEBDACuEcjxckb4rocHGU7VPT/OOOOZapNG/0ViB3XhmzNh7q8QJiq6
|
mDMEZsEF1xYJKwYBBAHaRw8BAQdAPZ3dA2od9HFaiaJRr1TEEeRMfAcrBp8oqQPa
|
||||||
M4z0fpC5sf1pHXbbKtehLETrAUTFuaEp19askZI0ISoz5+qKGZuaM3bDZWBjwUpt
|
R16Icva0OHNhdHVybmVyaWMoZm9yIGNvZGUgb3IgYmluYXJ5IHNpZ24gb25seSk8
|
||||||
woVgUphfeZy2DFsnmTtVj9CRU9Nma6smXVFud3Roj2ImZ0NFrkdETvprfLJ7jqk/
|
ZXJpY0Bia3R1cy5jb20+iJkEExYKAEEWIQQS9+iFjPFb7Jl1/zxco9okaEP9AwUC
|
||||||
mXgznNbbJdqmQ4l0I1E91VmrqHHHSakh3grzRDj/GuDookQl2JZfLA0J55qOYdkF
|
ZsEF1wIbIwUJA8JmbgULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRBco9ok
|
||||||
5mmnqbYURGVcP2oot/wSrrWH0F/WatwRx9w+jZjrJWgKjJoqWwvzG8WGop1XkRn1
|
aEP9A3TTAQC/H61IVj6LiSQ0dvodo5VFb2jTJa8XVfb2NT3yc/+JDwD+KTm+nV73
|
||||||
Ea3Nzj/KsSL7C5YRu03BL7wNu6UNIJ/zsAnNLp87nCY85w+HnNGHkL3QcnqNQbQP
|
dbaEG0FOTKu+n4rVhBpTes93Bn2GcRSbQwA=
|
||||||
3aySOkIjXdT8AlGIV5r5wO/RBg4e+xASGzQXx9lYbjJiiIOP2uLxYGGFbalDoiCa
|
=fWZe
|
||||||
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
|
|
||||||
-----END PGP PUBLIC KEY BLOCK-----
|
-----END PGP PUBLIC KEY BLOCK-----
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|||||||
@ -51,13 +51,14 @@ dependencies:
|
|||||||
This variant ensures compatibility with earlier Windows environments,
|
This variant ensures compatibility with earlier Windows environments,
|
||||||
extending the tool's accessibility and usability.
|
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
|
cryptographic operations, including encryption, decryption, and digital
|
||||||
signing. GnuPG (version 2.2.0 or newer) is a necessary component to leverage
|
signing. While GpgFrontend supports GnuPG version 2.1.0 or newer, some
|
||||||
the full capabilities of GpgFrontend. Please note, GnuPG 1.x versions are not
|
features may not be fully functional with versions below 2.4.0. For the best
|
||||||
supported by GpgFrontend due to differences in functionality and support.
|
compatibility and to ensure access to all features, it is strongly recommended
|
||||||
Users are encouraged to use GnuPG 2.x to ensure compatibility and secure
|
to use GnuPG 2.4.0 or higher. Please note that GnuPG 1.x versions are not
|
||||||
operations.
|
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
|
By catering to a wide range of operating systems and ensuring backward
|
||||||
compatibility with older Windows versions through Qt5 support, GpgFrontend
|
compatibility with older Windows versions through Qt5 support, GpgFrontend
|
||||||
|
|||||||
@ -6,7 +6,8 @@ sidebar:
|
|||||||
|
|
||||||
When choosing cryptographic algorithms for key management and data security,
|
When choosing cryptographic algorithms for key management and data security,
|
||||||
it's important to understand the differences and use cases for RSA, DSA, ECDSA,
|
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)
|
## 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
|
- **Security**: Provides strong security, but larger key sizes are required as
|
||||||
computational power increases.
|
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)
|
## ElGamal Encryption (ELG-E)
|
||||||
|
|
||||||
- **Key Characteristics**: ElGamal encryption (ELG-E) is an asymmetric key
|
- **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
|
### Common ECC Algorithms and Their Use Cases
|
||||||
|
|
||||||
- **NIST Curves (P-256, P-384, P-521)**: These curves, standardized by the
|
Elliptic Curve Cryptography (ECC) offers a range of algorithms and curves
|
||||||
National Institute of Standards and Technology (NIST), are widely used in
|
tailored to different cryptographic needs. Below is an overview of commonly used
|
||||||
secure communication protocols. For example, **ECDH NIST P-256** provides
|
ECC algorithms and their specific applications.
|
||||||
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.
|
|
||||||
|
|
||||||
- **ED25519 and ED448**: **ED25519** is favored for its speed and security,
|
- **NIST Curves (P-256, P-384, P-521)**: Standardized by the National Institute
|
||||||
providing 128-bit security and commonly used in modern applications like
|
of Standards and Technology (NIST), these curves are widely utilized in secure
|
||||||
secure messaging (e.g., Signal) and blockchain technologies. **ECDSA ED25519**
|
communication protocols. For example:
|
||||||
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.
|
|
||||||
|
|
||||||
- **BrainPool Curves (P-256, P-384, P-512)**: These curves are alternatives to
|
- **ECDH NIST P-256**: Provides approximately 128-bit security, making it
|
||||||
the NIST standards, offering similar security levels but with different
|
suitable for most encryption scenarios.
|
||||||
parameters. **ECDH BrainPool P-256** and **ECDSA BrainPool P-256** are used
|
- **ECDSA NIST P-256**: Commonly employed for digital signatures, offering
|
||||||
when there is a preference for non-NIST curves, especially in regions or
|
robust security for authentication purposes.
|
||||||
industries where alternative cryptographic standards are required. The
|
- **Higher Key Sizes**: P-384 and P-521 increase security levels
|
||||||
BrainPool curves maintain the balance between security and performance across
|
proportionally, with P-521 offering around 256-bit security, making it ideal
|
||||||
different key sizes.
|
for high-security environments.
|
||||||
|
|
||||||
- **CV25519 and X448**: **ECDH CV25519** is a counterpart to ED25519 but is used
|
- **BrainPool Curves (P-256, P-384, P-512)**: BrainPool curves serve as
|
||||||
specifically for key exchange. It provides approximately 128-bit security and
|
alternatives to NIST standards, providing similar security levels but with
|
||||||
is widely used for its efficiency in secure communications. **ECDH X448** is
|
independently developed parameters.
|
||||||
the higher-security variant (224-bit security) and is appropriate for
|
|
||||||
scenarios demanding more robust encryption, albeit with higher computational
|
|
||||||
costs.
|
|
||||||
|
|
||||||
## 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
|
- **CV25519 and X448**: These curves are optimized for performance and are
|
||||||
role in establishing trust and signing other keys. These algorithms are
|
widely used in modern cryptographic applications.
|
||||||
well-established and extensively audited, providing robust security for identity
|
|
||||||
verification.
|
|
||||||
|
|
||||||
Subkeys, however, are often used for specific operational tasks such as
|
- **ECDH CV25519**: A counterpart to ED25519, this curve is designed for key
|
||||||
encryption and authentication. This allows them to utilize a broader range of
|
exchange and offers approximately 128-bit security. It is highly efficient
|
||||||
algorithms like ECDH, which is optimized for key exchange. The flexibility in
|
in secure communications.
|
||||||
choosing algorithms for subkeys enhances their efficiency and allows
|
- **ECDH X448**: A higher-security variant providing 224-bit security,
|
||||||
cryptographic operations to be tailored to specific use cases, providing both
|
suitable for applications requiring more robust encryption. However, it
|
||||||
performance and security benefits.
|
comes with a slight trade-off in computational efficiency.
|
||||||
|
|
||||||
By understanding the strengths and appropriate use cases for each algorithm, you
|
- **SECP256K1**: Defined by the Standards for Efficient Cryptography Group
|
||||||
can choose the best cryptographic solution for your needs, ensuring both
|
(SECG), SECP256K1 is distinct from NIST curves and has gained significant
|
||||||
security and efficiency in your operations.
|
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:
|
sidebar:
|
||||||
order: 3
|
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,
|
By following these steps, you can generate a secure key pair using GpgFrontend,
|
||||||
tailored to your specific needs for encryption, signing, and authentication.
|
tailored to your specific needs for encryption, signing, and authentication.
|
||||||
|
|
||||||
## Steps to Generate a Subkey
|
## Primary Key Supported Algorithms
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
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:**
|
|
||||||
|
|
||||||
- RSA
|
- RSA
|
||||||
- DSA
|
- DSA
|
||||||
- ECDSA ED25519
|
- ECDSA ED25519
|
||||||
|
- EdDSA ED448 (GnuPG >2.3.0)
|
||||||
|
- ECDSA SECP256K1 (GnuPG >2.3.0)
|
||||||
- ECDSA NIST P-256
|
- ECDSA NIST P-256
|
||||||
- ECDSA NIST P-384
|
- ECDSA NIST P-384
|
||||||
- ECDSA NIST P-521
|
- ECDSA NIST P-521
|
||||||
- ECDSA BrainPool P-256 (GnuPG >2.3.0)
|
- ECDSA BrainPool P-256 (GnuPG >2.3.0)
|
||||||
- ECDSA BrainPool P-384 (GnuPG >2.3.0)
|
- ECDSA BrainPool P-384 (GnuPG >2.3.0)
|
||||||
- ECDSA BrainPool P-512 (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
|
cannot be understated. If this password is intercepted or guessed by an
|
||||||
unauthorized party, the encrypted data's security is compromised.
|
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
|
## How to Perform Symmetric Encryption
|
||||||
|
|
||||||
Performing symmetric encryption with GpgFrontend is a straightforward process.
|
Performing symmetric encryption with GpgFrontend is a straightforward process.
|
||||||
|
|||||||
@ -4,186 +4,100 @@ sidebar:
|
|||||||
order: 2
|
order: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
As a beginner, you're only required to swiftly comprehend a few crucial sections
|
This documentation explains the interface and functionality of GpgFrontend,
|
||||||
of the page. The exploration that follows will gradually unveil additional
|
based on the latest UI design. It is intended to guide users through its
|
||||||
functionalities. Bear in mind that interfaces may vary across different
|
features effectively.
|
||||||
versions.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Text Editor
|
## Text Editing Zone
|
||||||
|
|
||||||
The text editing zone allows you the liberty to input any desired text or
|
The **Text Editing Zone** allows users to input any desired text or work on
|
||||||
establish a new tab through the "New" option in the file menu at the top. Moving
|
existing files. You can open a new tab using the **"New"** or **"New E-Mail"**
|
||||||
or closing tabs can be done with ease as per your needs.
|
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
|
### Key Features:
|
||||||
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.
|
|
||||||
|
|
||||||
The edited text within the text box is encoded in UTF-8 without any formatting.
|
- **Operations Bar**: Located at the top, it provides options to encrypt,
|
||||||
This plain text format ensures that no message alteration leads to confusion.
|
decrypt, sign, and verify text directly.
|
||||||
While there are plans to introduce rich text editing in the future, the
|
- **Standard Shortcuts**: Supports basic shortcuts like **Ctrl+C**, **Ctrl+V**,
|
||||||
specifics are still being deliberated.
|
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
|
- Files up to **1MB** are supported. Larger files may cause performance issues
|
||||||
current limit set to 1MB per file. When dealing with relatively large files,
|
and are not recommended.
|
||||||
editing of the tab won't be feasible until the entire file is loaded. During
|
- While loading large files, editing will be temporarily disabled until the
|
||||||
this time, despite not being able to edit the file, you still have the
|
entire file is processed.
|
||||||
capability to view it.
|
|
||||||
|
|
||||||
It is important to note that opening files larger than 1MB is not supported, as
|
## Information Panel
|
||||||
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 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
|
### Color Coding for Status
|
||||||
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.
|
|
||||||
|
|
||||||
The Information Board was conceived to provide a comprehensive view of more
|
- **Green**: Indicates a successful operation with no issues.
|
||||||
information within the same space. However, GpgFrontend plans to incorporate a
|
- **Yellow**: Suggests a successful operation but with potential warnings.
|
||||||
graphical interface in the future to augment the user's comprehension of this
|
- **Red**: Signifies an unsuccessful operation or critical errors.
|
||||||
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.
|
|
||||||
|
|
||||||
### Dashboard Actions Menu
|
### Dashboard Actions Menu
|
||||||
|
|
||||||
The dashboard actions menu, located below the Information Board, provides quick
|
- **Copy**: Copies content from the Information Panel to the clipboard.
|
||||||
and easy access to essential functions related to the content displayed. It
|
- **Save File**: Saves the Information Panel's content as a plain text file
|
||||||
empowers users to efficiently manage and process large chunks of information for
|
(UTF-8).
|
||||||
various purposes.
|
- **Clear**: Clears all content from the Information Panel, resetting it for the
|
||||||
|
next operation.
|
||||||
#### 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.
|
|
||||||
|
|
||||||
## Key Toolbox
|
## Key Toolbox
|
||||||
|
|
||||||
The Key Toolbox on the right side of the interface lists all available keys,
|
The **Key Toolbox**, located on the right side of the interface, lists all
|
||||||
including public and private keys. The columns provide details such as key type,
|
available keys. It provides details such as key type, name, email address, and
|
||||||
name, and email address. You can select keys from this list to perform various
|
usage. Users can select keys for specific operations by ticking the boxes in the
|
||||||
operations such as encryption, decryption, signing, and verification.
|
first column.
|
||||||
|
|
||||||
### Usage
|
### Key Details
|
||||||
|
|
||||||
Most Gpg-related operations require specifying a key pair (for tasks like
|
- **Type**:
|
||||||
encryption, decryption, signature, etc.). You can select the checkbox in the
|
- `pub`: Public key (for encryption or verification).
|
||||||
first column of the Key Toolbox's table to designate one or more keys for your
|
- `pub/sec`: Key pair with both public and private keys.
|
||||||
operation. Categories that contain only public keys are frequently utilized in
|
- `pub/sec#`: Key pair with missing primary key.
|
||||||
cryptographic scenarios.
|
- `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
|
The toolbox categorizes keys by type (e.g., public or private) using tabs.
|
||||||
include any expired or revoked keys. To view such keys, you should refer to the
|
Expired or revoked keys are not displayed by default and can be viewed in
|
||||||
Key Manager. The default category comprises all private and public keys. During
|
**Manage Keys**.
|
||||||
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.
|
|
||||||
|
|
||||||
## Operations Bar
|
## 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.
|
1. **New E-Mail**: Create a new email or text file.
|
||||||
2. Open: Open an existing text file.
|
2. **Open**: Open an existing text file.
|
||||||
3. File Browser: Browse and select files from your system.
|
3. **File Browser**: Browse and select files from your system.
|
||||||
4. Encrypt: Encrypt the text or file.
|
4. **Encrypt**: Encrypt text or files using selected keys.
|
||||||
5. Encrypt Sign: Encrypt and sign the text or file.
|
5. **Encrypt Sign**: Encrypt and sign text or files simultaneously.
|
||||||
6. Decrypt: Decrypt the text or file.
|
6. **Decrypt**: Decrypt text or files.
|
||||||
7. Decrypt Verify: Decrypt and verify the text or file.
|
7. **Decrypt Verify**: Decrypt and verify signed files.
|
||||||
8. Sign: Sign the text or file.
|
8. **Sign**: Digitally sign text or files.
|
||||||
9. Verify: Verify the signature of the text or file.
|
9. **Verify**: Verify the signature of text or files.
|
||||||
10. Manage Keys: Open the key management interface.
|
10. **Manage Keys**: Access the key management interface.
|
||||||
11. Import Key: Import a new key through some approaches.
|
11. **Import Key**: Import keys into your keyring.
|
||||||
|
|
||||||
This interface provides a comprehensive suite of tools for managing and
|
|
||||||
utilizing your cryptographic keys and performing various encryption-related
|
|
||||||
operations with ease.
|
|
||||||
|
|
||||||
### Customization
|
### Customization
|
||||||
|
|
||||||
For operations that you may not use for a while, you have the option to uncheck
|
You can hide unused functions or add frequently used ones via the view settings
|
||||||
the associated function group in the top menu view. Conversely, for the
|
menu in the application.
|
||||||
operations you frequently use, you have the ability to add them here.
|
|
||||||
|
|||||||
@ -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
|
managing OpenPGP tasks. Embrace the latest features of GnuPG 2.x, enhancing your
|
||||||
security in the digital age.
|
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
|
## User Interface Glimpse
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user