(But if so, why not print the serial numbers inside the tank, not outside? Or maybe encrypt or HMAC them?)
(But if so, why not print the serial numbers inside the tank, not outside? Or maybe encrypt or HMAC them?)
The answer was that when things like tanks get moved, it's by rail or ship. When figuring out what goes where, having to climb up on a railcar to figure out whose tank it was gets old.
I think by serial number you mean the unit number and markings stenciled on the tank?
Something like 'C Co/5th Bn/377th Rgt'
Because friendly soldiers need to eyeball that information at a glance. Climbing up and peering inside each and every vehicle is a time-waster.
Someone else can do the proof, but I'm pretty sure the total number of tanks is inversely proportional to the smallest difference between two observed HMACs (or between the highest observed HMAC and the highest possible HMAC).
EDIT: Actually, scratch that. That only works if you see all the tanks...
a: 000001
b: 000101
c: 100000
What is the probability that c is not the highest serial number and that there are 1000 total tanks.How many tank serial numbers would we need before those probabilities get > 90%, > 95%?
http://en.wikipedia.org/wiki/German_tank_problem#Countermeas... http://en.wikipedia.org/wiki/Known-plaintext_attack
I can't understand HMAC enough to know whether it solves it, but there seems to be a trade-off between keeping it secure and introducing randomness and making people do lookups on the other end (which would have been super slow then, and I don't know how feasable hash tables are when dealing with punchcards)
HMAC(K, m) = h(K + a || h(K + b || m)),
where + is addition mod 2 (xor), || is concatenation and a and b are constants. (This construction takes into account possible length extension attacks on h.)Given that h is secure, knowledge of any reasonable number of pairs (m, HMAC(K, m)) does not allow you to recover K, and without K, you cannot compute HMAC(K, m) for known m, i.e. enumerate all the possible MACs for serial numbers.