Cryptography and Symmetric Encryption
Here are four rows modeled on a file that circulated online in late 2013: an account number, an encrypted password, and the hint the account holder wrote to jog their own memory. The real file also carried each account's email address. These rows are made up, and encrypted with a key of our own, but the method is the one the real file used.
10233871 uqydhFbav5U= the usual
10233872 uqydhFbav5U= numbers
10233873 cezWddcydiH3OnWGtgyJUg== company plus 123
10233874 uqydhFbav5U= 1 to 6
The real file came from Adobe, the maker of Photoshop and Acrobat. Adobe said in October 2013 that attackers had broken into its network and taken customer records along with the source code of some of its programs. A file of about 153 million account records then turned up online, 38 million of them active by Adobe's count. Adobe had encrypted the passwords instead of hashing them, all with the same key. Work out what rows like these give away to someone who doesn't have the key.
Three of the four ciphertexts are identical, so those three accounts have the same password, and nobody needs the key to see it. Their hints read together point straight at the password: the usual, numbers, 1 to 6, which make 123456. In the real file, 1,911,938 accounts shared that one ciphertext.

Encryption and keys
A small online bookstore keeps every order in a database: titles, names, shipping addresses. Once a month it exports the month's orders to a file and stores the file with its backups, and it encrypts that file first, so a copied backup is useless to whoever copies it.
The bookstore uses the same key to encrypt the export and, months later, to decrypt it if a backup has to be restored. Adobe did the same with passwords: one key turned every password into ciphertext, and the same key would turn every ciphertext back.
Symmetric encryption doesn't need a computer. Germany's cipher machines in World War II were symmetric too. A receiving Enigma or Lorenz machine set to the same key as the sender's turned the ciphertext back into the message.


Blocks
Adobe's algorithm, Triple DES, doesn't take a password whole. It cuts the plaintext into 8-byte blocks, one character per byte here, and encrypts each block into 8 bytes of ciphertext. The figure runs three accounts through it the way Adobe did, with each block encrypted on its own. Accounts A and B are shown in full; before looking at account C, predict its first block.
Account C's first block matches the other two, because its first 8 characters are the same sunshine and the key is the same. Only the second block differs. So the ciphertext told anyone reading Adobe's file which accounts shared a password, and which passwords began with the same 8 characters, without the key. The hints did the rest: a password shared by thousands of accounts came with thousands of hints, and enough of them gave it away.
The bookstore's export avoids this weakness by chaining the blocks: each block is mixed with the previous block's ciphertext and then encrypted, so two equal blocks in different places come out different. The cbc in the command below asks for exactly that.
Real AES output with a key of our own. AES, the algorithm the bookstore uses, encrypts 16 bytes at a time, so the picture is cut into 4-by-4 squares of pixels, one byte per pixel, and each square is one block. Each byte of ciphertext is drawn as one gray pixel back in its square.
AES and the key's size
The bookstore uses AES, the algorithm that replaced DES and its triple form.
The owner encrypts each month's export from the command line with OpenSSL, a free encryption program.
openssl enc -e -aes-256-cbc -in orders-03.csv -out orders-03.enc -k [password]
Here -e means encrypt, -in and -out name the plaintext and ciphertext files, and the key is derived from the password given after -k. Decrypting is the same command with -d in place of -e, the files swapped, and the same password. Newer versions of OpenSSL print a warning about this form of the command; adding -pbkdf2 to both commands makes each password guess slower for an adversary.
A 256-bit key has 2 to the 256th power possible values, far beyond anyone's reach. But when the key is derived from a password, does the adversary have to search all of them?
The key comes from the password, so an adversary only has to guess the password. If the owner's password were a word from a dictionary, the search would shrink to the few hundred thousand words in a dictionary. So the bookstore's password is long and generated at random, and it is kept apart from the backups it unlocks.
Adobe's response
Adobe said the system in the file was an old backup, due to be retired, and that its main systems had switched to salted hashes more than a year before. It settled a class action in 2015 by paying 1.18 million dollars in legal fees and promising changes to its security, and in November 2016 it paid 1 million dollars to 15 states and agreed to keep card data out of reach of its public-facing servers, to test its systems for weaknesses, and to train its staff. For the people in the file, the exposure came early: within about a week of the file appearing, a password researcher had worked out its 100 most common passwords, in about three hours of work, by grouping identical ciphertexts and reading their hints, without ever learning the key.
Sources: Krebs on Security, "Adobe Breach Impacted At Least 38 Million Users" (October 29, 2013); CSO Online, "Adobe confirms stolen passwords were encrypted, not hashed" (November 4, 2013); Graham Cluley, "The top 50 woeful passwords exposed by the Adobe security breach" (November 5, 2013); Robinson+Cole, "Adobe settles proposed class action data breach case" (June 18, 2015); Hunton Andrews Kurth, "Adobe Settles Multistate Data Breach Enforcement Action" (November 14, 2016).