https://github.com/c4mbr0nn3/hybrid-ecc-encryption
Proof-of-concept implementation of hybrid encryption using Elliptic Curve Cryptography (ECC) with multi-user data access control. Demonstrates ECDH key exchange, AES symmetric encryption, and secure Data Encryption Key (DEK) management for enterprise data protection scenarios.
https://github.com/c4mbr0nn3/hybrid-ecc-encryption
aes cryptography csharp data-protection dotnet dotnet-core ecdh elliptic-curves encryption hybrid-encryption key-management multi-user-access pbkdf2 proof-of-concept security
Last synced: 2 months ago
JSON representation
Proof-of-concept implementation of hybrid encryption using Elliptic Curve Cryptography (ECC) with multi-user data access control. Demonstrates ECDH key exchange, AES symmetric encryption, and secure Data Encryption Key (DEK) management for enterprise data protection scenarios.
- Host: GitHub
- URL: https://github.com/c4mbr0nn3/hybrid-ecc-encryption
- Owner: c4mbr0nn3
- License: mit
- Created: 2025-05-22T19:58:54.000Z (8 months ago)
- Default Branch: main
- Last Pushed: 2025-07-27T15:14:21.000Z (6 months ago)
- Last Synced: 2025-09-13T11:26:37.338Z (4 months ago)
- Topics: aes, cryptography, csharp, data-protection, dotnet, dotnet-core, ecdh, elliptic-curves, encryption, hybrid-encryption, key-management, multi-user-access, pbkdf2, proof-of-concept, security
- Language: C#
- Homepage:
- Size: 14.6 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Asymmetric Encryption with N users access
Use Elliptic Curve Cryptography (ECC) for public/private key pairs to manage DEK (Data Encryption Key).
## Core concepts
### Key pairs
Each user (CEO, MDs, any other authorized individual or role) who needs to decrypt data will have their own ECC key
pair:
- **Private Key**: Kept absolutely secret and controlled by the user.
- **Public Key**: Shared openly with the system and used by others to encrypt data specifically for that user.
### User's secret role
The user's secret, which the user inputs, will be used to protect their private key. This is typically done by:
- Generating EC key pair
- Encrypting the private key with a symmetric key derived from the user's secret (using PBKDF2 and a salt).
- Storing this encrypted private key with salt (ideally on hardware like yubikey). The system stores the public key,
accessible for encryption operations.
The user's secret is not stored in the system and is not equal to the password used to login in the system.
### Data Encryption Key (DEK) encryption (wrapping)
When encrypted data record is created/updated a unique DEK is generated for its payload.
To grant access to the DEK to a user the system retrieves the user's public key. Then the DEK is encrypted with the
user's public key with hybrid encryption like **ECIES (Elliptic Curve Integrated Encryption Scheme)**.
ECIES essentially uses ECDH (Elliptic Curve Diffie-Hellman) to establish a shared secret with the public key, and this
shared secret is then used to symmetrically encrypt the DEK (using AES or similar).
The output of this process is the encrypted DEK, which can be stored alongside the encrypted data, and any necessary
ephemeral public key used in the encryption process.
### DEK decryption (unwrapping)
When a user needs to decrypt the data, they will:
1. Provide their secret to the system
2. The application uses the secret (and the stored salt) to derive a key that decrypts the private key.
3. The application uses the decrypted private key to decrypt the DEK using ECIES.
4. The DEK is then used to decrypt the data payload using symmetric encryption (AES or similar).
## Database schema
### `users` table
| Column Name | Type | Constraint | Description |
|-------------|------|------------|--------------------------------|
| id | int | PK | Unique identifier for the user |
### `user_key_credentials` table
| Column Name | Type | Constraint | Description |
|-----------------------|-------|------------|----------------------------------|
| id | int | PK | Unique identifier for the record |
| user_id | int | FK | Foreign key to the users table |
| public_key | bytea | | User's public key |
| encrypted_private_key | bytea | | Encrypted user's private key |
| salt | bytea | | Salt used for key derivation |
### `encypted_data` table
| Column Name | Type | Constraint | Description |
|-------------|-------|------------|----------------------------------|
| id | int | PK | Unique identifier for the record |
| data | bytea | | Encrypted data payload |
### `encrypted_data_access_grants` table
| Column Name | Type | Constraint | Description |
|-------------------|-------|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id | int | PK | Unique identifier for the record |
| user_id | int | FK | Foreign key to the users table |
| encrypted_data_id | int | FK | Foreign key to the encrypted data table |
| encrypted_dek | bytea | | The DEK encrypted with the users's public key.
This is the output of a scheme like ECIES, containing ephemeral public key, ciphertext of DEK, and MAC tag |
## Workflows
### User missing EC key pair
We assume user is already registered in the system but it is missing the EC key pair.
The user will be prompted by the system to insert a new secret, once the secret is inserted the system will:
1. Generate a new EC key pair
2. Encrypt the private key with a symmetric key derived from the user's secret (using PBKDF2 and a salt).
3. Store the encrypted private key, salt, and public key in the `user_key_credentials` table.