EncryptionService derives key using SHA-256 hash instead of a proper KDF

[RUKAYAT-CODER]

Overview

src/security/encryption/encryption.service.ts derives its AES-256 key via crypto.createHash('sha256').update(secret).digest(). SHA-256 is a fast, unaided hash with no work factor, making brute-force key derivation trivial. A proper KDF (PBKDF2, scrypt, or Argon2) must be used instead.

Specifications

Features:

• Derive the AES key using crypto.scryptSync (or Argon2) with a persistent, randomly-generated salt stored separately from the key material.

Tasks:

• Replace createHash('sha256') with crypto.scryptSync(secret, salt, 32).
• Store the salt in a separate env var (ENCRYPTION_SALT) and validate its presence at startup.
• Document migration path for data encrypted with the old key.
• Add unit tests that verify key derivation uses scrypt parameters.

Impacted Files:

• src/security/encryption/encryption.service.ts
• .env.example

Acceptance Criteria

• Key derivation uses a KDF with configurable work factor.
• Startup fails if ENCRYPTION_SECRET or ENCRYPTION_SALT are absent.
• Existing encrypted data can be migrated with a one-time re-encryption script.

[adesinavictor272-alt]

@adesinavictor272-alt has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I would like to work on this issue because I have the technical skills and tools to execute the task

ℹ️ Repo Maintainers: To accept this application, review their application or assign @adesinavictor272-alt to this issue.

[sammycee769]

@sammycee769 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi team 👋

I’d like to take on the task of improving the key derivation logic in the EncryptionService.

I understand the current concern: using a raw SHA-256 hash for key derivation lacks a work factor and makes brute-force attacks significantly easier. I can replace this with a proper KDF using crypto.scryptSync, ensuring a more secure and industry-aligned approach.

My plan includes:

• Replacing the existing SHA-256 derivation with scryptSync(secret, salt, 32)
• Introducing and validating a persistent ENCRYPTION_SALT environment variable at startup
• Ensuring configuration fails fast if required secrets are missing
• Documenting a safe migration path for previously encrypted data
• Adding unit tests to confirm correct KDF usage and parameters

I have experience working with Node.js crypto, secure key management, and backend security best practices, so I’ll ensure the implementation is robust, maintainable, and well-tested.

Please assign this issue to me — I’m ready to get started 🚀

ℹ️ Repo Maintainers: To accept this application, review their application or assign @sammycee769 to this issue.

[Ajibose]

@Ajibose has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

i would love to work on this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ajibose to this issue.

[AlphaMaleBaDI]

@AlphaMaleBaDI has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi, I will implement a proper Key Derivation Function (KDF) using crypto.scryptSync inside EncryptionService.

To deliver a pristine, 100% compliant security enhancement matching all stated acceptance criteria, I plan to:

• Replace the weak, instantaneous crypto.createHash('sha256') key derivation mechanism inside src/security/encryption/encryption.service.ts with a robust crypto.scryptSync(secret, salt, 32) implementation.
• Introduce and enforce a persistent, randomly-generated ENCRYPTION_SALT environment variable, updating .env.example accordingly.
• Implement strict startup validation rules ensuring that the application immediately fails fast and alerts administrators if either ENCRYPTION_SECRET or ENCRYPTION_SALT is completely absent.
• Draft a highly clear, structured markdown data migration path detailing a one-time re-encryption script workflow to cleanly transition historical data encrypted under the old SHA-256 method over to the new secure KDF footprint.
• Expand the unit testing framework to thoroughly verify that key derivation utilizes the correct scrypt parameters and work factors without regressions.

Since my local workspace is perfectly calibrated for backend security services, cryptographic protocol architectures, and Node.js testing suites, I can jump straight into the security modules and submit a highly polished PR immediately. Ready to lock it in!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @AlphaMaleBaDI to this issue.

[JudeDaniel6]

@JudeDaniel6 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Please can you assign me this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @JudeDaniel6 to this issue.

[larryjay007]

@larryjay007 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi, please assign to me, i would like to work on the issue.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @larryjay007 to this issue.

[drips-wave]

Congratulations, @JudeDaniel6! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @JudeDaniel6: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