All you need is vanilla JavaScript! Seriously. Email me at [email protected] I will be glad to discuss my approach to completely avoiding these frameworks.
It was remarkable to me that I could not think of a good example for you. Apparently I myself to not have any good C# to share even though I have worked with the language a lot.
Anyways, I suggest you use Visual Studio, use the code formatter, and stick to common good programming practices such as: using proper accessors (public, private, protected), don't duplicate code, name variables with style, document things that you think you'll be curious about later, and use git to keep track of your code.
I have been using symmetrically encrypted TCP servers and clients, which I have been developing in a C++ library.
I believe the standard is basically TLS 1.2 asymmetric encryption and then token-based authentication via username/password mechanisms. For example, most databases are securely accessible via external services using TLS.
Key distribution in my case (symmetric encryption,) is trivial, but securing or replacing those keys is non-trivial and I have yet to solve this problem.
Nonetheless, securing private or even public TLS keys is a seriously difficult problem as well.
Ok so I guess the resulting lesson from Canada for me is that having a HASH or MAC for encrypted files is the most critical part of any secure system OP is interested in.
Furthermore, Canada, what about privately managed machines communicating via TCP and AES 256 CBC symmetrically encrypted messages? I also use a random salt and a transaction number.
Until now, I was thinking that successfully decrypted data would be safe. Is the case for TCP encrypted data the same? I need to have a MAC for each message and verify that between ACK's or something?
It looks like incorporating a MAC within or alongside the encrypted data is not as insecure or as complex as I was afraid.
Can both my TCP encryption and OP's file encryption problem by solved by just appending a HASH of the encrypted data to the end of the encrypted data (EtM), or appending a HASH of the plaintext data to the end of the plaintext data and then encrypting that (MtE)?
I agree that using the command line for this type of problem is going to be problematic.
I also see clearly how hashing the encrypted data before "storing it at this 3rd party" would allow you to verify CBC block modifications.
I guess I don't understand GPG well enough to see how it solves this problem better than AES CBC 256. Could you perchance provide a link? Or explain how GPG would take care of this?
Use AES 256 bit encryption. It looks like you found some openssl command line tools to do this, which appears fine. (I can't speak on the details of that particular tool.) Depending on your technology stack, there are probably a number of tools which can programmatically encrypt and decrypt files.
For example, I use CryptoPP for AES 256 bit encryption in C++.