Sources
AES Engine Lab is a teaching model. This file says where each number and each claim on the page comes from. The cipher, XTS and the key wrap are the published algorithms and are checked against published vectors. Anything marked “teaching value” is a number the lab chose to make a point. It is not a measurement of any drive and not a recommendation for real use. Items the sources do not settle are listed under “Open items”. Checked on 2026-10-15 against the saved copies named below.
The cipher
- NIST FIPS 197, Advanced Encryption Standard, the original of 2001-11-26 and the 2023-05-09 update FIPS 197-upd1. The update changed no technical content (its change log says so). Used for: AES has a 128-bit block and keys of 128, 192 or 256 bits, with 10, 12 or 14 rounds (Table 3: Nk = 4, 6, 8 words and Nr = 10, 12, 14); the state is a 4 by 4 byte grid; the four round steps SubBytes, ShiftRows (rows 1, 2 and 3 shift by one, two and three places), MixColumns and AddRoundKey; the S-box built from the inverse in GF(2^8), reduced by x^8 + x^4 + x^3 + x + 1 (the 1b byte), and the affine step with the constant 63; the key expansion with RotWord, SubWord and Rcon, and the extra SubWord that only AES-256 has (Nk > 6 and i mod Nk = 4); the inverse cipher. The lab’s default key 000102…0f and block 00112233…ff, and the ciphertext 69c4e0d86a7b0430d8cdb78070b4c55a in the hero, are the AES-128 example in Appendix C.1 of the 2001 text, which also gives every round’s state. The 2023 update replaced Appendix C with a pointer to NIST’s web page of examples, so the round-by-round values were read from the 2001 copy.
- “One round only stirs part of the block: a change in one byte reaches one column at most.” This follows from the structure in FIPS 197: SubBytes works byte by byte, ShiftRows only moves bytes, and MixColumns mixes within one column. No separate source is cited for it.
- Avalanche: “about half of the 128 bits” and “about half the bits by round 2” are what the lab computes on each run, not figures taken from a source. The dashed line at 64 is half the block.
- Constant time: the page says the lab’s table lookups depend on the data, so it is not constant-time. That is a statement about this code, not a cited attack result.
XTS and the key wrap
- NIST SP 800-38E (January 2010), “Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices”. Used for: NIST approves XTS-AES by reference to IEEE Std 1619-2007, for protecting the confidentiality of data on storage devices, with no authentication; XTS is Rogaway’s XEX tweakable block cipher with ciphertext stealing; the keys are 256 bits for XTS-AES-128 and 512 bits for XTS-AES-256 (so the lab’s 64-byte media key is an XTS-AES-256 key); a data unit is at most 2^20 blocks; an implementation may support only data units of whole blocks, in which case ciphertext stealing is never used (section 5). The lab’s sectors are always whole blocks, which is why it leaves ciphertext stealing out.
- IEEE Std 1619 itself was not read: IEEE sells it. The lab follows the construction SP 800-38E approves (the tweak is
the sector number encrypted under the second key, multiplied by alpha in GF(2^128) for each block, which the code
does with the 87 fold), and its tests carry the IEEE 1619 XTS-AES-128 vectors and cross-check XTS-AES-128 and
XTS-AES-256 against Node’s OpenSSL-backed
node:crypto. The vectors were not checked against the IEEE text. - RFC 3394, “Advanced Encryption Standard (AES) Key Wrap Algorithm”, J. Schaad and R. Housley, September 2002. Used for: the wrap takes n 64-bit blocks and returns n + 1, so the 64-byte media key wraps to 72 bytes (the “few dozen bytes” a password change rewrites); the default initial value is A6A6A6A6A6A6A6A6, and unwrapping checks it, which is how a wrong password is caught. The tests use the RFC’s section 4.1 and 4.6 vectors.
Passwords and the self-encrypting drive
- NIST SP 800-132 (December 2010), “Recommendation for Password-Based Key Derivation, Part 1: Storage Applications”. Used for: PBKDF2 with an HMAC as the pseudorandom function; the salt should have at least 128 bits made by an approved random generator; the iteration count “shall be selected as large as possible”, with a minimum of 1,000 recommended. The lab uses PBKDF2-SHA-256 through Web Crypto with 100,000 iterations and a fixed salt. Both are teaching values: the fixed salt makes the demo repeat, and the page says a real drive keeps a random salt per credential.
- Open Compute Project, Datacenter NVMe SSD Specification, version 2.6 (2024-09-25). Used for: SEC-2 requires hardware-based XTS-AES-256 (as specified in SP 800-38E, which references IEEE 1619) or AES-256-GCM, and says GCM is the preferred mode; SEC-4 requires crypto erase; section 12.6.6 (TCG Crypto) gives as an example that a drive may run PBKDF2 on the user’s locking range password. This is a data center requirement, not a description of every drive.
- Micron, “Data Security Features for SSDs” (white paper, in the library’s Security folder). Used for: a self-encrypting drive has an encryption engine on board, often integrated into the controller, and Micron’s SEDs use AES-256. This is one vendor’s statement.
- Seagate BarraCuda SATA Product Manual 100804187 Rev A, section 4.1 and “Cryptographic Erase”. Used for: on that vendor’s self-encrypting models the data encryption key is a random number generated by the drive that never leaves it and is stored encrypted, and a crypto erase changes the key so the old data reads back under a different key. Note that this manual describes AES-256 in CBC mode, not XTS, and says the erase is “done in a matter of seconds”. It is a hard drive manual.
- TCG Storage Security Subsystem Class: Opal, version 2.02 revision 1.0 (2022). Used for: the page’s line that real controllers manage keys through TCG Opal or similar. Opal defines locking ranges and the Global Range, each pointing to its own K_AES_128 or K_AES_256 key object. The lab models none of Opal.
- NIST SP 800-88 Rev. 2, section 3.2. Used for: cryptographic erase sanitizes by destroying the key, covers only data that was never stored in plaintext, and is described as rapid, with no time given. The lab’s “takes no time” means that no user data is touched; see the open items.
- NVM Express Base Specification 2.4 (2026-07-31), Sanitize command, No-Deallocate After Sanitize (NDAS). Used for: the page’s line that many drives report crypto-erased LBAs as unmapped. After a sanitize, including a crypto erase, the controller should deallocate all user data unless the host set NDAS. That is the specification’s default, not a survey of drives.
Teaching values
| Value | Setting | Source |
|---|---|---|
| Sector size | 512 bytes (also 4096 in the drive model) | Teaching values. In the lab the XTS data unit is one sector |
| The chapter 1 picture | Nine 512-byte sectors, 4 by 4 tiles of 16-byte blocks | Teaching value |
| Media key | 64 bytes, XTS-AES-256 | SP 800-38E: 512 bits for XTS-AES-256 |
| Chapter 1 scramble key | 32 bytes, XTS-AES-128 | SP 800-38E: 256 bits for XTS-AES-128 |
| Authentication (wrapping) key | 32 bytes | Teaching value. RFC 3394 allows a 128, 192 or 256-bit key-encryption key |
| Wrapped media key | 72 bytes | RFC 3394: n blocks in, n + 1 out |
| PBKDF2 | SHA-256, 100,000 iterations, fixed salt “aes-engine-lab demo salt” | Teaching value. SP 800-132 asks for a random salt and as many iterations as practical |
| Demo LBAs | 1000 and 8 | Teaching values |
| Largest LBA | 2^32 - 1 | Teaching value: a 32-bit sector number |
| Key generator | Seeded, not secure | Teaching value, so the demo repeats exactly. The page says so |
| Chapter 2 key and block | “my secret key 01”, “Plain text block” | Teaching values |
| Chapter 7 passwords | “open sesame”, then “a better password” | Teaching values |
| Walkthrough length | About eight minutes | The lab’s own estimate |
Open items for Sean
- “XTS, the mode drives really use”: SP 800-38E approves XTS for storage and many client SEDs advertise XTS-AES-256, but OCP 2.6 now prefers AES-256-GCM for data center drives, and the saved Seagate manual describes AES-256 in CBC mode. The page could say “the mode most drives use” or name XTS as the storage mode NIST approves.
- “An erase that takes no time at all” and “erases the drive in an instant”: no source gives zero time. NIST says rapid, Seagate says a matter of seconds, NVMe reports an estimate in seconds, and OCP 2.6 (CTO-11) allows a crypto-erase format up to 10 seconds. The page could say “in seconds, without touching the data”.
- “Many real drives report crypto-erased LBAs as unmapped”: the NVMe default above supports it for a sanitize; no saved source counts drives.
- IEEE Std 1619 (2007 or 2018) is not in the library. It is sold by IEEE; SP 800-38E stands in for it here.