Reconstruction of des.exe/undes.exe

validation.md

@@ -0,0 +1,50 @@
+# Validation
+
+The reconstructed sources were checked in two ways.
+
+## 1. Header/API syntax check
+
+`des.c`, `undes.c` and the common support compile syntactically against the
+actual `crypt.h` from the supplied `cryptl99.zip`.  There are no remaining
+placeholder CRYPTLIB declarations.
+
+## 2. Full CRYPTLIB round-trip on a modern compiler
+
+For a behavioural sanity check, the supplied CRYPTLIB 0.99 source and libdes
+3.14 source were compiled with GCC 14.2 together with the reconstruction.
+
+A binary test file was then processed as:
+
+```text
+plain.bin -> des_v2 -> encrypted.bin -> undes_v2 -> roundtrip.bin
+```
+
+`plain.bin` and `roundtrip.bin` compare byte-for-byte equal.
+
+The generated single-block encrypted file has the expected size:
+
+```text
+4       version
+4       IV
+256     password-check block
+16384   encrypted data block
+-----
+16648 bytes total
+```
+
+The prefix begins with `75 27 00 00`, i.e. file version `0x00002775` in the
+little-endian format used by the DOS executable.
+
+A second test with an incorrect password exits with status 1 and prints the
+same executable string:
+
+`Password is not correct, no decryption possible`
+
+## Scope of this validation
+
+This confirms that the reconstructed control flow is internally consistent
+with the supplied CRYPTLIB source.  It does **not** prove that a modern GCC
+build produces ciphertext byte-for-byte identical to the original Turbo C
+build.  The strongest compatibility test would be to decrypt an actual file
+created by the 1998 `des.exe`, or run the original executable in a DOS
+environment and compare outputs.