Hi to all,

has anybody an information about the current development status for AES256?

Will it come or is it abandon?

Has anybody replaced the integraded Blowfish128 and MD5 with AES256 and SHA256 and can give a howto for changing the source code?

For Compliance reasons we need to switch to AES256 or to another database which works with Lazarus/Free Pascal.

Thank you for Help in advance.

Teco

FWIW, I asked Claude Code to have a look:

 Feasibility: Moderate difficulty, but high risk

 What's in your favour

 - Clean abstraction — The crypto is well-encapsulated behind two classes (TEDBDigest for MD5, TEDBBlowfish for
 encryption) with simple interfaces. Only 7 source files reference them, and the actual encrypt/decrypt calls go
 through TEDBMemoryStream.InitEncryption, .Encrypt, and .Decrypt — a narrow interface.
 - Windows CNG already present — EDB ships bcrypt.pas (Windows CNG API headers) which already declares
 BCryptEncrypt/BCryptDecrypt. AES-256 and SHA-256 are both available via Windows CNG out of the box, so you wouldn't
 need a third-party library.

 What makes it hard

 1. Breaking change to on-disk format — This is the real problem. The constants change fundamentally:
   - DIGEST_HASH_SIZE: 16 (MD5) → 32 (SHA-256)
   - CRYPTO_BLOCK_SIZE: 8 (Blowfish) → 16 (AES)

 Every existing encrypted database, every stored password digest, and every encrypted comms stream becomes unreadable.
 You'd need a migration path or dual-mode support.
 2. Digest is serialised to disk — TEDBDigest.Save/Load/Read/Write all use the hardcoded 16-byte DIGEST_HASH_SIZE.
 Changing to 32 bytes breaks the binary format of every stored digest (passwords, signatures, etc.).
 3. Tight coupling to block size — TEDBMemoryStream uses CRYPTO_BLOCK_SIZE for block alignment, position advancement,
 and the stream's FBlockSize. Doubling the block size from 8 to 16 changes padding and alignment assumptions
 throughout.
 4. Comms encryption — edbcommsmgr.pas uses InitEncryption for client-server communication. Both client and server must
  match, so this is a coordinated upgrade across all deployments.
 5. It's ElevateDB's source — You're modifying a third-party database engine's internals. Any EDB update from Elevate
 Software would conflict with or overwrite your changes.

 Bottom line

 The code surgery itself is straightforward — replace two class implementations and two constants. But the data
 compatibility impact is severe. Every existing database and every client-server connection would break without a
 migration strategy. And since this is ElevateDB's own source, you'd be forking their crypto layer permanently.

 If the goal is stronger encryption, the more practical path would be to request this from Elevate Software directly,
 or encrypt at the application/transport layer (e.g., TLS for comms, which EDB already supports via sslprovider.pas)
 rather than replacing the engine internals.

FWIW, I asked Claude Code to have a look:

 Feasibility: Moderate difficulty, but high risk

 What's in your favour

 - Clean abstraction — The crypto is well-encapsulated behind two classes (TEDBDigest for MD5, TEDBBlowfish for
 encryption) with simple interfaces. Only 7 source files reference them, and the actual encrypt/decrypt calls go
 through TEDBMemoryStream.InitEncryption, .Encrypt, and .Decrypt — a narrow interface.
 - Windows CNG already present — EDB ships bcrypt.pas (Windows CNG API headers) which already declares
 BCryptEncrypt/BCryptDecrypt. AES-256 and SHA-256 are both available via Windows CNG out of the box, so you wouldn't
 need a third-party library.

 What makes it hard

 1. Breaking change to on-disk format — This is the real problem. The constants change fundamentally:
   - DIGEST_HASH_SIZE: 16 (MD5) → 32 (SHA-256)
   - CRYPTO_BLOCK_SIZE: 8 (Blowfish) → 16 (AES)

 Every existing encrypted database, every stored password digest, and every encrypted comms stream becomes unreadable.
 You'd need a migration path or dual-mode support.
 2. Digest is serialised to disk — TEDBDigest.Save/Load/Read/Write all use the hardcoded 16-byte DIGEST_HASH_SIZE.
 Changing to 32 bytes breaks the binary format of every stored digest (passwords, signatures, etc.).
 3. Tight coupling to block size — TEDBMemoryStream uses CRYPTO_BLOCK_SIZE for block alignment, position advancement,
 and the stream's FBlockSize. Doubling the block size from 8 to 16 changes padding and alignment assumptions
 throughout.
 4. Comms encryption — edbcommsmgr.pas uses InitEncryption for client-server communication. Both client and server must
  match, so this is a coordinated upgrade across all deployments.
 5. It's ElevateDB's source — You're modifying a third-party database engine's internals. Any EDB update from Elevate
 Software would conflict with or overwrite your changes.

 Bottom line

 The code surgery itself is straightforward — replace two class implementations and two constants. But the data
 compatibility impact is severe. Every existing database and every client-server connection would break without a
 migration strategy. And since this is ElevateDB's own source, you'd be forking their crypto layer permanently.

 If the goal is stronger encryption, the more practical path would be to request this from Elevate Software directly,
 or encrypt at the application/transport layer (e.g., TLS for comms, which EDB already supports via sslprovider.pas)
 rather than replacing the engine internals.