Jump to content
TheXman

CryptoNG UDF - Cryptography API: Next Gen

Recommended Posts

Posted (edited)
5 hours ago, RTFC said:

A praise-sandwich ;) for CryptoNG:

Top bread slice: Great work; thorough, methodical, consistent, clean code, and well-documented; an excellent contribution all-round.

@RTFC  Thanks so much!  :thumbsup:

5 hours ago, RTFC said:

At the moment, the library does not handle UTF-8 strings correctly

I will take a look into this.  I think CryptoNG handles UTF8 strings, but from what you have shown it may not handle strings with multi byte characters correctly.  If that is true, which it appears that it is, I will see what I can do to add the ability to handle such strings. 

In typical American fashion and since I don't ever use multi-byte character sets, for the most part, they don't exist.  :oops: It's sort of like how some of us assume that everyone speaks English. :muttley:

5 hours ago, RTFC said:

Furthermore, you cannot properly test this using your current example suite, as you use Consolewrite for examining output, which would require a registry hack each time to select the appropriate code page(s) to render non-English UTF8 characters correctly.

Yes, this is true.  By default, the Scite4AutoIt editor's message area does not correctly display multi-byte characters.  As I mentioned above, I'm sure I used ConsoleWrites in my examples because I didn't take into account the possibility of strings with multi-byte characters in them.  It was definitely short-sighted on my part.  :doh:I will see if I can come up with a better set of examples that will work universally with either single or multi-byte string output.

 

5 hours ago, RTFC said:

BTW, your recent "upgrade" of filling struct members using dot notation causes my scripts to error out (on every dot-based struct access) with:

"<path>\CryptoNG.v1.5.5.au3" (2743) : ==> Variable must be of type "Object".:
$tInputBuffer.data = Binary($vData)

Those look like Au3Check errors and I do not get them when I run the UDF or the example file through Au3Check.  I'm not sure why you are getting them. 

I did see that I forgot to run the latest version through Au3Check with the strictest settings which allowed some "declared, but not used in func" warnings to get through.  I will definitely get those corrected in the next version.

As for using dot notation for the dll struct gets & puts, I have read and seen small tests that show it is a little faster but not by much.  In this particular case, I don't think speed is a concern because the gets & puts are not occurring in a loop or being done multiple times during encryption or decryption.  My primary reason for making the change was that it looked cleaner and required far less code to get the same result.  :)

5 hours ago, RTFC said:

Bottom bread slice: As you know, I've gratefully incorporated your library into my own CodeCrypter environment, and it's proving a real asset, so many, many thanks for your continuing efforts, and I hope you'll keep maintaining it.

I'm glad that you have found the UDF useful.  I definitely plan to maintain it for the foreseeable future.  :)

 

I will start looking into these issue today.  Hopefully I can get them resolved quickly. 

I won't be truly satisfied with this "Praise Sandwich" until all of the fillings are as good as the slices of bread.  :D

 

Edited by TheXman

Share this post


Link to post
Share on other sites

@RTFC

I have made all of the changes to needed to handle multi-byte characters used as input to the CryptoNG functions.  I just have to do a bit of regression testing to make sure that nothing was broken by all of the modifications.  Hopefully, I will have a new version available by the end of the day tomorrow (Central Standard Time).  :)

Share this post


Link to post
Share on other sites
Posted (edited)

What's New

v1.6.0 (2020-07-10)

  • Added the ability to handle data that contains multi-byte character sets. (Reported by RTFC)
  • Removed all AU3CHECK warnings.
  • Added a new example to show the encryption/decryption of strings with multi-byte characters: aes_cbc_encrypt_decrypt_multibyte_example()
  • Added multi-byte characters to the example Word .docx so that the example script that encrypts/decrypts a file shows that it can handle multi-byte characters.
  • The example scripts used to write their output to the console.  The Scite4AutoIt's editor does not display multi-byte characters in the message area.  So the example scripts now sends messages to notepad, which does handle multi-byte characters.  (Best to use a monospaced font in Notepad, like Consolas, so that the message formatting displays correctly)
  • Removed a few examples whose functionality was duplicated in other example scripts.
