Synthesis Tamper-evident Attestation and Molecular Provenance (STAMP): Cryptographic Molecular Barcoding for DNA Synthesizers

STAMP seems like a working technique for barcoding but I'm not seeing the specific problem it's trying to address. The case study presented shows that you would be able to detect a tampered plasmid using the STAMP barcode but (1) this doesn't always mean there's malicious intent and (2) the detection of tampering doesn't prevent acquisition of the plasmid. I understand the solution, but I am not seeing the problem this solves or the attacks that this mitigates. The attacks described in the submission point out attacks against STAMP, which I think are sufficiently mitigated. What seems missing to me are the risks in the biotech ecosystem that STAMP mitigates.

Note: This is relevant for general trackability of synthetic

sequences, but the question below about relevance for *AI* safety in

particular is thus mis-posed. AI really doesn't have to be part of

every question these days. So I'm leaving that set to its default

neutral because that question doesn't match the more-general

techniques in this submission.

This is an interesting idea which has a number of issues which might

make it infeasible, but still worth considering:

(a) Synthesizers make errors. I see you're trying to ameliorate that

with your Hamming codes, but those only cover the barcode itself.

I'm assuming that the occasional errored landmark wouldn't be that

critical because the chances of that one single base being wrong

aren't individually high and the chances of *many* of the landmarks

being wrong is even smaller, assuming that we can assume statistical

independence.

(b) ...buuut: doesn't even a single-bit error break the hash?

Even a single incorrect landmark base would invalidate the hash,

and I don't see way around this unless you run ECC/RS/Hamming

along the landmarks, too, which I guess you could do.

(c) It's unfortunate that this can only detect ~kb insertions. Yes,

it'd be hard to do better without too much overhead, but it also means

that someone who can just assemble from oligos will defeat this, so

it's raising the bar but isn't going to be a complete solution.

(d) HSMs are *expensive.* Having personally advised benchtop vendors

on their machine security, it's apparent that even spending the small

amount of extra money it takes for a single-board computer which

allows adding a TPM chip (as opposed to ones which don't even have a

place on the board one may be attached) isn't something vendors are

going to do unless forced, such as via legislation. Expecting them

to do a good job about secure boot chains and the like isn't likely

in the near future absent some way to make this a commercial priority.

(e) A public ledge is going to be a hard sell, because it's going to

be hard to convince vendors you're not hiding information flows if the

machine reaches out to the network -- but it's not an *impossible*

sell. OTOH, claiming that you can "sunset" a public ledger is very

likely infeasible because if it's public, someone can keep a copy.

I don't see how you have both at once.

(f) A 12-bit synth ID isn't long enough if this industry ever really

takes off. You probably don't need IPv6's 128-bit overcompensation

for IPv4's 32-bit limit, but you should think harder about a

representation which can at least be variable-length if the number

of synths grows.

(g) I'm not sure an attacker couldn't just make their own primers.

*Maybe* section 3.5 says they can't do this, but I'm uncertain.