Hi,
EdAdvokat is right on point, yet i want to add few thoughts/points on this subject.
1) Using TMS Cryptography Pack is not enough to call an implemented functionality secure, there is best practices and there is standards to be applied.
2) How to know that this tool is in fact does encrypt for sure and doesn't leak or even the worse doesn't have a backdoor or master key !!?
3) How to know that this tool didn't reinvented the wheel and made huge mistakes like reusing the IV or the worse, doesn't use one !!?, or chose the wrong padding and it is working now for the lack of specific cases that will lead to data loss.
..
So i suggest the following:
If you don't want to disclose the source ? that is OK, but you have/must disclose the implemented algorithm(s), only then we can validate the functionality and the process, without disclosing the algorithm(s) this tool is highly recommended to not touch or use !
As pointed above (2)(3), there is best practice should be used, there is standards should be applied, there is hundred thousands of hours invested to provide these algorithms and that should not be taken lightly, and most crucial point to remember is that "obfuscation is not security", so disclosing the algorithm(s) is a must, at least we can check that the right usage and check for malicious implementation, like is every byte in that data is accounted for, and there is no backdoor ..etc
From TMS Cryptography Pack documentation i see the following algorithms/standards is right for such usage, namely
Zitat:
RSA (OAEP/PSS and PKCS v1.5) to sign and verify signatures of data with key size up to 4096 bits or to encrypt and decrypt (used to exchange keys)
ECIES to encrypt and decrypt with elliptic curves, the AES and SHA2 (used to exchange keys)
But these will use PKI (asymmetric operation), and there is difference between them, all of them can
handle private key this in like OAEP should be provided in external container like an X509 certificate which can be tricky for your case of usage, but not impossible on the contrary you could add certificate store to use for encryption and provide them along the passwords,
For me i like and use ECIES a lot, this standard is very powerful and relatively faster than RSA, with the nicest thing to have which is shorter key, with shorter keys one can utilize PBKDF2 to generate the private for the ECIES from plain password, i do/did that in so many places, a recommendation here always generate the key with salt, in case you want to limit the encryption/decryption to one tool/project then fix the salt in that tool, otherwise combine stapled (in the exe) certificate private key with a user provided password then derive the private key for ECIES.
Why i suggested these above, because without these standard you are reinventing the wheel and you do need to build a sound and reliable data structure (a container) for the encrypted data and the associated parameters, simple case is that AES encryption must not reuse the key for more than one operation, hence the need for the (pseudo) random IV, and this IV should not be derived from the key !, and it can be public, so it must accompany the encrypted data, so the encrypted file should have the IV, also what MAC algorithm in case you want to do it on your own, and when are you MAC'ing the data, in other words did you use MAC, and which algorithm/method ? Encrypt-then-MAC, MAC-then-Encrypt or Encrypt-and-MAC ? also that MAC should be accompany the encrypted file, so we need at least two fields/data to accompany the file, here comes another question with added data, which padding are you using to ensure the reliability of the mentioned fields, ...
So to skip all above, stick to the well known and vetted algorithms, AES is far from enough be just secure out of the box.
side note: didn't run your tool, but providing command line is very nice functionality to have, so you might consider adding it.