Edited by TheXman

Share this post


Link to post
Share on other sites
Posted (edited)
12 hours ago, TheXman said:

new version available

Wow, you really are as fast as your avatar picture suggests; velocius quam asparagi conquantur. Many, many thanks.:thumbsup:

EDIT: So I found the bug triggering the error (which wasn't due to AU3check): your code never checks for empty input strings in your encryption UDFs (and I initialise my environment by calling with an empty argument), so DllStructCreate tries to allocate a buffer of size 0, which fails, but you don't check for errors after that call either. Example:

Func aes_cbc_encrypt_decrypt_example()

    Const $ALG_ID       = $CNG_BCRYPT_AES_ALGORITHM, _
          $MESSAGE      = "", _
          $SECRET       = "Secret Password!", _
          $SECRET_SALT  = "Secret Salt"

I would just add a size>0 check on the parsed string at the highest calling level. Sorry for not reporting this earlier.:>

Edited by RTFC
persistent bug

Share this post


Link to post
Share on other sites
Posted (edited)
On 7/11/2020 at 2:54 AM, RTFC said:

So I found the bug triggering the error (which wasn't due to AU3check): your code never checks for empty input strings in your encryption UDFs (and I initialise my environment by calling with an empty argument), so DllStructCreate tries to allocate a buffer of size 0, which fails, but you don't check for errors after that call either.

I always wondered what, if any, differences there were between using the DllStruct Get & Set functions and their dot-notation alternatives.  Thanks to you, now I know at least one difference.  :)   The object-based, dot-notation form does not like having empty values being set.  The regular functions handle it without any issues.  I'll have to tuck that new bit of knowledge away for future reference.  Thanks for making me aware of it.

With the knowledge above, I have reverted all of the dot-notation references back to their DllStruct* functions.  I think there are too many "gotchas" that could pop up using the dot-notation.  I will be publishing v1.6.1 now.

As you may or may not be are aware, trying to encrypt an empty string has always and will continue to generate an API error.  The error says something like "...an invalid parameter has been passed".  So during your environment initialization, you will have to work around that, if you haven't already. ;)

Update:

I went back and took a look at what you said and the root cause of the issue.  As you said, because an empty value had been passed, when I tried to set the DllStruct's buffer to zero length (byte[0]), of course it failed.  So it was really was an oversight on my part that I didn't check for empty values being passed in order to prevent that sort of error.  I should've known better.  :doh:So it really isn't an issue with object-based dot-notation. 

I've reverted everything back to dot-notation and added the additional logic validation logic to make sure that empty values are handled appropriately.  Thanks again for pointing out the issue.

Edited by TheXman
Corrected my previous statement

Share this post


Link to post
Share on other sites

What's New

  • v1.6.1 (2020-07-11)
    • Reverted all dll struct gets & sets from dot-notation back to DllStructGetData & DllStructSetData.  Using dot-notation caused object initialization errors when value was set to an empty string. (Reported by @RTFC)

Share this post


Link to post
Share on other sites
2 minutes ago, TheXman said:

Reverted all dll struct gets & sets

That's funny, I just spent the last hour doing exactly the same thing (again).:lol: Yeah, I always avoid dot notation if possible (hate blackboxes).

8 minutes ago, TheXman said:

So during your environment initialization, you will have to work around that

Thanks (was aware of that); my initialisation just needs your function to be called for it to be recognised as "active" in the context of CodeScanner; otherwise it gets pruned as redundant when CodeCrypter is reconstructing the script from scratch. From now on, I'll be parsing a non-empty dummy string, just to be sure.

Share this post


Link to post
Share on other sites

What's New

  • v1.6.2 (2020-07-12)
    • Added additional function parameter validation to prevent the issue, reported by RTFC, where passing empty strings to some functions was causing DllStructCreate failures.
    • Reverted all DllStructGetData & DllStructSetData functions back to object-based dot-notation.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...