0

I have a randomly generated string of about 256 characters long. This string is hashed to for a key and initialization vector for a program running on the .NET framework 4.8. Is this method secure from a professional point of view?

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
DDX5 Media
  • 1
  • 1
  • 1
    What is the size of the key, how it is generated? Not exactly a clear question and AES-256 has 256 bits of key not 256 characters. – kelalaka Apr 05 '21 at 22:12
  • The key size will become 256bit by hashing the random string into SHA256 byte array and MD5 for The initialization vector. All I Need To Know Is It Safe To Say That The string used to generate the keys will be hard to crack – DDX5 Media Apr 05 '21 at 22:15
  • Say that you have an alphabet of 64 characters (all upper and lowercase characters, digits and 2 special characters, not that many) Then each character contains 6 bits of entropy as 2^6 = 64. So your key is build from 256 * 6 = 1536 bits of entropy, which is more than enough. Then again, your key and IV are static, so if you want to encrypt multiple messages then you're better off prefixing a (usually 16 byte) random IV to the ciphertext so it can be used to initialize the cipher during decryption. – Maarten Bodewes Apr 05 '21 at 22:21
  • 1
    Please don't use MD5 ever. It's insecure and better attacks may be found. It would act as a red flag to any serious auditor of the protocol or code. Instead you might want to read up on KDF's such as HKDF and authenticated encryption. For transport mode security: use TLS. – Maarten Bodewes Apr 05 '21 at 22:23
  • Just for clarification a static IV could be used as a substitute for the MD5 hash instead, If not how would i go about generating an IV that is 128bit – DDX5 Media Apr 05 '21 at 22:36
  • A static IV is fine for some modes (e.g. CTR and GCM) and not for others (e.g. CBC). But you can only use the key once. – Swashbuckler Apr 06 '21 at 00:55
  • If you use a PBKDF then you can just vary the salt as well, in which case the key / IV would still be unique. If you reuse the key / IV combination for CTR and GCM you are really in trouble, much more so than with CBC, so that's probably the answer. – Maarten Bodewes Apr 06 '21 at 23:12
  • @Swashbuckler Sorry, I misread. Why do you think that CBC is vulnerable if a static IV is used with one-use keys? – Maarten Bodewes Apr 09 '21 at 17:54

1 Answers1

-1

The Following Code Is Now Using The Password Derive Bytes Function, All Values Will Be Changed Accordingly

    string Password = "Example";
    byte[] IV = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
    byte[] Salt = Encoding.ASCII.getBytes("Salt Example");
    PasswordDeriveBytes pdb = new PasswordDerivedBytes(Password,Salt);
    Aes Alg = Aes.Create();
    Alg.Key = pdb.CryptDeriveKey("Aes","SHA256",256,IV);
    Alg.IV = IV;

The Code Above Is C#

DDX5 Media
  • 1
  • 1
  • 1
    That is not a safe way to derive a key from a password. A special "Password Hashing Function" like Argon2id is needed, not a general hash like SHA256. Also the IV is incorrect and will negate the security since it's repeated. – SAI Peregrinus Apr 06 '21 at 03:34
  • So Something Like Password derive bytes in C# Would be a better alternative – DDX5 Media Apr 06 '21 at 19:57
  • Yes, though I also don't see what mode AES is being used in (AES isn't secure without a mode of operation, preferably an AEAD mode like GCM), and again you've got a fixed IV which means there's no practical security. The IV must never repeat for any given key (password) in most modes. – SAI Peregrinus Apr 06 '21 at 20:13
  • I Have Not Tried Using A Random IV Before I Know AES Has A Method For That, However Does The IV Have To Be The Same For Both Encryption and Decryption – DDX5 Media Apr 06 '21 at 20:21
  • Yes, the IV must be the same for both encryption and decryption. It's not secret, and is usually sent just before the ciphertext. – SAI Peregrinus Apr 06 '21 at 20:22
  • Found Some Documentation About The Function above And It Should Solve My Problems. I Am Using AES In CBC Mode – DDX5 Media Apr 11 '21 at 15:57
  • CBC mode is unauthenticated. You will have to HMAC the ciphertext (with a DIFFERENT key derived from the same password as the AES key using a password-based key derivation function like Argon2id), then send the resulting tag before the ciphertext message. The recipient will need to verify the HMAC tag, and if verification fails delete the message instead of decrypting. Or you could change to an AEAD mode, like GCM or SIV mode.

    Is there a reason you MUST use AES? IF not, nsec[1] provides libsodium bindings which would be easier to use.

    [1] https://github.com/ektrah/nsec

     – SAI Peregrinus Apr 11 '21 at 22:09
  • I Will Switch CBC To GCM. Will My Code Be Usable And Secure. – DDX5 Media Apr 13 '21 at 12:55
  • If you can avoid ever repeating an IV with a given key, yes. If not, no. Your current example has a fixed IV, so it's insecure no matter what mode you use. – SAI Peregrinus Apr 13 '21 at 21:12
  • See the following for some rules that MUST be followed to use AES-GCM securely: https://crypto.stackexchange.com/questions/84357/what-are-the-rules-for-using-aes-gcm-correctly – SAI Peregrinus Apr 13 '21 at 21:18