AES 128 Bit encryption

[Rene Gladis]

Hi,

has anyone AES encryption (http://aesencryption.net/) working with Harbour ?

Thanks in advance !!!

Best regards

[Alexandre Cavalcante Alencar]

Hi,

Take a look at contrib\hbssl\tests\crypt.prg

Best regards

[Rene Gladis]

Hi,

can someone help me not get the right result

Thanks in advance !!!
Best regards

sample Harbour:
Y1PvsXP1cz4oa3u0dGwJJQ==

aesencryption.net :
BUVnRWYGPLccl5I0jW3bVg==

PROCEDURE Main()

   LOCAL ctx
   LOCAL result
   LOCAL encrypted
   LOCAL decrypted

   LOCAL cKey := "1234"
   LOCAL cTxt := "abcd"

   SSL_init()
   OpenSSL_add_all_ciphers()
   ctx := hb_EVP_CIPHER_ctx_create()
   EVP_CIPHER_CTX_init( ctx )

   EVP_EncryptInit( ctx, "AES128", cKey)
   EVP_CIPHER_CTX_cipher( ctx )
   EVP_CIPHER_block_size( EVP_CIPHER_CTX_cipher( ctx ) )

   encrypted := ""
   result := ""
   EVP_EncryptUpdate( ctx, @result, cTxt )
   encrypted += result
   EVP_EncryptFinal( ctx, @result )
   encrypted += result

   ? "ENCRYPTED", ">" + hb_base64Encode( encrypted ) + "<"
  
   ctx := NIL
   EVP_cleanup()

   RETURN

[Sami Laham]

take a look at link below

http://www.pctoledo.com.br/forum/viewtopic.php?f=4&t=17146&sid=50201eea1ec58daec5f30b825338d77e


Regards

Sami

[Alexandre Cavalcante Alencar]

Be sure you and the website are using the same AES configuration.

Same message

Same key

Same block size

Same mode

If, for a exercise, you take an OpenSSL install, try this:

echo abcd | openssl enc -aes-128-cbc -e -k 1234 > t1.enc.aes-128-cbc

echo abcd | openssl enc -aes-128-cfb -e -k 1234 > t1.enc.aes-128-cfb

echo abcd | openssl enc -aes-128-ecb -e -k 1234 > t1.enc.aes-128-ecb

echo abcd | openssl enc -aes-128-ofb -e -k 1234 > t1.enc.aes-128-ofb

If you try to decrypt with different parameters, it will fail

Using same key, blocksize and wrong mode: ecb instead of cbc

openssl enc -d -aes-128-ecb -in t1.enc.aes-128-cbc -k 1234

bad decrypt

28852:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:.\crypto\evp\evp_enc.c:337:

Using same key, blocksize and mode: cbc

openssl enc -d -aes-128-cbc -in t1.enc.aes-128-cbc -k 1234

abcd

Best regards

[Attila Szabó]

Hi,

I noticed that "AES-128-ECB" mode corresponds to AES/ECB/PKCS5PADDING mode.

I tested here: https://8gwifi.org/CipherFunctions.jsp

Is there any way to use AES/ECB/NOPADDING in Harbour?

Open SSL Version Installed: 1.0.2n

Harbour Version Installed: HB-3.2.0dev (r1711221033)

Best Regards,

Attila

[Zsolt Varga]

Hi!

I needed something similar for the Hungarian Tax Authority (NAV). So far I have been using HMG 3.4.0 and it worked. I don't remember how I managed to get it together. I downloaded version 3.5 and now it doesn't work.
Even though both hbssl and hbcrypto are compiled with OpenSSL.
Yet I get error messages like this:
... i686-w64-mingw32/bin/ld.exe: cannot find -llibssl
... i686-w64-mingw32/bin/ld.exe: cannot find -llibcrypto

If I could solve this, it is likely that new ones would be created, but for now these are the ones.

What could be the solution?

Thank you!

[Takács Gábor]

Hi,

Olvastad már?

https://groups.google.com/d/msgid/harbour-users/e676f532-3f76-4315-bb0a-cc9e41700ff8n%40googlegroups.com?utm_medium=email&utm_source=footer

--
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: https://groups.google.com/group/harbour-users
---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/harbour-users/b0a259f4-8a99-4ed1-93e7-5e4b47a5adcfn%40googlegroups.com.

[Zsolt Varga]

Köszönöm!
(Majd megnézem később.)

[Paolino Rappa]

Good morning everyone,
Thanks to this conversation, I was able to download the Yugi source code for implementing the AES algorithm.
http://www.pctoledo.com.br/forum/viewtopic.php?f=4&t=17146

Unfortunately, due to the use of Portuguese for both function and variable names, I had difficulty reading it and, with the help of AI, I decided to translate it into English.
Once finished, I decided to make some improvements and share the new source code, including the original.

The following changes were made:

- Translated all function and variable names from Portuguese to English. Where appropriate, some names were replaced with more descriptive ones.  
- Unified all functions performing the same task with different keys (e.g., the functions cifraArquivo(), cifraArquivo192(), and cifraArquivo256() were replaced by the function EncryptFile()).  
- Added functions to encrypt/decrypt text in CBC and CTR modes. ECB mode was retained only for educational purposes, but its use is strongly discouraged unless the data is non-sensitive.  
- Added CTR mode and an HMAC authentication tag to file encryption/decryption.  
- Declared all internal functions (not callable from outside this source) as STATIC.  
- Removed all validation checks except those for externally accessible functions. Since internal functions receive parameters only from other functions within this source, it is assumed they are valid, making further validation unnecessary.  
  For the same reason, functions performing such checks were removed.  
- Removed the initialization function iniciarAES(), which had to be called before other functions.  
  Accordingly, tables were declared using #DEFINE, and all PUBLIC variables were replaced by LOCAL variables declared exclusively within the functions where needed.  
- Padding code present in various functions was replaced with calls to dedicated padding functions.  
- Replaced calls to the HB_RANDOM() function (not cryptographically secure) for random IV generation with a function that invokes the Windows API, which is cryptographically secure. In case of API failure, a fallback code written in C is used. Although not as secure as the API, it is still more robust than HB_RANDOM().  
- Main functions no longer require fixed-length hexadecimal keys for encryption; now, strings of any length (passwords) are accepted.  
  The code will convert the input into a valid key for encryption using the DeriveAESKey() function.  
  It is unreasonable to expect users to input fixed-length hexadecimal keys.

To compile use: hbmk2 -GTWVT Xhb.hbc test aes -lhbnf -lhbmisc -lhbct -static -w3 -RUN

Regards

Translated with DeepL.com (free version)

[Aleksander Czajczyński]

wtorek, 16 września 2025 o 11:45:35 UTC+2 Paolino Rappa napisał(a):

- Replaced calls to the HB_RANDOM() function (not cryptographically secure) for random IV generation with a function that invokes the Windows API, which is cryptographically secure. In case of API failure, a fallback code written in C is used. Although not as secure as the API, it is still more robust than HB_RANDOM().  

You could use HB_RAND(), possibly even HB_RANDSTR() functions derived from arc4random, on Windows they call advapi32 - probably the same way you do, without duplicating the solution.

Best regards, Aleksander

[rossi.ma...@gmail.com]

Thank you!

[Paolino Rappa]

Hi Aleksander,

Thanks for your comment.

I didn't know HB_RAND() and HB_RANDOMSTR() used CryptGenRandom, although what you say toward the end makes me think you're not sure yourself.
As mentioned, I've had AI help, and they've always told me that Harbour's random functions aren't cryptographically secure, even worse than those in the C language, where, among other things, they aren't used in cryptography either, and special libraries are used instead.
If it's as you say, then mine is truly a duplicate. However, my code implements an explicit fallback with an LFSR generator and a high-entropy seed, and, at this point, I'd like to know how robust Harbour's internal fallback is.
At this point, I'm undecided whether to use Harbour's functions or leave things as they are (after all, they've been written by now, and at least they give me the impression I have the situation under control).

Best Regards, Paolino

[Aleksander Czajczyński]

środa, 17 września 2025 o 13:43:04 UTC+2 Paolino Rappa napisał(a):

Hi Aleksander,

Thanks for your comment.

I didn't know HB_RAND() and HB_RANDOMSTR() used CryptGenRandom, although what you say toward the end makes me think you're not sure yourself.

https://github.com/harbour/core/blob/master/src/rtl/arc4.c

https://github.com/harbour/core/blob/master/src/rtl/hbrand.c

Maybe the fallback is not up to your standards. err,  i'm not sure either :-)

Thanks for posting your code.

Best regards, Aleksander

[Paolino Rappa]

Thanks for the new comment Aleksander..

You're actually right, and my code can easily be replaced with HB_RANDSTR().
However, ChatGPT told me it would be better to use BcryptGenRandom, which is more modern (works starting with Windows Vista) and recommended by Microsoft.
Therefore, I modified my function to use BcryptGenRandom instead of CryptGenRandom and use HB_RANDSTR() as a fallback.
What do you think?

#DEFINE DC_CALL_STD          0x0020
#DEFINE BCRYPT_USE_SYSTEM_PREFERRED_RNG   0x00000002

FUNCTION RandomStringAPI( nLen )
   LOCAL cRandom := SPACE( nLen )
   LOCAL nRes

   // Tentativo con BCryptGenRandom (CNG API, Windows Vista+)
   nRes := DLLCALL( "bcrypt.dll", DC_CALL_STD, "BCryptGenRandom", ;
                    0, @cRandom, nLen, BCRYPT_USE_SYSTEM_PREFERRED_RNG )

   IF nRes != 0
      // Se fallisce, fallback sicuro su HB_RANDSTR()
      cRandom := HB_RANDSTR( nLen )
   ENDIF

RETURN cRandom

Best regard

[Aleksander Czajczyński]

Hello!

Both BCryptGenRandom and old CryptGenRandom are told to use the same backend internally, except a situation where you request a specific RNG of your choice using newer API. BCRYPT_USE_SYSTEM_PREFERRED_RNG suggests it will be the same. Anyway if you're concerned by these things, CPU hardware-backed RNG in modern Intel processors are told to be engineered by government. Some security oriented OSes exclude this generator as a source of entropy.

https://stackoverflow.com/questions/37290697/difference-between-cryptgenrandom-and-cng-bcryptgenrandom-apis

I guess Harbour could dyncall BCryptGenRandom if it's available. That's if "use the newer API" buzz convinces to make a patch.

Best regards, Aleksander Czajczyński

[Paolino Rappa]

Hi,

It looks like my code is really superfluous, and HB_RANDSTR() is perfect for the job. I'm actually fine with that, as I have no interest in rewriting existing code, and from that perspective, it would have been perfect if Harbour had also included the AES functions (I wouldn't have spent hours rewriting the original AES file, though I can't complain, as I only program as a hobby, and it served me as a pastime).

Best Regards, Paolino