securedata

package
v0.0.0-...-236a8fe Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Nov 12, 2024 License: MIT Imports: 8 Imported by: 0

README

Using GopenPGP v3 for Securing Bloom Filter Files with Encryption and Signing

Overview

This document outlines the reasons to choose GopenPGP v3 for securely encrypting and signing Bloom filter files, ensuring both confidentiality and authenticity. Additionally, it includes considerations for using RFC5580 and * RFC9580*, which provide modern cryptographic standards including support for elliptic curve cryptography (ECC) and post-quantum cryptography (PQC), respectively.

Why Choose GopenPGP v3 for Encryption and Signing?

1. Sign-Then-Encrypt Approach
  • GopenPGP v3 follows a sign-then-encrypt approach, meaning that the data is first signed to verify its authenticity and then encrypted to ensure confidentiality.
  • This prevents attackers from tampering with the file’s contents, as any attempt to modify the signature will be detected when the recipient verifies it after decryption.
2. AES-GCM Authenticated Encryption
  • GopenPGP v3 supports AES-GCM (Galois/Counter Mode) for encryption, which provides both confidentiality and * integrity* protection in a single step.
  • AES-GCM ensures that any unauthorized modification of the encrypted Bloom filter file (such as tampering with or stripping the signature) will be detected via integrity checks.
3. Modern and Secure Algorithms
  • GopenPGP v3 supports modern, secure cryptographic algorithms like AES-256 for encryption and SHA-256 or * SHA-512* for signing, ensuring strong protection against current cryptographic attacks.
  • These algorithms are designed to meet modern security requirements and provide long-term protection for sensitive data.
4. Elliptic Curve Cryptography (ECC) Support via RFC5580
  • GopenPGP v3 is compatible with RFC5580, which introduces Elliptic Curve Cryptography (ECC), specifically * Curve25519* and Ed25519, for encryption and signing.
  • ECC provides the same level of security as RSA, but with smaller key sizes and improved performance. This makes encryption and decryption faster, especially for large files such as Bloom filters.
  • ECC is highly recommended for modern applications due to its efficiency and security.
5. Signature Integrity and Verification
  • The signature verification process ensures that any tampering with the signed and encrypted Bloom filter file will be detected. If an attacker tries to strip the original signature and re-sign the file, the verification will fail, alerting the recipient to the modification.
  • GopenPGP v3 uses secure hash functions like SHA-256 to ensure that the signature is computationally secure and resistant to collision attacks.
6. ASCII Armor for Compatibility
  • GopenPGP v3 supports ASCII Armor, allowing the encrypted and signed Bloom filter files to be easily transmitted over text-based systems (e.g., email, HTTP). This ensures compatibility across platforms that may not handle binary data efficiently.

Considerations for Using RFC5580

RFC5580 is a crucial extension to the OpenPGP standard that introduces ECC for enhanced security and performance. When using GopenPGP v3 for encryption and signing, consider the following reasons to adopt RFC5580:

1. Smaller Key Sizes and Faster Operations
  • Curve25519 (for encryption) and Ed25519 (for signing) offer equivalent security to large RSA keys but with * much smaller key sizes*, improving performance.
  • ECC algorithms allow for faster encryption, decryption, and signing operations, which is particularly beneficial when working with large datasets like Bloom filters.
2. Future-Proof Cryptography
  • ECC is recommended by modern cryptographic standards and is expected to remain secure for the foreseeable future, making it a better long-term choice than traditional RSA keys.
  • By using RFC5580, you ensure that your encryption and signing practices align with the latest cryptographic advancements.
3. Strong Security with SHA-256 and SHA-512
  • RFC5580 enforces the use of strong hashing algorithms such as SHA-256 and SHA-512, reducing the risk of vulnerabilities associated with older algorithms like SHA-1.
4. Interoperability with Modern Systems
  • As ECC becomes more widely adopted, using RFC5580 ensures interoperability with other modern systems and software that also use elliptic curve cryptography.

Considerations for Using RFC9580

RFC9580 introduces post-quantum cryptographic (PQC) algorithms, which are designed to be resistant to attacks by future quantum computers. When considering long-term security for your data, here are the key aspects to keep in mind:

1. Quantum Resistance
  • Post-quantum algorithms like Kyber (for encryption) and Dilithium (for signing) are designed to resist attacks from quantum computers that could break traditional cryptographic algorithms like ECC and RSA.
  • If your data needs to remain secure for decades and quantum computing poses a future threat, RFC9580 provides protection against such risks.
2. Storage Overhead
  • Post-quantum cryptography comes with significant storage overhead due to larger key and signature sizes:
    • Kyber keys can range from 800 bytes to 1.5 KB, and Dilithium signatures can be 1.3 KB to 2.6 KB ( compared to 32-byte keys and 64-byte signatures in ECC).
  • This results in 50-100x larger storage requirements for keys and signatures.
3. Performance Overhead
  • Post-quantum cryptographic operations are generally slower than ECC, with encryption, signing, and verification operations taking 2 to 10 times longer.
  • This impacts both system performance and user experience, especially in environments with limited computational resources.
