2

I'm trying to make a Python program which will take the file and key and then it will encrypt the file. I already know that the AES-GCM and AES-CFB mode uses a nonce and IV, respectively. And I currently store the IV/nonce in the encrypted file itself. I'm pondering over the idea if I can use the IV/nonce of the AES-CFB/AES-GCM as my password hashing salt?

Earlier I hashed the key provided, but when I came to know about Rainbow-tables, I thought of using a more sophisticated way. The approach I came to know about was PBKDF2.

if filepath.endswith(EXT):
      method = 'decrypt'
      flag = False
      with open(filepath, 'rb+') as f:
        f.seek(-NONCE_SIZE,2)
        iv = f.read()
      os.truncate(filepath, os.path.getsize(filepath) - NONCE_SIZE)

    # If the file doesn't end with the required extension,
    # then identify the method as `encrypt` and do the same
    # with the key provided.
    else:
      method = 'encrypt'
      flag = True
      iv = Random.new().read(NONCE_SIZE)

    # Make a cipher object with the nonce and key and write
    # to the file with the arguments.
    # Previous approach as commented-out code line below
    # key = hashlib.sha3_256(key.encode()).digest()
    key = PBKDF2(key, iv, dkLen=32)
    crp = getattr(AES.new(key, AES.MODE_GCM, nonce=iv), method)

I expect that the IV/nonce used as a password hashing salt provides the security required.

arunanshub
  • 581
  • 5
  • 15
  • To clarify, the use of key derivation functions has nothing to do with rainbow table attacks. Rainbow tables are used to efficiently lookup the input to hash values. But in this case the hash value is the encryption key. An attacker that knows the password hash can already decrypt the ciphertext; figuring out the password is pointless. The KDF is an intentionally slow function so that brute-forcing the password becomes slow. With your old code an attacker has to perform only one SHA computation and one AES-GCM decryption to test a password, which is very fast to do. – Peter Jun 18 '19 at 09:48
  • 2
    Possible duplicate of [Reusing PBKDF2 salt for AES/GCM as IV: dangerous?](https://stackoverflow.com/questions/48709703/reusing-pbkdf2-salt-for-aes-gcm-as-iv-dangerous) – Peter Jun 18 '19 at 09:50

2 Answers2

2

That is what the IV and the nonce are there for already. Using them twice might have catastrophic effects on the encryption. A nonce is by definition a number that is used only once.

Klaus D.
  • 13,874
  • 5
  • 41
  • 48
  • 2
    That's oversimplifying things. For block cipher modes it's totally okay to re-use an IV with another key, for instance. It would be very impractical otherwise, because we'd have to guarantee *globally* unique IVs. I very highly doubt that using the same IV for completely different algorithms -- family of algorithms, even, since one is hashing and one is encryption -- poses any kind of problem. – Peter Jun 18 '19 at 09:41
  • You can reuse an IV with an other key, but you should not reuse it with the same key and you should not use it twice while encrypting the same block. – Klaus D. Jun 18 '19 at 10:27
  • 1
    Agreed. But that isn't the question. – Peter Jun 18 '19 at 10:44
  • @Peter In his code he use `iv` twice, once for the key derivation function and then as the nonce for the encryption. – Klaus D. Jun 18 '19 at 10:59
0

I realized that there is no saner way other than to just create two different random bytes, one for the password derivation salt, and the other one for nonce for the block cipher.

arunanshub
  • 581
  • 5
  • 15