implementing-aes-encryption-for-data-at-rest

Use the cryptography library with AES-256-GCM: derive a key from a password using PBKDF2 or Argon2id, generate a random 12-byte nonce with os.urandom, encrypt the data, and store salt, nonce, ciphertext, and tag together for later decryption.

AES-GCM provides authenticated encryption (AEAD) with a built-in integrity tag, while AES-CBC provides no authentication and is vulnerable to padding-oracle attacks. For data at rest, prefer GCM; CBC should only appear in legacy systems with encrypt-then-HMAC.

AES-ECB encrypts identical plaintext blocks into identical ciphertext blocks, leaking data patterns (the ECB penguin problem). Detect it by encrypting repeated 16-byte blocks and checking for repeated ciphertext blocks; use AES-256-GCM instead.

No. Reusing a 96-bit nonce with the same key is catastrophic: it leaks the XOR of plaintexts and enables authentication-key recovery. Generate a fresh nonce with os.urandom(12) for every encryption and store it alongside the ciphertext.

Never use a raw password as an encryption key. Derive keys with PBKDF2 using at least 600,000 iterations, or use Argon2id for memory-hard resistance, always with a random per-file salt stored with the ciphertext.

Flip one byte of the ciphertext or authentication tag and confirm decryption raises an InvalidTag error and returns no plaintext. A scheme that outputs data after tampering is broken; also confirm decryption with the wrong key fails.