Are there issues in how cryptography is used in this short code sample?

Question

I want to encrypt some small text files so I can put them online, in non-restricted access (not the best idea, but it's cheap and simple). I know I should use something like Truecrypt instead of this, but I'm looking for something lighter and simple.

import base64
import os
from cryptography.fernet import Fernet
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC

from sys import argv


if len(argv)<3:
    exit('please provide a password')
    exit()
# password = b"password"
password = argv[2].encode()
salt = os.urandom(16)
salt = b'\x03>\x8d\xd9x\x8d\xdcR\xc9\x1b-\x9c\x86\xc7\x83\x8c'
kdf = PBKDF2HMAC(
    algorithm=hashes.SHA256(),
    length=32,
    salt=salt,
    iterations=100000,
    backend=default_backend()
)
key = base64.urlsafe_b64encode(kdf.derive(password))
# print(key)
f = Fernet(key)
# print(token)
# print(f.decrypt(token))
# print(salt)

if "encrypt" in argv:
    plain_src = open("plain.nogit.txt", encoding='utf8')
    crypted = open("crypted.nogit.txt",'w')

    token = f.encrypt(plain_src.read().encode())
    plain_src.read().encode()
    # print(repr(token))
    crypted.write(repr(token))
elif "decrypt" in argv:
    plain_src = open("plain.decrypted.nogit.txt",'w', encoding='utf8')
    crypted = open("crypted.nogit.txt")
    token = eval(crypted.read())
    plain_src.write(f.decrypt(token).decode())

    if open("plain.decrypted.nogit.txt", encoding='utf8').read() == open("plain.nogit.txt", encoding='utf8').read():
        print('same content')
    else:
        print('different content')
else:
    exit('provide either 1 or 2 args')

How secure is this? I'm aware that this would leave the password in the shell history (which can be deleted and cleared), but I just want to ask if this the right way to encrypt some simple text data. My goal here is to have best ratio security/simplicity. What would you change? Any advice?

Answer 1

I see the following security issues:

• The essential purposely-slow password-to-key transform is PBKDF2-HMAC. That's better than nothing, but among the better-than-nothing that's one of the worse from the standpoint of resistance to hardware-assisted password cracking (using GPUs, FPGAs, or ASICs). Nothing lesser than scrypt or Argon2 is recommendable nowadays.
• The random salt for PBKDF2 is obliterated by a fixed value. It should be left random, stored in the ciphertext on encryption and taken from that on decryption. Random salt is there for a good reason: prevent password-cracking adversaries from amortizing work among multiple users.
• The workfactor parameter iterations=100000 is fixed and not stored in the ciphertext. That's not future-open. Also it seems a tad low.

I have no opinion on the security of the implementation of Fernet, which I did not check. However I have some mixed feelings about what I see in the doc:

• The example for password-to-key transform is awfully dated (and the root cause of much of the above critic). On the other hand, on second read, I notice they do link to and have built-in support for scrypt, a rather satisfactory alternative, +1 for that.
• The specification states "Signing-key, 128 bits" for what really is a MAC key¹.
• It is documented a 256-bit (H)MAC, which is needlessly large given the key size.
• If quantum computers usable for cryptanalysis materialize, choosing 128-bit keys for encryption and MAC will look like a poor choice; OTOH 128-bit is still quite safe in the foreseeable future.
• Handcrafting authenticated encryption with AES-CBC and HMAC is dated; there are better modes nowadays, like AES-GCM-SIV, or ChaCha20-Poly1305.

Other issues:

• The program opens the plaintext with encoding='utf8' and thus can't be used for e.g. a jpeg file.
• Command line parsing is uh, substandard.

---

¹ I have made / let a similar terminology error slip review long ago, and it still burns me often.