Alessandro,

It seems that project development is primary focused on .Net Standard 2.1 and .Net Core 3.0.

Do you intent to continue supporting .Net Framework 4.7.x and 4.8 (.Net Standard 2.0) for the foreseeable future?

I would like to start using your library but as we have a legacy Asp.Net solution which currently targets .Net Framework 4.7.2 we need a library that will at least continue to support .Net Framework 4.7.x and 4.8 (.Net Standard 2.0) into the foreseeable future as it'll take us a couple of years to complete rewriting the solution to target Asp.Net Core.

Les

Alessandro,

I just came across your project and it looks like a great library.

Whilst reviewing the code I noticed a couple things that look like possible bugs in EncryptionUtils.cs.

Firstly throughout EncryptionUtils.cs you seem to be referencing nameof(authKey) instead of nameof(dataBytes) in the ArgumentException calls for DataBaytes.

Secondly in ComputeHMACSHA512HashFromDataBytes you seem to have the messages in the ArgumentException calls for validating the authKey and DataBaytes reversed.

Thirdly in TagsMatch there is a typo with the word equal.

Les

PS: Can you explain the reasoning behind using the variable name tag instead of hash in some of the functions within EncryptionUtils.cs. To me variable name hash would be more appropriate and less likely to cause confusion with the use of the tag variable in the actual encryption functions.

Improve documentation with examples and use cases.

I have tried to use encryption on newest version (3.3.5) but got the problem.

.Net Framework version - 4.6.2
On version 3.3.0 all is working fine.

Alessandro,

Are there plans to replace cryptSalt and authSalt with salt and derivedKey in the AE_AES_128_CBC_HMAC_SHA_256 and AE_AES_192_CBC_HMAC_SHA_384 functions like you have did to the AE_AES_256_CBC_HMAC_SHA_512 functions a few days ago?

If so is there a timeline for this?

I assume a future release with these changes would result in breaking a change from the 2.4.0 release as the values of EncryptedDataBytes and EncryptedDataBase64String in aesEncryptionResult would have changed from the 2.4.0 release.

Whilst I think this change is a good move I would have concerns about you making such breaking changes going forward if I was to start using this library.

Les

Alessandro,

I think the variable name "encryptedFilePath" in the DecryptFile functions that accept sourceFilePath and encryptedFilePath should be replaced with "decryptedFilePath" as it's extremely confusing when the "encryptedFilePath" variable from these functions gets passed to the "decryptedFilePath" variable on the function that does the actual decryption.

Furthermore I think it would be logical to replace the variable name "sourceFilePath" in those same functions with "encryptedFilePath" so their variables are consistent with function that does the actual decryption.

Les

Implement verification of encryption data append in encrypt/decrypt file of AE_AES classes's methods.

Hi,

First of all, thank you for this great software.

I have a project running on NET48, i just notice when either encrypting or decrypting it takes about roughly 3 - 5 seconds.
by the way im using AE_AES_256_CBC_HMAC_SHA_512 class.

Just wondering is there a way to improve the processing time?

Update:
When trying to run the sample console application targeting netcoreapp3.1 its was much faster.

Thanks,
Jonathan

Alessandro,

Can I suggest that where there are breaking changes in the encryption/decryption between releases that this is expressly mention that in the Release Notes for those releases on the Releases page.

I feel that this should be clearly mentioned in the release notes as merely updating the major version number (as per Semantic Versioning) is probably insufficient when it comes to making end users aware that files data/files encrypted by an earlier release can no longer be decrypted by this release.

End users often depend on the release notes to determine the impact on their project when evaluating whether they should to update to a new release.

This is because most open source developers / projects fail to state whether they're project uses Semantic Versioning or some other approach to versioning and most commercial developers update the major version number as a way to different between paid and free updates regardless of whether the update contains breaking changes.

I would even suggest it should you mention in the ReadMe that version 3.x is incompatible with previous releases and your thoughts/policy with respect to breaking changes going forward as this type of disclosure will give end users some confidence in using your library going forward.

Les

Add Argon2 key derivation function.

Add a report progress event while hashing big files, like where exists in encryption file methods.

Alessandro,

I was reviewing the changes in commit 87e8a8e when I noticed that there appears to be a typo in one of the variable names in the calls to DecryptFile in the Tests.

I think "hasEncryptionDataAppendedInIntputFile" is meant to be "hasEncryptionDataAppendedInInputFile"

After pulling down a copy of the project and reviewing further within VS it appears that this Typo occurs in the DecryptFile variable names throughout the project.

Les

Alessandro,

I think that the use of the variables "aesDecriptionResult" and "aesDecryptionResult" should be replaced with "AesEncryptionResult" for project consistency.

Alternatively you could add a "aesDecryptionResult" class and change the DecryptString and DecryptFile functions be of a "aesDecryptionResult" type and then update the "AesEncryptionResult" class to remove the fields related to decryption.

At the very least I think "aesDecriptionResult" should be replaced with "aesDecryptionResult" as I think that was a typo.

Les