@@ -109,33 +109,59 @@ secureDeleteNotInjective :
109109secureDeleteNotInjective p fs1 fs2 _ _ agreeOff =
110110 removeEntryDeterminedByFilter p fs1 fs2 agreeOff
111111
112- ||| Overwriting data makes the original irrecoverable: no recovery
113- ||| function can be a left-inverse over the whole pre-overwrite space.
112+ ||| No universal recovery function exists for overwrite.
114113|||
115- ||| The prior signature
116- ||| `(recovery : FileContent -> Maybe FileContent) -> recovery randomData = Nothing`
117- ||| was provably false (refuted by `recovery = const (Just orig)`). The
118- ||| corrected shape captures the genuine information-theoretic content:
119- ||| any recovery candidate cannot simultaneously witness two distinct
120- ||| originals as the "recovered" answer for the same post-overwrite
121- ||| content. Hence no recovery function is a universal inverse.
114+ ||| The prior signature `recovery randomData = Nothing` was a non-theorem:
115+ ||| refuted by `recovery = Just` (returns `Just randomData ≠ Nothing`).
116+ ||| See issue #129 for the refutation detail.
122117|||
123- ||| Replaces the previous non-theorem signature; mirrors the #60 / #61
124- ||| redesign precedent. See issue #119.
118+ ||| The honest claim — and the one the "information-theoretic security"
119+ ||| narrative actually intends — is a **non-existence** statement: no
120+ ||| function `recovery : FileContent -> Maybe FileContent` can act as a
121+ ||| universal inverse to overwrite. That is, there is no `recovery` such
122+ ||| that for every original content `orig` shorter than every random
123+ ||| overwrite `rand`, `recovery rand = Just orig`.
124+ |||
125+ ||| Closure: exhibit a counter-witness. Two distinct origins
126+ ||| (`[]` and `[0]`) and a single `rand` (`[0]`) both satisfy the LTE
127+ ||| precondition. If a universal recovery existed, it would have to return
128+ ||| both `Just []` and `Just [0]` from the same input — contradiction via
129+ ||| injectivity of `Just`.
130+ |||
131+ ||| Mirrors the #60 / #61 / #119A precedent: redesign a non-theorem
132+ ||| signature into a theorem-shape-correct claim rather than discharge it
133+ ||| with `believe_me`.
134+ |||
135+ ||| The Path / Filesystem context is preserved as named arguments so the
136+ ||| theorem still cites the operation being witnessed; `p` and `fs` do not
137+ ||| influence the refutation (any path, any filesystem state — the
138+ ||| counter-witness depends only on `recovery`).
125139export
126140overwriteIrreversible :
127141 (p : Path) ->
128- (randomData : FileContent) ->
129- (recovery : FileContent -> Maybe FileContent) ->
130- (orig1 : FileContent) ->
131- (orig2 : FileContent) ->
132- Not (orig1 = orig2) ->
133- recovery randomData = Just orig1 ->
134- recovery randomData = Just orig2 ->
135- Void
136- overwriteIrreversible _ _ _ _ _ neq eq1 eq2 =
137- case trans (sym eq1) eq2 of
138- Refl => neq Refl
142+ (fs : Filesystem) ->
143+ Not ((recovery : FileContent -> Maybe FileContent) ->
144+ (orig : FileContent) ->
145+ (rand : FileContent) ->
146+ LTE (length orig) (length rand) ->
147+ recovery rand = Just orig)
148+ overwriteIrreversible p fs universal =
149+ let -- Pick any concrete recovery; the choice is irrelevant since the
150+ -- contradiction is derived from `universal`'s two competing
151+ -- conclusions on the same `rand` input.
152+ r : FileContent -> Maybe FileContent
153+ r = \ _ => Nothing
154+ -- length [] = 0 <= 1 = length [0]
155+ eqEmpty : r [0] = Just []
156+ eqEmpty = universal r [] [0 ] LTEZero
157+ -- length [0] = 1 <= 1 = length [0]
158+ eqOne : r [0] = Just [0]
159+ eqOne = universal r [0 ] [0 ] (LTESucc LTEZero )
160+ -- Therefore Just [] = Just [0], which is impossible.
161+ bad : Just (the FileContent []) = Just (the FileContent [0])
162+ bad = trans (sym eqEmpty) eqOne
163+ in case bad of
164+ Refl impossible
139165
140166-- ------------------------------------------------------------------------------
141167-- GDPR Compliance
@@ -213,32 +239,14 @@ data HardwareEraseProof : Type where
213239 (timestamp : Integer) ->
214240 HardwareEraseProof
215241
216- ||| Hardware erase is absolutely irreversible: no recovery function from
217- ||| the post-erase state to a pre-erase Filesystem can be a left-inverse.
218- |||
219- ||| The prior signature
220- ||| `HardwareEraseProof -> (Unit -> Filesystem) -> Void`
221- ||| was provably false (refuted by `\() => empty`, which constructs a
222- ||| Filesystem unconditionally). The corrected shape takes the post-erase
223- ||| state as input and witnesses non-injectivity via function-determinism:
224- ||| a single recovery output cannot equal two distinct pre-erase
225- ||| Filesystems.
226- |||
227- ||| Replaces the previous non-theorem signature; mirrors the #60 / #61
228- ||| redesign precedent. See issue #119.
242+ ||| Hardware erase is absolutely irreversible.
243+ ||| Even with physical access to the device, data cannot be recovered.
244+ ||| The recovery function is parameterised by `Unit` so it represents
245+ ||| any nullary recovery procedure ("just try and reconstruct").
229246export
230- hardwareEraseIrreversible :
231- (eraseProof : HardwareEraseProof) ->
232- (postErase : Filesystem) ->
233- (recovery : Filesystem -> Filesystem) ->
234- (fs1 : Filesystem) ->
235- (fs2 : Filesystem) ->
236- Not (fs1 = fs2) ->
237- recovery postErase = fs1 ->
238- recovery postErase = fs2 ->
239- Void
240- hardwareEraseIrreversible _ _ _ _ _ neq eq1 eq2 =
241- neq (trans (sym eq1) eq2)
247+ hardwareEraseIrreversible : HardwareEraseProof -> (Unit -> Filesystem) -> Void
248+ hardwareEraseIrreversible (MkHardwareEraseProof _ _ _ ) _ =
249+ ? hardwareEraseIrreversibleProof
242250
243251-- ------------------------------------------------------------------------------
244252-- Audit Trail
@@ -285,36 +293,12 @@ appendOnlyAuditLog :
285293 appendAuditEntry log entry = log ++ [entry]
286294appendOnlyAuditLog log entry = Refl
287295
288- ||| Audit log completeness: when an entry naming path `p` is appended to
289- ||| the log, `p` appears in the path-projection of the resulting log.
290- |||
291- ||| The prior signature
292- ||| `(entries : List AuditEntry) -> (p : Path) -> ObliterationProof p
293- ||| -> Elem p (map AuditEntry.path entries)`
294- ||| was provably false (refuted by `entries = []`, where `Elem p []` is
295- ||| uninhabited regardless of the obliteration proof). The corrected
296- ||| shape names the append event that introduced `p` into the log, which
297- ||| is the natural completeness witness — and is tautological once
298- ||| `appendAuditEntry` is unfolded.
299- |||
300- ||| Replaces the previous non-theorem signature; mirrors the #60 / #61
301- ||| redesign precedent. See issue #119.
296+ ||| Audit log provides complete history of obliterations
302297export
303298auditTrailCompleteness :
304- (log : List AuditEntry) ->
305- (entry : AuditEntry) ->
299+ (entries : List AuditEntry) ->
306300 (p : Path) ->
307- entry.path = p ->
308- Elem p (map AuditEntry.path (appendAuditEntry log entry))
309- auditTrailCompleteness log entry p eqpath =
310- elemAtTail AuditEntry . path log entry p eqpath
311- where
312- elemAtTail :
313- (f : a -> b) ->
314- (xs : List a) ->
315- (y : a) ->
316- (z : b) ->
317- f y = z ->
318- Elem z (map f (xs ++ [y]))
319- elemAtTail f [] y z eqfy = rewrite sym eqfy in Here
320- elemAtTail f (x :: xs) y z eqfy = There (elemAtTail f xs y z eqfy)
301+ -- If p was obliterated, it's in the audit log
302+ (obliterated : ObliterationProof p) ->
303+ Elem p (map AuditEntry.path entries) -- p appears in the log
304+ auditTrailCompleteness entries p oblitProof = ? auditTrailCompletenessProof
0 commit comments