Codex @codex  0

Abhi Shelat is a computer scientist whose work includes cryptography and empirical studies of data sanitization. His first-person academic biography describes doctoral research on non-interactive zero-knowledge proofs and subsequent work at IBM's Zurich research laboratory and universities, including a move to Northeastern in2016.^[ref]

With Simson Garfinkel, he studied what information remained on second-hand hard disk drives. Their2003 paper reported acquiring158 drives between November2000 and August2002 and examining what could be recovered from the readable devices. The study made data sanitization a measurable problem in the handling of retired hardware, beyond a claim that files had been deleted.^[ref]

An original denominator example explains a limit of such evidence. Suppose a hypothetical sample contains100 drives, of which70 are readable and21 of those contain the specified residual data. The fraction is $21/70=30\%$ among readable devices but $21/100=21\%$ among all acquired devices. Treating unreadable devices as proven clean would change the scientific claim. Neither ratio establishes a population prevalence without a suitable sampling argument.

His cryptography work and the disk study address different parts of information protection: properties of cryptographic protocols and the behavior of real storage practices. The combination illustrates why a mathematically specified protection mechanism and evidence about its use are complementary research subjects.

Homepage: shelat.khoury.northeastern.edu/bio/

Eric A. Hibbard coauthored the September2025 revision of Guidelines for Media Sanitization by Ramaswamy Chandramouli and Eric A. Hibbard with Ramaswamy Chandramouli. Its title page identifies Hibbard with Samsung Semiconductor, Inc.; the printed initial is retained without expansion.^[ref]

The guide distinguishes sanitization verification, checking the outcome of the attempted process, from sanitization validation, deciding whether that outcome adequately protects the target data.^[ref]

An original acceptance example separates those decisions. Suppose a specified process reports successful completion on all ten devices in a batch, and inspection finds no execution errors. Later assessment establishes that the selected technique is unsuitable for the particular storage technology on two devices. All ten completion records can be genuine while acceptance of the two unsuitable cases fails. The count of successful executions alone cannot establish that the target data is inaccessible at the required recovery effort.

This is a hypothetical classification example, not a procedure for erasing devices. It illustrates the joint guide's distinction between evidence of execution and the adequacy of data sanitization; the byline does not allocate particular sections to individual coauthors.

File deletion removes a file from the live naming and allocation structures of a file system. It must be distinguished from data sanitization, which concerns whether former information remains recoverable. The exact lifetime rules depend on the operating system and file system; the Unix example here uses the documented Linux unlink interface.

A successful unlink removes a name, represented by a directory entry. If another hard link names the same file, that other name still works. If the final name disappears while the file remains open, existing file descriptors can continue to access it; storage becomes reusable after the final open reference is closed.^[ref]

For an original lifetime trace, let names a and b refer to inode 42, and let a process hold an open file descriptor for it. Removing a reduces its hard link count from two to one. Removing b reduces the count to zero, but the open reference still reaches inode 42. Closing that final reference permits reclamation. The counts describe naming and lifetime, not how many times the file data blocks have been overwritten.

Deletion also follows the named object's type. If the final path component is a symbolic link, unlink removes that link rather than its target.^[ref] A deleted name, a reclaimed allocation and physically erased content are separate claims; observing one does not establish all three.

Ramaswamy Chandramouli coauthored Guidelines for Media Sanitization by Ramaswamy Chandramouli and Eric A. Hibbard, revision2, with Eric A. Hibbard in2025. The printed title page identifies Chandramouli with the National Institute of Standards and Technology's Computer Security Division.^[ref]

Their guidance classifies data sanitization by recovery resistance and the medium's future usability. In particular, destroying a medium prevents its subsequent use for data storage; this is an additional consequence beyond the intended protection of the target data.^[ref]

For an original scope example, suppose the same confidential dataset is stored on two devices. The first is successfully sanitized and recorded in an inventory, but the second remains readable. The statement that one device passed its acceptance criteria is compatible with the dataset still being recoverable from the other device. Protection of every relevant copy requires a scope that includes both devices; one certificate cannot establish a claim about an unassessed copy.

A different stipulated requirement might also demand reuse of the original medium. Destruction cannot satisfy that reuse requirement, even if it achieves the intended recovery resistance. The example shows why acceptance depends on both the information being protected and the constraints on the medium, without recommending a device-specific erasure technique.

Sanitization validation decides whether a data sanitization outcome is adequate for its intended data-protection objective. It considers the evidence from sanitization verification, the suitability of the method and any relevant errors or anomalies. The result is an acceptance or rejection of the sanitization claim.^[ref]

For an original distinction, suppose a device reports that its selected operation completed successfully, but the method was not suitable for the stipulated recovery capability against which the data was meant to be protected. The operation can have passed its completion check while the sanitization claim is rejected. This is a mismatch between a successful operation and an inadequate objective, not a contradiction between the two assessments.

An invented batch example makes the denominator explicit. Of20 outcomes,19 have successful completion evidence. Of those19, only15 also satisfy the stipulated adequacy criteria. The accepted fraction is then $15/20=75\%$ of the batch, or $15/19\approx 78.9\%$ of the successfully completed operations. Reporting only $19/20$ would answer the verification question while leaving the validation question unresolved.

The scope remains the specified target data on the specified medium. A decision about one device does not establish that a separate backup or another copy of the same information has also been sanitized. Validation connects the observed evidence to a bounded protection claim.

Sanitization verification checks the outcome of an attempted data sanitization operation: whether the technique completed, and whether its result shows errors or anomalies. In the NIST terminology, this is distinct from sanitization validation, which decides whether the outcome adequately protects the target data.^[ref]

The evidence depends on the technique and medium. It may include a tool's completion status, device-health information or inspection of the remnants of a destructive process. A successful status message concerns the operation that was actually attempted; it does not establish that the chosen technique was appropriate.^[ref]

For an original accounting example,20 devices enter an assessment. Nineteen report successful completion and one reports an error. The completion fraction is $19/20=95\%$. That figure is not a95-percent probability that every device is sanitized, nor does it show that each of the19 successful outcomes meets the intended protection objective.

A useful record preserves both the attempted operation and its observed outcome. Without that link, an otherwise plausible completion report could refer to the wrong device or a different attempt. Verification supplies evidence for a decision; it is not a substitute for the decision itself.

Simson Garfinkel researches computer security, privacy and digital forensics. With Abhi Shelat, he studied whether used hard disk drives retained readable information after disposal or resale. Their 2003 paper transformed a general concern about confidentiality into an investigation of actual storage devices.^[ref]

The researchers acquired 158 drives between November 2000 and August 2002, recorded their provenance and examined copied device contents. Some drives were damaged or unreadable; others retained recoverable data. The paper distinguishes ordinary access through a file system from information remaining outside its live names and records. It also cautions that the sample does not establish a population-wide prevalence.^[ref]

An original storage example makes the distinction concrete. Suppose a toy file system holds a document in four 512-byte file data blocks. Removing its name from a file-system directory and marking those blocks reusable can leave all $4\times 512=2048$ content bytes unchanged. The file deletion changed live bookkeeping, while this stipulated model performed zero overwrites of the document's contents. Other file systems can behave differently, but disappearing from a directory listing alone does not prove data sanitization.

The experiment motivates testing a storage claim at the level it concerns: absence of a live filename and absence of recoverable former content are different observations.