I had a similar experience and asked.

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.

The wiki article mentions estimations being done from parts from broken tanks, in which case internal numbers wouldn't necessarily help.

The Soviets used to semi-randomly change ship pennant numbers and other identifying marks on their equipment to throw off NATO efforts to develop accurate strength estimates, orders of battle, and movement pictures.

As a less intentional version of this - at early stages of the 1973 war, Israeli forces in certain areas tended to consist of whatever scraps of forces arrived at the front first. This led Egyptian and Syrian intelligence to wildly overestimate Israeli force sizes, since they would sometimes see the identifying marks of multiple brigades when facing a very small force.

> why not print the serial numbers inside the tank

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.

Finally, an application for Google Glass: Tank identification. Paint on a camouflage QR code and we're ready to go.

FWIW, I believe the military already deploys mobile computers with HUDs like this.

Such a (GPS-based) system I've worked with in the past is called Blue Force Tracking.

http://en.wikipedia.org/wiki/Blue_Force_Tracking

I don't know whether they use HUDs, and whether they work with tanks, but the common name for that is a "friend or foe" system (http://en.wikipedia.org/wiki/Identification_friend_or_foe)

I'd guess that they didn't know if they were allowed to do that, and figured if there was no serial number then they couldn't get in trouble.

So, I HMAC the serial numbers of the tank. Now you have a series of very large numbers, evenly distributed.

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...

If the serial numbers are randomly distributed in some finite span, and you have the serial number of three tanks, say:

    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%?

Apparently encryption is weak because the plaintext has a very simmple pattern (increasing numbers).

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)

A MAC of a message m can only be computed with the knowledge of a key K. Specifically, with a cryptographic hash function h,

  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.

Why is encryption weak due to the simple pattern of increasing numbers? Encrypting increasing numbers is how CTR and GCM mode work; those are arguably some of the best modes of operation we have commonly available.