4. Bandwidth Usage
  • The larger key and signature sizes in post-quantum cryptography lead to higher bandwidth consumption when transmitting encrypted or signed data, making it less suitable for low-bandwidth environments.
5. Memory and Computational Resources
  • Post-quantum algorithms require more memory and computational power than ECC, making them less ideal for resource-constrained devices (e.g., IoT or mobile devices).
Summary of Overhead with RFC9580
Overhead Type Traditional Cryptography (RFC5580 - ECC) Post-Quantum Cryptography (RFC9580)
Public Key Size 32 bytes (Curve25519) 800 bytes to 1.5 KB (Kyber)
Private Key Size 32 bytes (Curve25519) 1.6 KB to 3 KB (Kyber)
Signature Size 64 bytes (Ed25519) 1.3 KB to 2.6 KB (Dilithium)
Ciphertext Size Small Larger ciphertext, dependent on algorithm (Kyber)
Key Generation Time Fast 2-5x slower than ECC
Encryption/Decryption Time Fast 2-3x slower than ECC
Signing Time Fast 5-10x slower than ECC
Verification Time Fast 2-3x slower than ECC
Bandwidth Usage Low (small keys and signatures) High (large keys and signatures)
Memory Usage Low (small storage requirements) High (large keys, signatures, and temporary memory use)

Conclusion

GopenPGP v3 is an excellent choice for securing Bloom filter files due to its support for modern encryption and signing algorithms, authenticated encryption, and the sign-then-encrypt process that ensures both confidentiality and authenticity. By using RFC5580, we take advantage of the benefits of elliptic curve cryptography for enhanced performance and security. However, in the future when quantum-resistant security is needed, RFC9580 provides future-proof cryptographic algorithms, albeit with significant storage and performance overhead.


Key Features of GopenPGP v3:

  • Sign-then-Encrypt: Protects both confidentiality and authenticity.
  • AES-GCM: Provides encryption and integrity in one step.
  • ECC via RFC5580: Offers smaller key sizes and faster operations.
  • Post-Quantum Security via RFC9580: Protects against future quantum attacks but with higher storage and computational costs.
  • ASCII Armor: Compatibility with text-based systems for easier transmission.

By following these guidelines and using GopenPGP v3, you ensure that your Bloom filter files are securely encrypted and signed, providing robust protection against tampering and unauthorized access.

Documentation

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

func GenerateTestKeys

func GenerateTestKeys(t *testing.T) []*crypto.Key

func IsRawEncrypted

func IsRawEncrypted(reader *bufio.Reader) (bool, error)

IsRawEncrypted checks if the data is encrypted.

Types

type OpenPGPSecureHandler

type OpenPGPSecureHandler struct {
	// contains filtered or unexported fields
}

OpenPGPSecureHandler handles encryption and decryption using OpenPGP.

func NewPGPSecureHandler

func NewPGPSecureHandler(opts ...Option) (*OpenPGPSecureHandler, error)

NewPGPSecureHandler creates a new instance of OpenPGPSecureHandler.

func (*OpenPGPSecureHandler) Reader

func (h *OpenPGPSecureHandler) Reader(input io.Reader) (VerifyDataReader, error)

Reader returns an io.Reader that decrypts data and verifies the signature.

func (*OpenPGPSecureHandler) Writer

func (h *OpenPGPSecureHandler) Writer(output io.Writer) (io.WriteCloser, error)

Writer returns an io.Writer that encrypts data.

type Option

type Option func(*OpenPGPSecureHandler) error

Option defines a function that can modify OpenPGPSecureHandler and return an error.

func WithPrivateKey

func WithPrivateKey(privKey *crypto.Key) Option

func WithPrivateKeyPath

func WithPrivateKeyPath(filePath string, passphrase string) Option

func WithPublicKey

func WithPublicKey(pubKey *crypto.Key) Option

func WithPublicKeyPath

func WithPublicKeyPath(filePath string) Option

type SecureDataHandler

type SecureDataHandler interface {
	Writer(output io.Writer) (io.WriteCloser, error)  // Encrypts and returns an io.Writer
	Reader(input io.Reader) (VerifyDataReader, error) // Decrypts and returns an io.Reader
}

SecureDataHandler defines an interface for securely handling data (encryption/decryption).

type VerifiedReader

type VerifiedReader struct {
	// contains filtered or unexported fields
}

VerifiedReader wraps VerifyDataReader and verifies the signature at the end.

func (*VerifiedReader) Read

func (r *VerifiedReader) Read(b []byte) (int, error)

Read reads data from the underlying VerifyDataReader and verifies the signature at the end.

func (*VerifiedReader) VerifySignature

func (r *VerifiedReader) VerifySignature() error

VerifySignature verifies the signature of the data read so far.

type VerifyDataReader

type VerifyDataReader interface {
	Read(b []byte) (n int, err error)
	// VerifySignature is used to verify that the embedded signatures are valid.
	// This method needs to be called once all the data has been read.
	VerifySignature() error
}

VerifyDataReader is used for reading data that should be verified with a signature. It is needed because entire data needs to be read before verifying the signature, but bloom.BloomFilter does not always read the entire data it writes.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL